| name | sop-creator |
| description | SOP 制定 Skill：帮助 Manager 与人类协作，从零设计一套任务执行 SOP。 按四要素框架（角色分工/步骤清单/Checkpoint设计/质量标准）生成标准作业流程文档。 适用场景：建立新 SOP 模板，或对已有 SOP 进行重大修订。 产出由调用方（通常是 memory-save skill）写入 shared/sop/ 目录。
|
| type | reference |
sop-creator：SOP 制定框架
概述
本 Skill 是一个参考型（reference） Skill，直接注入调用方 Agent 的上下文。
Manager 无需启动沙盒，只需按照下面的四要素框架，根据任务背景设计 SOP 文档。
SOP（Standard Operating Procedure）是团队执行任务的规范化流程文档。
一个好的 SOP 必须让任何人拿到后都能按步骤执行，不需要额外猜测。
四要素 SOP 设计框架
要素 1：角色分工
谁做什么？谁负责什么阶段？
设计视角：
- 列出参与本任务的所有角色（Manager / PM / Dev / QA 等）
- 每个角色的职责边界：我负责什么 / 我不负责什么
- 角色之间的交接点：A 完成后交给 B 的是什么
要素 2：步骤清单
任务如何从开始到完成？
设计视角：
- 按执行顺序列出所有步骤，每步包含：
- 执行角色
- 操作内容（具体到可执行）
- 输入（从哪里读取）
- 输出（写到哪里、格式是什么）
- 步骤粒度：细到「可以独立执行、有明确完成标志」，不要写「处理需求」这种模糊描述
- 并行步骤需明确标注（哪些步骤可以同时执行）
要素 3：Checkpoint 设计
哪些节点需要人类介入确认？
设计原则：
- 只在以下两类位置设 Checkpoint：
- 不可逆操作之前（执行了就很难撤回）
- 需要人类拍板的关键决策点（方向性判断、风险授权）
- 不要滥设 Checkpoint：每多一个 Checkpoint 就多一次等待和打扰。
高频审批会导致人失去判断力，开始无脑点通过（审批疲劳）。
- 每个 Checkpoint 必须说明：触发位置 / 确认类型 / 等待什么决定
典型 Checkpoint 位置：
- 需求文档完成后、任务分配前（人确认方向是否正确）
- 核心设计文档完成后、开发开始前（人确认方案是否可行）
- MVP 完成后、测试开始前（人确认功能是否符合预期）
要素 4：质量标准
每一步完成的标准是什么？
设计视角：
- 每个关键步骤的完成判断依据（可验证，不模糊）
- 整体任务的验收标准（DoD）
- 常见失败模式和检查点（如：文档格式不符合模板、接口未经测试）
输出格式（标准 SOP 模板）
# {任务类型} SOP
## 适用场景
[描述这个 SOP 适合什么类型的任务，以及不适合什么]
## 角色分工
| 角色 | 职责 | 不负责 |
|------|------|--------|
| Manager | ... | ... |
| PM | ... | ... |
## 执行步骤
### 步骤 1：{步骤名}（{执行角色}）
1. 操作内容
2. 读取：{输入来源}
3. 输出：{输出路径/格式}
### 步骤 2：...
## Checkpoint
| 触发位置 | 消息类型 | 等待决定 |
|---------|---------|---------|
| 步骤X 完成后 | checkpoint_request | 人类确认 [具体确认内容] |
## 质量标准
### 各步骤完成标准
- 步骤1：{可验证的完成标志}
- 步骤2：...
### 整体验收标准（DoD）
- [ ] {可测试的验收条件}
使用注意
- 本 Skill 是纯思考框架，不执行任何代码
- 输出的 SOP 草稿内容交由
memory-save skill 写入 shared/sop/ 目录
- 文件命名约定：ASCII 小写 + 下划线，如
product_design_sop.md、code_review_sop.md
- 文件名必须根据任务背景自动生成，禁止使用
product_design_sop 等与任务无关的默认名称。
命名规则：提炼任务核心动词+对象，转为 ASCII 下划线风格，结尾加 _sop。
示例：竞品分析 → competitive_analysis_sop，代码审查 → code_review_sop，用户调研 → user_research_sop
- 草稿文件加
draft_ 前缀：draft_competitive_analysis_sop.md，人确认后去掉前缀
- Checkpoint 不是越多越好，设计时优先问「这里不设会怎样？」
