| name | case-to-sop |
| description | 案例驱动 SOP 沉淀。从新增 knowledge/cases/*.md 的 frontmatter sop_refs 出发,自动规划每个被引用 SOP 应该做的更新(stub→v0.9 全量重写 / v0.9→追加案例 / 正式版→仅追加 Section 六)。触发:"案例沉淀"、"驱动 SOP"、"反哺 SOP"、"/case-to-sop"、用户新增或修改 knowledge/cases/*.md 并要求更新对应 SOP。 |
| metadata | {"audience":"developers","workflow":"knowledge-curation","category":"sop-lifecycle"} |
case-to-sop
职责
当一个新的案例文件(knowledge/cases/*.md)写完后,把案例中的经验反哺到对应的 SOP(knowledge/sops/<band>/*.md)。本 skill 负责:
- 读案例 frontmatter 中的
sop_refs: [SOP-ID, ...]
- 对每个 SOP 判断当前状态:stub(v0.1 placeholder)/ v0.9(方法论版)/ formal(v1.0+ 正式版)
- 给出具体的更新动作(全量重写 / 追加反哺 / 追加案例)
- 由 Claude 按计划执行 Read / Edit / Write 落盘
本 skill 是 Planner + Executor —— 规划来自脚本,实际落盘由 Claude 在语境中完成。
触发条件
满足以下任一:
- 用户输入
/case-to-sop 或 slash 命令等价形式
- 用户说"案例沉淀"、"反哺 SOP"、"驱动 SOP 更新"、"把这个案例的结论写回 SOP"
- 用户刚新建或刚修改
knowledge/cases/*.md,并希望同步更新 SOP
- 用户引用具体案例文件路径并要求"更新对应 SOP"
实现绑定
| 调用路径 | 实现 | 责任 |
|---|
| 主路径(规划) | tools/case_to_sop.py | 解析案例 frontmatter + 状态检测 + 输出更新计划 |
| 执行(落盘) | Claude(Read / Edit / Write) | 按计划实际修改 SOP 文件 |
| 状态检测逻辑共享 | 与 tools/check-architecture-consistency.py L51-58 对齐 | 保持"stub / v0.9 / formal"判定单一真相源 |
工作流程
1. 参数解析
从用户输入中提取 案例文件路径(形如 knowledge/cases/<name>.md)。
如果用户只提案例名未提路径,先在 knowledge/cases/ 中匹配。
2. 规划(调用脚本)
python3 tools/case_to_sop.py <case-file.md>
输出内容结构:
- 案例元信息:title / 机型阶段 / 现象 / source_case
- sop_refs 列表
- 关键案例要点(脚本自动抽取的 5 条 bullets)
- 逐 SOP 行动计划:每个 SOP 一个
=== SOP-X-YY === 区段,含 State / Template / Proposed action
- 后续执行提示
3. 状态 → 动作映射(Claude 执行依据)
| State | 动作 | 关键产物 |
|---|
stub(v0.1 placeholder) | Full v0.9 rewrite(基于案例 + 兄弟 SOP 结构) | 完整 8 章节方法论版,版本 v0.9.0,标注"方法论版(待现场复测)" |
v0.9(方法论版) | 追加 Section 六 + 更新反哺引用 | 案例追加到典型案例章节,更新附录引用与更新记录,版本 v0.9.x→v0.9.(x+1) |
formal(v1.0+ 正式版) | 仅追加 Section 六 典型案例 | 只动第六章,版本 v1.x.y→v1.x.(y+1) |
missing | 提示先跑 tools/gen_sop_stubs.py 生成 placeholder | — |
4. 执行(Claude 落盘)
按计划对每个 SOP:
- Read 目标 SOP 全文
- stub → 参照脚本给出的 sibling 模板,Write 全量新版(含本案例作首源案例 + 教训反思)
- v0.9 / formal → Edit 追加 Section 六 案例块,更新版本号 / 日期 / 更新记录表
5. 校验
落盘后运行:
python3 tools/check-architecture-consistency.py
重点关注:SOP 行数阈值(v0.9: 180-500 / formal: 180-300)、必备章节、版本号格式。
6. 日志
调用 engineering-logger 技能追加日志,记录:
- 案例文件
- 更新到的 SOP 列表(含版本号变动)
- 是否触发 matrix.yaml 变更(通常不会,除非案例引入了新的源×受扰体映射)
输出契约
Claude 在执行计划后给用户的回复应包含:
## 案例反哺结果
**案例**:`knowledge/cases/<name>.md`
### SOP 变更清单
| SOP | Before | After | 动作 |
|---|---|---|---|
| SOP-X-YY | v0.9.0 | v0.9.1 | 追加 Section 六 案例 |
| ... | ... | ... | ... |
### 关键反哺点
- <从案例抽取的 1-3 条方法论级教训>
### 后续建议
- 是否需要更新 matrix.yaml(仅当案例引入新 source × victim 组合)
- 是否需要更新 bandwidth-discrimination.md(仅当案例纠正了宽窄带判别反例)
与其他 skill / 命令的关系
| 模块 | 关系 |
|---|
engineering-logger | 落盘后调用以记录日志 |
sop-executor | 本 skill 负责 SOP "写入",后者负责 SOP "执行" —— 正交关系 |
/diagnose | 诊断完成 → 用户写案例 → 本 skill 把案例反哺回 SOP |
/formal | 正式报告生成后,若报告伴随新案例,可链式触发本 skill |
tools/check-architecture-consistency.py | 状态检测逻辑共享;落盘后用于校验 |
tools/gen_sop_stubs.py | 若 sop_refs 命中不存在的 SOP,提示先跑此脚本 |
不做什么
- 不自动修改 matrix.yaml(矩阵变更需用户显式决策,本 skill 只提示)
- 不自动修改 methodology/ 方法论文档(同上)
- 不 commit(提交由 engineering-logger 或用户手动完成)
- 不在用户未确认的前提下对 formal(v1.0+) SOP 做结构性修改 —— 只追加 Section 六
设计备注
本 skill 把 Sprint 2 手动编排的 "Agent prompt pattern" 固化下来:Sprint 2 的每个 v0.9 SOP 都是以 (案例 + 兄弟 SOP 模板 + Echo 方法论) 三要素由 Agent 生成。tools/case_to_sop.py 把这三者的定位自动化(通过 frontmatter sop_refs + 同 band 最强兄弟 SOP + 共享的状态检测逻辑),Claude 只负责在语境中按计划落盘,避免每次都要手动挑模板、手动判版本。
版本:v1.0.0(2026-05-06)
