social-calendar

根据用户的内容支柱、平台和实际可持续的发布频率，制定一份切实可行的 2 周内容计划——是计划，不是排程工具。

背景

读取项目根目录中的 social-context.md（也检查 .agents/social-context.md），查看 ## Voice、## Pillars、## Platforms、## Audience、## Cadence 和 ## Goals 部分。如果文件缺失，请先提议运行 social-context skill，但不要因此耽搁——直接提出 2–3 个简短问题，并继续执行：

• 你的 2–4 个内容支柱是什么？
• 你会使用哪些平台？哪个最重要？
• 过去一个月，你实际稳定做到每周发几篇？

工作流

1. 首先确认实际发布频率。 按照 ## Cadence 中的数字来安排——这是用户如实给出的数量，请予以尊重。如果用户要求的发布量超过其所述频率（例如频率写着每周 3 次，却要求每天发布），要明确提出一次异议：不切实际的日历安排还不如没有，因为错过排期会让用户逐渐忽视整个计划。按照他们实际能够坚持的频率来安排，或者采用他们重新明确确认的新频率。
2. 确定日期范围。 从下一个适合发布的自然日开始，规划两周——通常是明天；如果今天已临近周末，则通常从即将到来的周一开始。只有当参照日期确实导致时间范围不明确时，才询问时区。
3. 收集重要节点。 询问这段时间内是否有真实发生的事情：产品发布、活动、网络研讨会、版本发布，或受众确实会庆祝的节日。先安排与这些节点相关的内容，再围绕它们制定其余计划。重要事项要设计成一个小系列，而不是只安排单独一条内容：
   • 提前 2–4 天发布一条预热内容（预告问题，而不是公告）；
   • 在重要节点当天发布内容；
   • 之后 1–3 天发布一条后续内容（成果、经验或幕后情况）。
4. 分配内容支柱。 将各内容支柱分散到不同排期中，确保同一平台不会连续两次发布同一个支柱，也不会让任何一个支柱占总排期的约 40% 以上，除非用户表示有意让某个支柱占主导。根据 ## Goals 中的主要目标调整内容比例——获客目标侧重展示产品实际效果的支柱；认知度和权威性目标则侧重观点与教学内容。如果用户有 4 个或更多支柱，但排期很少，不要把每个支柱都压缩成一条象征性内容——这两周先搁置最弱的支柱，并告诉用户是哪一个以及原因。
5. 分配内容形式。 轮换各平台实际支持的形式，并让形式与支柱相匹配——教学内容适合长帖、轮播图文和文档帖子；观点和故事类内容适合单条文字帖子：
   • LinkedIn： 文字帖子、文档／轮播帖子、图片帖子
   • X： 单条帖子、长帖、图片帖子
   • Instagram： 轮播图文、Reel 创意、单张图片
   • Threads / Bluesky： 短文字帖子、小型长帖
   • Facebook： 文字帖子、图片帖子、链接帖子 绝不安排平台不支持的形式，也不要让某个平台在整个两周内只使用一种形式。
6. 为每个排期写一个工作标题或开场钩子。 不要只写主题标签，而要写出用户可以直接用作开头的实际第一句话。“我们为什么砍掉了最好的功能”胜过“产品经验”。如果上下文中提供了品牌语气，就用这种语气写钩子；如果有禁用词清单，也要遵守。
7. 预留临时内容空间。 留出约 20% 的排期——两周内至少 2 个——并标记为 reactive，不指定主题。这些排期可用于回应热门话题、将值得展开的回复转为帖子，以及跟进用户所在领域的新闻。在计划备注中明确说明这一点，让用户明白这些排期是预留容量，而不是空缺。
8. 按精力安排顺序，而非追求整齐。 第一周优先安排最有力的钩子——尽早取得成效有助于用户坚持计划。将准备工作量大的形式（轮播图文、长篇长帖）安排在用户可能有空的日子；如果不清楚，就询问。如果同一个创意适合两个平台，就间隔 1–3 天发布，并重新调整钩子——绝不要在同一天原样复制粘贴。
9. 最后检查计划是否现实。 提交计划前，逐项核对质量标准中的每一项——发布量、支柱间隔（包括约 40% 的上限）、形式搭配、钩子、预留空间、重要节点以及跨平台发布间隔。宁可删减，也不要硬塞——用户能完成的 9 条计划，胜过他们会半途放弃的 14 条计划。
10. 可以提出导出 .ics 文件，但不要未经请求就生成。 如果用户需要日历条目，就生成一个 .ics 文件，每个排期对应一个全天事件，标题格式为 [platform] hook，这样计划就能添加到他们平时使用的日历中。

质量标准

检查项	约束
发布量	与声明的频率完全一致——绝不超出
支柱间隔	同一平台上不能连续两次发布同一支柱；任何支柱占比不得超过约 40% 的发布位
格式组合	两周内每个平台至少采用 2 种不同格式
开场白	每个发布位都有可用的第一句话，而不是主题标签
灵活空间	约 20% 的发布位标记为 reactive，至少 2 个
重要日期	用户提到的每个日期都安排发布位；重要日期前后都要有预热和后续内容
跨平台发布	同一主题在两个平台上的发布时间间隔 1–3 天，并改写开场白

每个开场白都必须通过“我会停下来不再刷吗？”测试——要具体、明确，并带有观点或张力：

不合格	合格
“关于效率的想法”	“我连续 30 天记录了每场会议。有 11 个小时纯属作秀。”
“我们的发布故事”	“我们发布后只收到了 4 个注册。看这封邮件如何扭转局面。”
“给创始人的建议”	“这条建议让我们浪费了 6 个月：‘多和用户交流。’”

交付内容

一个 Markdown 表格，包含 日期 | 平台 | 支柱 | 格式 | 工作标题 / 开场白 | 状态 列，每一行的状态都设为 idea。例如：

日期	平台	支柱	格式	工作标题 / 开场白	状态
周一 7 月 20 日	LinkedIn	公开构建	文字帖	“我们先发布了错误的功能。故意的。”	idea
周二 7 月 21 日	X	教学	主题帖	“我反复看到的 7 个定价页面错误（附修正方法）：”	idea
周三 7 月 22 日	X	—	—	reactive	idea

表格下方添加一个简短的 备注 部分，说明：计划的发布频率及其原因、暂缓了哪个支柱（如有），以及如何使用灵活发布位。可选择提供 .ics 导出。这是一份供用户自行执行的计划——交付后即止。