/sop-creator

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**：

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 不是越多越好，设计时优先问「这里不设会怎样？」