nextclaw: Skill for Claude Code

产品博客叙事

候选与提前成稿

博客不必等到版本发布后才开始。用户明确要求写作，或 Delivery 判断一个已验证结果具备独立用户任务、可核查证据和公开叙事价值时，进入本 skill；changeset 本身不自动等于博客候选。

按事实成熟度选择一个状态：

• 证据或产品边界尚未稳定：只报告候选主题和缺失证据，不创建正文；
• 实现、Validation 与 Review 已稳定：可提前写入 docs/blog-drafts/YYYY-MM-DD-<topic>.blog-draft.md；
• 获得正式发布授权：按实际发布日期迁入 apps/docs/zh/blog 与 apps/docs/en/blog，并同步 index、sidebar 和适用链接。

内部草稿不参与站点构建，也不代表文章已发布。草稿正文只保留未来读者需要看到的内容；候选判断、私有路径、测试会话 ID、发布步骤和内部取舍留在设计、迭代记录或协作回复中。实现或测量环境在成稿后变化时，发布前重新核对全部事实与指标。

需要随产品 changeset 一起发布时，草稿 frontmatter 写入 releaseBlogTarget: next-stable、releaseBlogChangeset 和 releaseBlogState: draft，changeset 使用 <!-- release-note-blog: docs/blog-drafts/<file>.blog-draft.md --> 绑定。发布准备时生成中英文正式文章、更新 index/sidebar，并把草稿状态改为 ready、补充 releaseBlogZhPath 与 releaseBlogEnPath。NPM 达到 NPM_READY 后，产品发布闭环会阻断仍处于 draft 或缺少正式入口的绑定文章；线上验证完成后再删除内部草稿。

发布关联的功能、优化和结果博客默认采用短篇结果营销稿：标题先写产品、成果和最强可核查数字，首屏直接回答“做成了什么、效果如何”；实现原理只保留理解结果所需的最少内容。只有用户明确要技术复盘、原理说明或产品判断时，才展开为科普或长文。标题可以强，但不能超出测量范围或把开发版本写成已发布。

写作流程

1. 对齐 docs/VISION.md，明确主题服务统一入口、能力编排、自感知、自治、自进化或生态扩展中的哪一点。
2. 从代码、文档、真实 UI、事件链路、发布记录或用户反馈找证据。证据不足的内容写成方向，不写成已完成事实。
3. 先选传播目标：发布关联的功能与优化使用结果营销短稿；状态报告使用结果摘要；只有用户明确要求时才写观点、科普或长篇故事。
4. 用一句话冻结核心事实，再写它支撑的具体用户任务；模型接入、安装 skill、连接渠道等能力入口本身不是用户任务。
5. 比较竞品前固定产品与版本，使用官方一手资料建立 能力 | NextClaw | 对方 | 结论。对方同样具备的能力不能继续称独有优势；文档未提及也不能断言不存在。
6. 区分“自身已有能力、产品重要特点、相对差异”，再核对控制边界、执行层、生命周期、组合方式和成熟度。
7. 写明能力边界和下一步，不把底座、方向或概念图包装成现成功能。
8. 公开正文由 Wiki 中的用户内容边界约束；分类过程、模板解释和取舍理由留在协作材料，不进入发布稿。

默认文章结构

## 摘要

一句话结论 + 3-5 条可核查事实。

## 当前结果

用表格列能力、状态和用户可见结果。

## 能力边界

列尚未完成的范围。

## 下一步

列 2-3 个后续方向。

正文短、硬、可核查；多用“当前、已具备、未完成、下一步”，少用情绪转场、排比和“大 V”腔。事实说明可在此基础上扩写；只有用户明确要观点、传播稿或发布故事时，才增加问题、判断、取舍和用户使用路径。

配图选择

先写一句“图片必须让用户看懂什么”，再比较至少 2-3 种形式：

• 真实/标注截图：已上线能力的首选，可信度最高；
• 概念化产品图：跨多界面或尚在产品化的能力，必须明确是概念表达；
• 信息图/流程故事板：结构判断、对比、before/after 和用户旅程；
• 抽象氛围图：默认不选，不能替代产品证据。

功能跨多个界面时，截图覆盖真正承担说明责任的入口、管理面和结果面，不能用结果图替代完整链路。可信度和传播性冲突时，以截图作正文证据、概念图作 hero。

配图后自评：视觉焦点是否命中核心亮点；是否有任务、状态、进度、工具或统一工作台等证据元素；去掉标题后能否猜到主题；是否退化为机器人、科幻光效或泛 AI 氛围。未命中就改 brief 或重做。