工作转可执行手册

要解决什么问题

团队里常见一种浪费：某类活已经有人跑通过一遍，但下次换个人或换 Agent，仍要从零摸索，反复踩同样的坑。把过程写成 README 或 Wiki，Agent 往往只会「读到一半就来问你接下来怎么办」——因为文档记录的是结果，不是可执行的决策链和从失败里提炼的 Gotchas。

本技能针对的是：如何把「已经做完的一次真实工作」变成 Agent 拿到后能自主推进到完成的执行手册，而不是先空写 SKILL.md 再去做事。

技能如何工作

核心顺序是：先有人把工作做完 → 教 AI 做一遍并记录失败 → 再封装。加载后会先判断是创建新技能还是更新已有技能，再按阶段推进：

1. 工作识别：未完成、一次性任务、标准库文档、项目专属约定等场景，明确该不该封装（详见 references/workflow-guide.md）。
2. 经验萃取：优先从「教 AI 时的真实失败」提取边界情况、环境依赖与隐性知识；Gotchas 必须写成「遇到 X 则做 Y」，而不是「注意这里有坑」。
3. 教学记录：完整写入 assets/teaching-record.md，作为后续封装的依据。
4. 技能封装：SKILL.md 控制在 500 行内，大块内容进 references/；description 需同时说明做什么、何时用，并在末尾加 Do NOT use for... 负面触发器。
5. 可复现性验证：对照清单确认 Agent 能否在不追问的情况下完成，并在文末保留 ## 验证完成。
6. 数据脱敏（可选）：按 8 类敏感信息让用户勾选范围后再扫描、替换与确认。
7. 平台适配发布：按 SkillHub、Coze、ClawHub 等差异调整文件后再交付。

判断标准很简单：把技能交给一个完全不了解背景的 Agent，它能否独立完成这项工作。

适用边界与注意点

• 不适合：工作尚未结束、纯一次性对话任务、已有成熟公开文档的标准工具用法、只适用于单个仓库的内部约定——这些应写在项目 README 或对话记录里。
• 更新已有技能时遵循增量追加与 SemVer：PATCH 修错补 Gotcha，MINOR 增流程，MAJOR 才做不兼容变更。
• 脱敏保留流程结构（例如审批链路的角色顺序），只泛化具体人名与公司；过度删除会把技能变成无法复现的空壳。
• 若不确定 Skill 与 MCP 的分工，可参考技能内的 references/skills-vs-mcp.md 与故障排除表。