ce-promote

推广文案

将刚上线的功能转化为可直接复制粘贴、面向用户的公告文案，直接融入工程工作流——让消息不必等待单独的营销审核。

**完成标准：**每个起草的渠道都以带标签、可直接复制粘贴的区块呈现，并且已向用户提供修改机会。**此技能只负责起草——绝不发布、公布、安排发布时间、提交更改或创建 PR。**发布是人工操作。

**无论是否安装 Spiral，都能使用：**如果没有安装任何内容，它会依据 Path B（直接起草）中的编辑和社交媒体基础原则直接起草文案。如果已安装 Spiral CLI 且已完成身份验证，生成的文案会贴合用户的品牌风格——这是增强功能，而非使用要求。

阶段 1 — 弄清楚上线了什么

参数中的自由格式描述是事实依据。否则，根据上下文推断，利用现有信息，绝不等待任何单一信息来源：

• 已合并／活跃的 PR — gh pr view --json title,body,url（标题和正文通常会说明面向用户的价值）
• 差异内容 — git diff main...HEAD --stat，快速浏览重要更改，确保描述基于实际变更
• 更新日志 — docs/changelog.md、CHANGELOG.md 或类似文件中的顶部条目或 [Unreleased] 条目
• 近期提交 — git log --oneline -15，了解更改的脉络

然后用 1-3 句话概述面向用户的价值：用户现在能做什么，而此前做不到，以及这为何值得关注。描述结果，而非实现方式——“现在只需单击一下，即可将任意报告导出为 CSV”，而不是“添加了 CsvSerializer 和一个导出端点”。如果无法有把握地判断上线了什么，就提出一个简短问题，而不是猜测。

阶段 2 — 选择渠道

默认起草一条 X 帖文（或简短串文），再加一条单行更新日志／发布说明。如果用户指定了渠道——LinkedIn、电子邮件、博客引言、演示脚本——就起草这些渠道的文案，替代或补充默认内容。根据更改规模灵活调整：小修复只需一两条简短文案，旗舰功能则可覆盖多个渠道。不要强行套用固定模板。

阶段 3 — 起草文案

通过以下两个快速、非阻塞命令检测 Spiral 状态：

which spiral
spiral auth status --json 2>/dev/null

• 没有可执行文件 -> 未安装
• "authenticated": true -> 就绪
• "authenticated": false -> 未通过身份验证
• 输出不是 JSON（较旧的 CLI 忽略了 --json） -> 若包含 spiral_sk_ 则视为就绪，否则视为未通过身份验证

就绪 -> Path A（Spiral 已就绪）。未安装或未通过身份验证 -> Path 0（提供 Spiral 设置），然后如果设置完成则进入 Path A，否则进入 Path B（直接起草）。Spiral 发生故障、超时或输出异常时，绝不能阻塞或拖慢此技能——无法确定时，一律视为未就绪并继续。

Path 0 — 提供 Spiral 设置（仅一次，可拒绝）

以非交互方式运行时，直接进入 Path B——此时没有人可以回答。否则仅提供一次设置选项：阅读 references/spiral-cli.md，并遵循其 Path 0 部分，其中说明了如何检查用户是否选择退出、如何提出阻塞式问题、Agent 运行的 spiral login --json 流程（API 密钥绝不会经过 Agent，用户也无需在聊天中粘贴密钥）、安装路径，以及如何记录用户选择退出。只有当该项检查发现已有退出记录时，才跳过并进入 Path B。该部分定义了怎样才算有退出记录；简单扫描配置会误将 ce-setup 中带注释的模板示例识别为退出记录，从而悄无声息地跳过选项。

此流程依赖该部分中的两项约定：任何拒绝都会记录为选择退出，因此首次运行时拒绝一次，就会永久停止在此仓库中提供该选项；拒绝后始终进入 Path B，不会因此受阻。如果有人在场，但当前工具列表中没有阻塞式问题工具，则在聊天中以编号列表列出两个选项并等待回答——不要跳过选项，也绝不要调用面向用户的问题工具来确认是否存在此类工具。

路径 A — Spiral 已就绪（匹配品牌声音）

撰写提示词前，请先阅读 references/spiral-cli.md。 Spiral 返回多渠道内容，还是同一渠道的多个版本，取决于措辞（渠道关键词和提示词 vs. --num-drafts）；如果弄错，可能会悄无声息地返回数量或形式不符的草稿——不要凭记忆复述这些规则。

始终传入 --instant 和 --json；解析 drafts[]（每份草稿都包含自己的 channel）以及 session_id。展示每一份返回的草稿，并按 channel 分组——每个渠道要生成多少份由 Spiral 决定，因此绝不要假设每个渠道只有一份草稿，也不要漏掉多余的草稿。如果 spiral write 调用出错或未返回可用草稿，则对受影响的渠道静默回退到路径 B。

路径 B — 直接起草

无需 Spiral。通过 ce-noslop 技能为每个渠道起草。（Spiral 路径更进一步：匹配品牌声音、让文案更自然、保存风格，以及跨渠道统筹营销活动。）

每个渠道：

• 先写面向用户的结果——读者现在能做什么，而不是内容是如何构建的。
• 每份内容只表达一个想法。

**分发渠道：**第一行就是吸引读者继续往下看的钩子（信息流会截断内容）。不要写铺垫。匹配各渠道原生的形式和篇幅；切勿在不同渠道直接重复使用同一份草稿。如果渠道适用，加入一个明确的行动号召。仅在渠道通常使用话题标签时添加 0-2 个。

各渠道要求：

• X — 第一行就体现价值；约 1-3 行，简洁有力。只有在内容包含多个值得各自占一行的要点时，才写长帖。
• 更新日志 / 发布说明 — 用一句陈述句点明新功能。直白，不要带宣传口吻。
• LinkedIn — 一段简短文字：先从人的角度说明意义，再介绍具体内容。语气比 X 更亲切。
• 邮件 — 主题行说明收益；正文 2-4 句；加入一个行动号召。
• 博客引言 — 用一段开篇文字阐明问题和新功能；深入内容留给作者。
• 演示脚本 — 3-6 个口述要点：钩子、问题、操作、效果。

默认每个渠道提供一份有力的草稿；只有在用户要求时才提供更多（如“3 个推文选项”），最多约 3 份。

第 4 阶段 — 展示草稿

将每份草稿整理为清晰、便于复制粘贴的内容块，并标注渠道：

### X post
<the copy>

如果通过路径 A 生成草稿，还要展示 session_id 和每份草稿的 url，方便用户在 Spiral 网页应用中打开并修改。主动提出可调整语气、篇幅、角度，提供更多版本或改写其他渠道。不要发布、安排发布、提交或创建 PR——最后提醒用户这些草稿由他们自行发布。