content-calendar

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Content Calendar

内容日历

A content calendar isn't a blank grid you fill by heroics — it's a sustainable operating rhythm: a recurring structure that generates posts so you're never staring at an empty page, at a cadence you can actually hold. Two ideas drive everything here:

Cadence equals capacity. The number-one reason calendars fail is overcommitting. A sustainable floor you keep for a year beats an ambitious plan abandoned in February.
A recurring skeleton beats a blank page. Define repeatable buckets (pillar × format × slot) and a couple of named series — then each cycle is fill-in-the-blanks, not invent-from-scratch.

This skill owns the recurring system. Filling a specific week/month with actual posts is

batch-content-plan

; the higher-level channel/goal choices are

social-strategy

. This sits between them: strategy + pillars → the repeatable rhythm → (per cycle) batch-content-plan → content skills → scheduler.

内容日历不是一张靠硬撑填满的空白网格——它是一套可持续的运营节奏：一种循环出现的固定结构，用来持续生成帖子，让你不再面对空白页面，并采用你真正能够坚持的发布频率。这里的一切都基于两个核心观念：

发布节奏等于产能。 内容日历失败的首要原因是承诺过度。一个能够坚持一年的可持续保底计划，胜过一份在二月就被放弃的雄心勃勃的计划。
固定骨架胜过空白页面。 定义可重复的内容桶（内容支柱 × 内容形式 × 内容位），再设置几个命名系列——这样每个周期只需填空，而不必每次从零构思。

本 skill 负责这套循环系统。 填充某个具体周/月并产出实际帖子是

batch-content-plan

的职责；更高层级的渠道/目标选择则属于

social-strategy

。本 skill 位于两者之间：战略 + 内容支柱 → 可重复的节奏 →（每个周期）

batch-content-plan

→ 内容类 skills → 排期工具。

Step 0 — Read the foundation first

第 0 步——先读取基础信息

Load

social-strategy.md

content-pillars.md

, and

brand-profile.md

. If pillars don't exist, route to

content-pillars

or derive lightweight provisional ones — the calendar must map to themes, not float free.

加载

social-strategy.md

、

content-pillars.md

和

brand-profile.md

。如果没有内容支柱，转至

content-pillars

或推导出一组轻量级的临时内容支柱——内容日历必须映射到主题，不能无的放矢。

Step 1 — Size the cadence to real capacity

第 1 步——根据实际产能确定发布节奏

Estimate honest capacity (time, people, budget, the bad-week floor) and set a sustainable cadence per platform — different per platform, not one number everywhere. Pick one or two primary platforms to do well. Use repurposing to cover more without proportionally more work. See

references/cadence-and-capacity.md

估算真实产能（时间、人力、预算、糟糕一周时的保底线），并为每个平台设定可持续的发布频率—— 各平台应有所不同，而不是到处都使用同一个数字。选择一到两个主要平台做精做强。利用内容复用来扩大覆盖面，而不必让工作量按比例增加。参见

references/cadence-and-capacity.md

。

Step 2 — Build the recurring skeleton

第 2 步——建立固定骨架

Map buckets — pillar × format × slot/day/platform — so each slot is a standing instruction, not a fixed post. Distribute across pillars (signature pillar gets prime slots) and vary formats by design. See

references/calendar-structure.md

规划内容桶——内容支柱 × 内容形式 × 内容位/日期/平台——使每个内容位都成为一项长期指令，而不是一条固定的帖子。在各内容支柱之间分配内容（标志性内容支柱获得黄金内容位），并有意识地让内容形式多样化。参见

references/calendar-structure.md

。

Step 3 — Design one or two recurring series

第 3 步——设计一个或两个循环系列

Add a named franchise in a fixed slot ("Teardown Tuesday," "Build Log") for anticipation, less decision fatigue, and recognition. One or two — not every slot.

在固定内容位中加入一个命名的系列栏目（“Teardown Tuesday”、“Build Log”），以制造期待、减少决策疲劳并提升辨识度。只设一到两个——不是每个内容位都设。

Step 4 — Anchor dates + reserve reactive room

第 4 步——锚定日期并预留反应空间

Layer time-bound anchors (launches, relevant events) onto the skeleton, and reserve ~20–30% for reactive/timely content with one or two open slots a week (hand live trend research to

trend-jacking

). Structure for consistency; reactive room for relevance.

在骨架上叠加有明确时间边界的锚点（产品发布、相关活动），并预留约 20–30% 用于反应式/时效性内容，每周留出一到两个开放内容位（将实时趋势研究交给

trend-jacking

）。结构保证一致性；预留空间保证相关性。

Step 5 — Set the operating rhythm

第 5 步——设定运营节奏

Define the workflow that sustains it: a planning ritual (monthly shape, weekly fill, daily engage), batch creation, and a buffer/queue so a bad week doesn't break the streak. Assign roles if a team. See

