Communitygithub.com

内容日历

一个可持续的内容运营节奏系统,通过可重复的支柱-格式-槽位结构生成内容,避免过度承诺和空白页面的焦虑。

内容日历 是什么?

该技能旨在为开发者或内容团队构建一个可持续的、基于节奏的内容日历,而不是一份一次性填满的网格。其核心思想是“节奏等于产能”:承诺一个你一年都能坚持的下限,远胜于一个二月就破产的雄心计划。技能通过定义可重复的“桶”(支柱 × 格式 × 槽位)和一到两个命名的系列(如“周二大拆解”),让你每周只需填空,而不必每次从零发明。它位于高层战略(`social-strategy`)和单轮执行(`batch-content-plan`)之间:输入战略和支柱,输出一个可持续的重复骨架、系列、以及20-30%的反应式空间。该技能明确不支持内容分析(如最佳发布时间),并要求用户手动或通过`content-pillars`技能提供支柱,否则不会工作。它适用于Claude Code、Cursor、Codex等AI代理平台,通过清晰的步骤、参考文件和自我检查清单,确保日历的可行性、可操作性与可维护性。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/social-media-skills/skills/tree/main/skills/content-calendar

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

内容日历 是做什么的?

内容日历不是一张靠英雄主义填满的空白网格——它是一个可持续的运营节奏: 一个可重复的结构,按你真正能坚持的频率生成帖子,这样你永远不会面对空白页面。这里有两个核心理念:

  1. 节奏等于产能。 日历失败的首要原因是过度承诺。一个你能坚持一年的可持续下限,远胜于一个二月就破产的雄心计划。
  2. 可重复的骨架胜过空白页面。 定义可重复的桶(支柱 × 格式 × 槽位)以及一两个命名系列——这样每个周期就是填空,而不是从零发明。

本技能负责这个可重复系统。 填充特定周/月的实际帖子是 batch-content-plan 的责任;更高层的渠道/目标选择属于 social-strategy。本技能恰好处于两者之间:战略 + 支柱 → 可重复的节奏 → (每个周期)batch-content-plan → 内容技能 → 发布计划器。

步骤 0 — 首先阅读基础资料

加载 social-strategy.md、content-pillars.md 和 brand-profile.md。如果支柱不存在,请引导至 content-pillars 或推导出轻量级临时支柱——日历必须映射到主题,而不是凭空漂浮。

步骤 1 — 根据实际产能确定节奏

估算真实产能(时间、人力、预算、坏周的下限),并为每个平台设定一个可持续的节奏——每个平台不同,而不是一个数字到处用。挑选一到两个主要平台做好。通过重新利用来覆盖更多平台,而不成比例地增加工作量。参见 references/cadence-and-capacity.md。

步骤 2 — 构建可重复的骨架

映射桶——支柱 × 格式 × 槽位/天/平台——这样每个槽位是一条固定的指令,而不是一个固定的帖子。在各支柱之间分配(标志性支柱获得优先槽位),并有意地变化格式。参见 references/calendar-structure.md。

步骤 3 — 设计一到两个可重复的系列

在固定槽位中添加一个命名的系列(“深度剖析星期二”、“开发日志”),以建立预期、减少决策疲劳并提高辨识度。一到两个足矣——不是每个槽位都要。

步骤 4 — 设定锚定日期 + 预留反应空间

将有时限的锚定(发布日、相关事件)叠加到骨架上,并预留约20-30%用于反应式/时效性内容,每周留出一到两个开放槽位(将实时趋势研究交给 trend-jacking)。用骨架保证一致性,用反应空间保证相关性。

步骤 5 — 设定运营节奏

定义支撑日历的工作流:一个规划仪式(月度规划、每周填充、每日互动)、批量创作,以及一个缓冲区/队列,这样即使遇到坏周也不会打破连续记录。如果团队运作,指定角色。参见 references/operating-rhythm.md。

步骤 6 — 交付 + 交接

输出节奏 + 可重复骨架 + 系列 + 计划/反应比例 + 锚定,再加上一个填充好的样本周以使其具体化。然后:

  • 填充特定时间段 → batch-content-plan。
  • 撰写每篇内容 → 内容技能;跨平台适配 → cross-platform-repurposing。
  • 发布 → scheduling-and-queue(存入缓冲区)。

质量标准——自查清单

  • 节奏是否根据产能(下限,而非上限)调整,并且是针对每个平台**的?
  • 是否有可重复的骨架(由支柱 × 格式 × 槽位组成的桶),而非一次性列表?
  • 是否有一两个命名系列?
  • 是否预留了反应空间(约20-30%)以及合理的锚定?
  • 是否有规划节奏 + 缓冲区,而不仅仅是一张网格?
  • 是否明确了交接给 batch-content-plan / 内容技能 / 发布计划器?
  • 多平台是否通过重新利用变得可行,并且没有分析声明?

边界情况与推送回

  • 过度承诺("一个人每天在6个平台上发5次")→ 严格调整至可持续下限;解释原因;使用重新利用。
  • 过于死板("锁定90天,不允许有空白")→ 预留反应槽位;完全锁定的日历无法跟上趋势。
  • "直接给我20个帖子想法" → 那是 batch-content-plan 的职责;在此提供可重复的骨架。
  • "根据我们的最佳发布时间和顶级表现来构建" → WoopSocial没有分析功能;建议用户提取原生数据或进行定性审查;不要声称基于数据的优化。
  • 尚无支柱/战略 → 引导至 content-pillars / social-strategy 或推导临时支柱;不要凭空漂浮。
  • 总是放弃发布计划 → 修复节奏(可持续下限 + 缓冲区 + 仪式),而不仅仅是网格。

相关技能

  • social-strategy — 此技能之上的渠道/目标选择。
  • content-pillars — 骨架映射到的主题;brand-profile、voice-builder。
  • batch-content-plan — 用简报填充特定时间段(每轮执行)。
  • cross-platform-repurposing — 使多平台变得可持续。
  • 内容技能(caption-writer、reels-script、tiktok-script、carousel-writer、thread-writer、linkedin-post-writer)— 撰写每个槽位。
  • trend-jacking — 反应式槽位;scheduling-and-queue — 将内容发布到缓冲区。

参考资料

  • references/cadence-and-capacity.md — 根据产能调整节奏;针对每个平台的标准;重新利用;缓冲区。
  • references/calendar-structure.md — 桶,支柱 × 格式 × 槽位,系列,计划/反应,锚定。
  • references/operating-rhythm.md — 规划仪式,批量创作,缓冲区,诚实回顾,交接。
  • references/examples.md — 已实现的日历(独立创作者 + 团队),附样本周,以及一个过度乐观的例子。

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

相关技能