Sop Creator

任务如何从开始到完成？

设计视角：

• 按执行顺序列出所有步骤，每步包含：
  • 执行角色
  • 操作内容（具体到可执行）
  • 输入（从哪里读取）
  • 输出（写到哪里、格式是什么）
• 步骤粒度：细到「可以独立执行、有明确完成标志」，不要写「处理需求」这种模糊描述
• 并行步骤需明确标注（哪些步骤可以同时执行）

要素 3：Checkpoint 设计

哪些节点需要人类介入确认？

设计原则：

• 只在以下两类位置设 Checkpoint：
  1. 不可逆操作之前（执行了就很难撤回）
  2. 需要人类拍板的关键决策点（方向性判断、风险授权）
• 不要滥设 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 不是越多越好，设计时优先问「这里不设会怎样？」