references/operating-rhythm.md

定义支撑该日历的工作流：一套规划例行流程（按月定形、按周填充、每日互动）、 批量创作，以及一个缓冲区/队列，确保糟糕的一周不会中断连续发布。如果是团队，还要分配角色。参见

references/operating-rhythm.md

。

Step 6 — Deliver + hand off

第 6 步——交付并完成交接

Output the cadence + recurring skeleton + series + planned/reactive split + anchors, plus a filled sample week to make it concrete. Then:

Fill a specific period →
```
batch-content-plan
```
.
Write each piece → the content skills; adapt across platforms →
```
cross-platform-repurposing
```
.
Schedule →
```
scheduling-and-queue
```
(into the buffer).

输出发布频率 + 固定骨架 + 系列 + 计划内容/反应式内容比例 + 锚点，再附上一个填充完整的示例周，让方案具体可感。然后：

填充特定周期 →
```
batch-content-plan
```
。
撰写每篇内容 → 内容类 skills；跨平台改编 →
```
cross-platform-repurposing
```
。
排期 →
```
scheduling-and-queue
```
（进入缓冲区）。

Quality bar — self-check

质量标准——自检

Is the cadence sized to capacity (the floor, not the ceiling), and per-platform?
Is there a recurring skeleton of buckets (pillar × format × slot), not a one-off list?
Are there one or two named series?
Is reactive room reserved (~20–30%) alongside sensible anchors?
Is there a planning rhythm + buffer, not just a grid?
Are hand-offs to batch-content-plan / content skills / scheduler clear?
Is multi-platform made feasible by repurposing, with no analytics claims?

发布频率是否按产能设定（采用保底线，而非上限），并且是按平台区分的？
是否有由内容桶构成的固定骨架（内容支柱 × 内容形式 × 内容位），而不是一份一次性清单？
是否设置了一个或两个命名系列？
是否在合理的锚点之外预留了反应空间（约 20–30%）？
是否有规划节奏 + 缓冲区，而不只是一张表格？
与
```
batch-content-plan
```
、内容类 skills 和排期工具的交接是否清晰？
是否通过内容复用让多平台发布变得可行，且没有作出任何数据分析声明？

Edge cases & pushback

边界情况与纠偏建议

Overcommitting ("5×/day on 6 platforms solo") → right-size hard to a sustainable floor; explain why; use repurposing.
Too rigid ("lock 90 days, no gaps") → reserve reactive slots; a fully-locked calendar can't ride trends.
"Just give me 20 post ideas" → that's
```
batch-content-plan
```
; offer the recurring skeleton here.
"Build it around our best times/top performers" → WoopSocial has no analytics; offer native data the user pulls or qualitative review; don't claim data-driven optimization.
No pillars/strategy yet → route to
```
content-pillars
```
/
```
social-strategy
```
or derive provisional pillars; don't float free.
Keeps abandoning schedules → fix the rhythm (sustainable floor + buffer + ritual), not just the grid.

承诺过度（“个人同时在 6 个平台每天发 5 条”）→ 坚决将规模调整到可持续的保底水平；解释原因；采用内容复用。
过于僵化（“锁定 90 天，不留空档”）→ 预留反应式内容位；完全锁死的日历无法跟上趋势。
“只要给我 20 个帖子创意” → 这属于
```
batch-content-plan
```
；在这里应提供固定骨架。
“围绕我们的最佳时段/表现最佳的内容来构建” → WoopSocial 没有分析数据；可以提供用户自行拉取的原生数据或定性复盘；不要声称进行了数据驱动优化。
尚无内容支柱/战略 → 转至
```
content-pillars
```
/
```
social-strategy
```
，或推导临时内容支柱；不要无的放矢。
总是放弃排期 → 修复节奏（可持续保底线 + 缓冲区 + 例行流程），而不只是修复表格。

Related skills

References

参考资料

```
references/cadence-and-capacity.md
```
— sizing cadence to capacity; per-platform norms; repurposing; buffer.
```
references/calendar-structure.md
```
— buckets, pillar × format × slot, series, planned/reactive, anchors.
```
references/operating-rhythm.md
```
— the planning ritual, batching, buffer, honest review, hand-offs.
```
references/examples.md
```
— worked calendars (solo + team) with sample weeks, vs an over-ambitious one.

```
references/cadence-and-capacity.md
```
— 确定发布频率与产能的匹配；各平台惯例；内容复用；缓冲区。
```
references/calendar-structure.md
```
— 内容桶、内容支柱 × 内容形式 × 内容位、系列、计划/反应式内容、锚点。
```
references/operating-rhythm.md
```
— 规划例行流程、批量制作、缓冲区、务实复盘、交接。
```
references/examples.md
```
— 实际案例日历（个人与团队），包含示例周，并与过于雄心勃勃的版本进行对比。