specops 0.2.2 → 0.2.4

package/.opencode/skills/subagent-driven-development/SKILL.md

@@ -0,0 +1,242 @@
+---
+name: subagent-driven-development
+description: 在当前会话中执行实现计划，适用于包含多个独立任务的场景
+---
+
+# 子 Agent 驱动开发
+
+通过为每个任务派发全新的子 agent 来执行计划，每个任务完成后进行两阶段审查：先审查规格合规性，再审查代码质量。
+
+**核心原则：** 每个任务一个全新子 agent + 两阶段审查（规格 → 质量）= 高质量、快速迭代
+
+## 何时使用
+
+```dot
+digraph when_to_use {
+    "有实现计划吗？" [shape=diamond];
+    "任务大多独立吗？" [shape=diamond];
+    "留在当前会话？" [shape=diamond];
+    "子 agent 驱动开发" [shape=box];
+    "执行计划" [shape=box];
+    "手动执行或先头脑风暴" [shape=box];
+
+    "有实现计划吗？" -> "任务大多独立吗？" [label="是"];
+    "有实现计划吗？" -> "手动执行或先头脑风暴" [label="否"];
+    "任务大多独立吗？" -> "留在当前会话？" [label="是"];
+    "任务大多独立吗？" -> "手动执行或先头脑风暴" [label="否 - 紧密耦合"];
+    "留在当前会话？" -> "子 agent 驱动开发" [label="是"];
+    "留在当前会话？" -> "执行计划" [label="否 - 并行会话"];
+}
+```
+
+**对比执行计划（并行会话）：**
+- 同一会话（无上下文切换）
+- 每个任务全新子 agent（无上下文污染）
+- 每个任务完成后两阶段审查：先规格合规性，再代码质量
+- 更快迭代（任务之间无需人工介入）
+
+## 流程
+
+```dot
+digraph process {
+    rankdir=TB;
+
+    subgraph cluster_per_task {
+        label="每个任务";
+        "派发实现子 agent（./implementer-prompt.md）" [shape=box];
+        "实现子 agent 有问题？" [shape=diamond];
+        "回答问题，提供上下文" [shape=box];
+        "实现子 agent 实现、测试、提交、自审" [shape=box];
+        "派发规格审查子 agent（./spec-reviewer-prompt.md）" [shape=box];
+        "规格审查子 agent 确认代码符合规格？" [shape=diamond];
+        "实现子 agent 修复规格差距" [shape=box];
+        "派发代码质量审查子 agent（./code-quality-reviewer-prompt.md）" [shape=box];
+        "代码质量审查子 agent 通过？" [shape=diamond];
+        "实现子 agent 修复质量问题" [shape=box];
+        "在 TodoWrite 中标记任务完成" [shape=box];
+    }
+
+    "读取计划，提取所有任务全文，记录上下文，创建 TodoWrite" [shape=box];
+    "还有剩余任务？" [shape=diamond];
+    "派发最终代码审查子 agent 审查整体实现" [shape=box];
+    "使用 specops:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
+
+    "读取计划，提取所有任务全文，记录上下文，创建 TodoWrite" -> "派发实现子 agent（./implementer-prompt.md）";
+    "派发实现子 agent（./implementer-prompt.md）" -> "实现子 agent 有问题？";
+    "实现子 agent 有问题？" -> "回答问题，提供上下文" [label="是"];
+    "回答问题，提供上下文" -> "派发实现子 agent（./implementer-prompt.md）";
+    "实现子 agent 有问题？" -> "实现子 agent 实现、测试、提交、自审" [label="否"];
+    "实现子 agent 实现、测试、提交、自审" -> "派发规格审查子 agent（./spec-reviewer-prompt.md）";
+    "派发规格审查子 agent（./spec-reviewer-prompt.md）" -> "规格审查子 agent 确认代码符合规格？";
+    "规格审查子 agent 确认代码符合规格？" -> "实现子 agent 修复规格差距" [label="否"];
+    "实现子 agent 修复规格差距" -> "派发规格审查子 agent（./spec-reviewer-prompt.md）" [label="重新审查"];
+    "规格审查子 agent 确认代码符合规格？" -> "派发代码质量审查子 agent（./code-quality-reviewer-prompt.md）" [label="是"];
+    "派发代码质量审查子 agent（./code-quality-reviewer-prompt.md）" -> "代码质量审查子 agent 通过？";
+    "代码质量审查子 agent 通过？" -> "实现子 agent 修复质量问题" [label="否"];
+    "实现子 agent 修复质量问题" -> "派发代码质量审查子 agent（./code-quality-reviewer-prompt.md）" [label="重新审查"];
+    "代码质量审查子 agent 通过？" -> "在 TodoWrite 中标记任务完成" [label="是"];
+    "在 TodoWrite 中标记任务完成" -> "还有剩余任务？";
+    "还有剩余任务？" -> "派发实现子 agent（./implementer-prompt.md）" [label="是"];
+    "还有剩余任务？" -> "派发最终代码审查子 agent 审查整体实现" [label="否"];
+    "派发最终代码审查子 agent 审查整体实现" -> "使用 specops:finishing-a-development-branch";
+}
+```
+
+## 提示词模板
+
+- `./implementer-prompt.md` - 派发实现子 agent
+- `./spec-reviewer-prompt.md` - 派发规格合规审查子 agent
+- `./code-quality-reviewer-prompt.md` - 派发代码质量审查子 agent
+
+## 示例工作流
+
+```
+你：我正在使用子 Agent 驱动开发来执行这个计划。
+
+[读取计划文件：docs/plans/feature-plan.md]
+[提取全部 5 个任务的完整文本和上下文]
+[创建 TodoWrite 包含所有任务]
+
+任务 1：Hook 安装脚本
+
+[获取任务 1 的文本和上下文（已提取）]
+[派发实现子 agent，附带完整任务文本 + 上下文]
+
+实现者："开始之前想确认一下，hook 应该安装在用户级别还是系统级别？"
+
+你："用户级别（~/.config/specops/hooks/）"
+
+实现者："明白了。开始实现..."
+[稍后] 实现者：
+  - 实现了 install-hook 命令
+  - 添加了测试，5/5 通过
+  - 自审：发现遗漏了 --force 标志，已补充
+  - 已提交
+
+[派发规格合规审查子 agent]
+规格审查者：✅ 符合规格 - 所有需求已满足，没有多余内容
+
+[获取 git SHA，派发代码质量审查子 agent]
+代码审查者：优点：测试覆盖好，代码干净。问题：无。通过。
+
+[标记任务 1 完成]
+
+任务 2：恢复模式
+
+[获取任务 2 的文本和上下文（已提取）]
+[派发实现子 agent，附带完整任务文本 + 上下文]
+
+实现者：[没有问题，直接开始]
+实现者：
+  - 添加了 verify/repair 模式
+  - 8/8 测试通过
+  - 自审：一切正常
+  - 已提交
+
+[派发规格合规审查子 agent]
+规格审查者：❌ 问题：
+  - 缺失：进度报告（规格要求"每 100 项报告一次"）
+  - 多余：添加了 --json 标志（未要求）
+
+[实现者修复问题]
+实现者：移除了 --json 标志，添加了进度报告
+
+[规格审查者重新审查]
+规格审查者：✅ 现在符合规格
+
+[派发代码质量审查子 agent]
+代码审查者：优点：扎实。问题（重要）：魔法数字（100）
+
+[实现者修复]
+实现者：提取了 PROGRESS_INTERVAL 常量
+
+[代码审查者重新审查]
+代码审查者：✅ 通过
+
+[标记任务 2 完成]
+
+...
+
+[所有任务完成后]
+[派发最终代码审查子 agent]
+最终审查者：所有需求已满足，可以合并
+
+完成！
+```
+
+## 优势
+
+**对比手动执行：**
+- 子 agent 自然遵循 TDD
+- 每个任务全新上下文（不会混淆）
+- 并行安全（子 agent 互不干扰）
+- 子 agent 可以提问（工作前和工作中都可以）
+
+**对比执行计划：**
+- 同一会话（无交接）
+- 持续推进（无需等待）
+- 审查检查点自动触发
+
+**效率提升：**
+- 无文件读取开销（控制器提供完整文本）
+- 控制器精确筛选所需上下文
+- 子 agent 一开始就获得完整信息
+- 问题在工作开始前浮现（而非之后）
+
+**质量关卡：**
+- 自审在交接前捕获问题
+- 两阶段审查：规格合规性，然后代码质量
+- 审查循环确保修复确实有效
+- 规格合规防止过度/不足构建
+- 代码质量确保实现质量过关
+
+**成本：**
+- 更多子 agent 调用（每个任务需要实现者 + 2 个审查者）
+- 控制器需要更多准备工作（预先提取所有任务）
+- 审查循环增加迭代次数
+- 但能早期发现问题（比后期调试更划算）
+
+## 红线
+
+**绝对不要：**
+- 未经用户明确同意就在 main/master 分支上开始实现
+- 跳过审查（规格合规或代码质量都不行）
+- 带着未修复的问题继续推进
+- 并行派发多个实现子 agent（会冲突）
+- 让子 agent 自己读计划文件（应提供完整文本）
+- 跳过场景设定上下文（子 agent 需要理解任务在整体中的位置）
+- 忽略子 agent 的问题（让他们继续之前先回答）
+- 在规格合规上接受"差不多就行"（规格审查者发现问题 = 未完成）
+- 跳过审查循环（审查者发现问题 = 实现者修复 = 再次审查）
+- 让实现者的自审替代正式审查（两者都需要）
+- **在规格合规通过 ✅ 之前就开始代码质量审查**（顺序错误）
+- 在任一审查有未解决问题时就进入下一个任务
+
+**如果子 agent 提问：**
+- 清晰完整地回答
+- 需要时提供额外上下文
+- 不要催促他们赶紧实现
+
+**如果审查者发现问题：**
+- 实现者（同一个子 agent）修复
+- 审查者重新审查
+- 重复直到通过
+- 不要跳过重新审查
+
+**如果子 agent 任务失败：**
+- 派发修复子 agent，附带具体指令
+- 不要手动修复（上下文污染）
+
+## 集成
+
+**必需的工作流 skill：**
+- **specops:using-git-worktrees** - 必需：开始前设置隔离工作区
+- **specops:writing-plans** - 创建本 skill 执行的计划
+- **specops:requesting-code-review** - 审查子 agent 使用的代码审查模板
+- **specops:finishing-a-development-branch** - 所有任务完成后收尾
+
+**子 agent 应使用：**
+- **specops:test-driven-development** - 子 agent 对每个任务遵循 TDD
+
+**替代工作流：**
+- **specops:executing-plans** - 用于并行会话而非同会话执行

package/.opencode/skills/subagent-driven-development/code-quality-reviewer-prompt.md

@@ -0,0 +1,20 @@
+# 代码质量审查子 Agent 提示词模板
+
+派发代码质量审查子 agent 时使用此模板。
+
+**目的：** 验证实现质量过关（干净、有测试、可维护）
+
+**仅在规格合规审查通过后才派发。**
+
+```
+task() 工具（specops:code-reviewer）：
+  使用 requesting-code-review/code-reviewer.md 中的模板
+
+  WHAT_WAS_IMPLEMENTED: [来自实现者的汇报]
+  PLAN_OR_REQUIREMENTS: [计划文件]中的任务 N
+  BASE_SHA: [任务开始前的提交]
+  HEAD_SHA: [当前提交]
+  DESCRIPTION: [任务摘要]
+```
+
+**代码审查者返回：** 优点、问题（严重/重要/次要）、评估结论

package/.opencode/skills/subagent-driven-development/implementer-prompt.md

@@ -0,0 +1,78 @@
+# 实现子 Agent 提示词模板
+
+派发实现子 agent 时使用此模板。
+
+```
+task() 工具（通用）：
+  description: "实现任务 N：[任务名称]"
+  prompt: |
+    你正在实现任务 N：[任务名称]
+
+    ## 任务描述
+
+    [计划中任务的完整文本 - 粘贴在这里，不要让子 agent 自己读文件]
+
+    ## 上下文
+
+    [场景设定：这个任务在整体中的位置、依赖关系、架构上下文]
+
+    ## 开始之前
+
+    如果你对以下内容有疑问：
+    - 需求或验收标准
+    - 方法或实现策略
+    - 依赖或假设
+    - 任务描述中任何不清楚的地方
+
+    **现在就问。** 开始工作前提出所有顾虑。
+
+    ## 你的任务
+
+    确认需求清楚后：
+    1. 严格按照任务规格实现
+    2. 编写测试（如果任务要求则遵循 TDD）
+    3. 验证实现可用
+    4. 提交你的工作
+    5. 自审（见下方）
+    6. 汇报结果
+
+    工作目录：[目录]
+
+    **工作过程中：** 如果遇到意外情况或不确定的地方，**提问**。
+    随时可以暂停并澄清。不要猜测或做假设。
+
+    ## 汇报前：自审
+
+    用全新的视角审视你的工作。问自己：
+
+    **完整性：**
+    - 我是否完整实现了规格中的所有内容？
+    - 是否遗漏了任何需求？
+    - 是否有未处理的边界情况？
+
+    **质量：**
+    - 这是我最好的工作吗？
+    - 命名是否清晰准确（反映功能而非实现方式）？
+    - 代码是否干净且可维护？
+
+    **纪律：**
+    - 是否避免了过度构建（YAGNI）？
+    - 是否只构建了被要求的内容？
+    - 是否遵循了代码库中的现有模式？
+
+    **测试：**
+    - 测试是否真正验证了行为（而非只是 mock 行为）？
+    - 如果要求了 TDD，是否遵循了？
+    - 测试是否全面？
+
+    如果自审中发现问题，在汇报前立即修复。
+
+    ## 汇报格式
+
+    完成后，汇报：
+    - 实现了什么
+    - 测试了什么以及测试结果
+    - 修改了哪些文件
+    - 自审发现（如有）
+    - 任何问题或顾虑
+```

package/.opencode/skills/subagent-driven-development/spec-reviewer-prompt.md

@@ -0,0 +1,61 @@
+# 规格合规审查子 Agent 提示词模板
+
+派发规格合规审查子 agent 时使用此模板。
+
+**目的：** 验证实现者是否构建了被要求的内容（不多不少）
+
+```
+task() 工具（通用）：
+  description: "审查任务 N 的规格合规性"
+  prompt: |
+    你正在审查一个实现是否符合其规格。
+
+    ## 被要求的内容
+
+    [任务需求的完整文本]
+
+    ## 实现者声称构建了什么
+
+    [来自实现者的汇报]
+
+    ## 关键：不要信任汇报
+
+    实现者完成得可疑地快。他们的汇报可能不完整、
+    不准确或过于乐观。你必须独立验证一切。
+
+    **不要：**
+    - 相信他们关于实现内容的说法
+    - 信任他们关于完整性的声明
+    - 接受他们对需求的解读
+
+    **要：**
+    - 阅读他们实际编写的代码
+    - 逐行对比实际实现与需求
+    - 检查他们声称已实现但实际缺失的部分
+    - 寻找他们未提及的额外功能
+
+    ## 你的任务
+
+    阅读实现代码并验证：
+
+    **缺失的需求：**
+    - 他们是否实现了所有被要求的内容？
+    - 是否有跳过或遗漏的需求？
+    - 是否有声称可用但实际未实现的内容？
+
+    **多余/不需要的工作：**
+    - 是否构建了未被要求的内容？
+    - 是否过度工程化或添加了不必要的功能？
+    - 是否添加了规格中没有的"锦上添花"内容？
+
+    **理解偏差：**
+    - 是否对需求的理解与预期不同？
+    - 是否解决了错误的问题？
+    - 是否实现了正确的功能但方式不对？
+
+    **通过阅读代码来验证，而非信任汇报。**
+
+    汇报：
+    - ✅ 符合规格（如果代码检查后一切匹配）
+    - ❌ 发现问题：[具体列出缺失或多余的内容，附带 file:line 引用]
+```

package/.opencode/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,296 @@
+---
+name: systematic-debugging
+description: 遇到任何bug、测试失败或意外行为时使用，在提出修复之前
+---
+
+# 系统化调试
+
+## 概述
+
+随机修复浪费时间，还会制造新 bug。快速补丁掩盖底层问题。
+
+**核心原则：** 在尝试修复之前，必须先找到根因。修复症状就是失败。
+
+**违反这个流程的字面意思就是违反调试的精神。**
+
+## 铁律
+
+```
+没有先做根因调查，就不能提出修复方案
+```
+
+如果你没有完成第一阶段，你不能提出修复方案。
+
+## 何时使用
+
+用于任何技术问题：
+- 测试失败
+- 生产环境 bug
+- 意外行为
+- 性能问题
+- 构建失败
+- 集成问题
+
+**尤其在以下情况使用：**
+- 时间压力下（紧急情况让猜测变得诱人）
+- "就一个快速修复"看起来很明显
+- 你已经尝试了多次修复
+- 上一次修复没有用
+- 你没有完全理解问题
+
+**不要跳过，即使：**
+- 问题看起来很简单（简单 bug 也有根因）
+- 你很赶时间（赶工保证返工）
+- 领导要求立刻修好（系统化比瞎折腾快）
+
+## 四个阶段
+
+你必须完成每个阶段才能进入下一个。
+
+### 第一阶段：根因调查
+
+**在尝试任何修复之前：**
+
+1. **仔细阅读错误信息**
+   - 不要跳过错误或警告
+   - 它们通常包含确切的解决方案
+   - 完整阅读堆栈跟踪
+   - 记下行号、文件路径、错误代码
+
+2. **稳定复现**
+   - 你能可靠地触发它吗？
+   - 确切的步骤是什么？
+   - 每次都会发生吗？
+   - 如果无法复现 → 收集更多数据，不要猜
+
+3. **检查最近的变更**
+   - 什么变更可能导致了这个问题？
+   - Git diff，最近的提交
+   - 新依赖、配置变更
+   - 环境差异
+
+4. **在多组件系统中收集证据**
+
+   **当系统有多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：**
+
+   **在提出修复之前，添加诊断埋点：**
+   ```
+   对每个组件边界：
+     - 记录进入组件的数据
+     - 记录离开组件的数据
+     - 验证环境/配置的传播
+     - 检查每一层的状态
+
+   运行一次收集证据，展示在哪里断裂
+   然后分析证据，定位失败的组件
+   然后调查那个特定组件
+   ```
+
+   **示例（多层系统）：**
+   ```bash
+   # 第 1 层：工作流
+   echo "=== 工作流中可用的密钥: ==="
+   echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
+
+   # 第 2 层：构建脚本
+   echo "=== 构建脚本中的环境变量: ==="
+   env | grep IDENTITY || echo "IDENTITY not in environment"
+
+   # 第 3 层：签名脚本
+   echo "=== 钥匙串状态: ==="
+   security list-keychains
+   security find-identity -v
+
+   # 第 4 层：实际签名
+   codesign --sign "$IDENTITY" --verbose=4 "$APP"
+   ```
+
+   **这揭示了：** 哪一层失败（密钥 → 工作流 ✓，工作流 → 构建 ✗）
+
+5. **追踪数据流**
+
+   **当错误深在调用栈中时：**
+
+   参见本目录中的 `root-cause-tracing.md` 了解完整的反向追踪技术。
+
+   **快速版本：**
+   - 错误值从哪里来？
+   - 谁用错误值调用了这里？
+   - 继续向上追踪直到找到源头
+   - 在源头修复，不是在症状处
+
+### 第二阶段：模式分析
+
+**在修复之前找到模式：**
+
+1. **找到可用的示例**
+   - 在同一代码库中找到类似的可用代码
+   - 什么类似的东西是能用的？
+
+2. **与参考实现对比**
+   - 如果在实现某个模式，完整阅读参考实现
+   - 不要略读，每一行都要读
+   - 在应用之前完全理解这个模式
+
+3. **识别差异**
+   - 能用的和坏的之间有什么不同？
+   - 列出每一个差异，不管多小
+   - 不要假设"那个不可能有影响"
+
+4. **理解依赖关系**
+   - 这需要哪些其他组件？
+   - 需要什么设置、配置、环境？
+   - 它做了什么假设？
+
+### 第三阶段：假设与测试
+
+**科学方法：**
+
+1. **形成单一假设**
+   - 清楚地陈述："我认为 X 是根因，因为 Y"
+   - 写下来
+   - 要具体，不要模糊
+
+2. **最小化测试**
+   - 做最小的可能变更来测试假设
+   - 一次只改一个变量
+   - 不要同时修复多个问题
+
+3. **继续之前先验证**
+   - 有效了？是 → 第四阶段
+   - 没有效？形成新假设
+   - 不要在上面叠加更多修复
+
+4. **当你不知道时**
+   - 说"我不理解 X"
+   - 不要假装知道
+   - 寻求帮助
+   - 做更多研究
+
+### 第四阶段：实施
+
+**修复根因，不是症状：**
+
+1. **创建失败测试用例**
+   - 最简单的可能复现
+   - 如果可能，写自动化测试
+   - 没有框架就写一次性测试脚本
+   - 修复之前必须有
+   - 使用 `specops:test-driven-development` skill 来写正确的失败测试
+
+2. **实施单一修复**
+   - 解决已识别的根因
+   - 一次只改一处
+   - 不要"顺便"改进
+   - 不要捆绑重构
+
+3. **验证修复**
+   - 测试现在通过了？
+   - 其他测试没有挂？
+   - 问题真的解决了？
+
+4. **如果修复没有用**
+   - 停下来
+   - 数一数：你已经尝试了多少次修复？
+   - 如果 < 3：回到第一阶段，用新信息重新分析
+   - **如果 ≥ 3：停下来，质疑架构（见下面第 5 步）**
+   - 不要在没有架构讨论的情况下尝试第 4 次修复
+
+5. **如果 3 次以上修复失败：质疑架构**
+
+   **表明架构问题的模式：**
+   - 每次修复都在不同地方暴露新的共享状态/耦合/问题
+   - 修复需要"大规模重构"才能实施
+   - 每次修复在其他地方产生新症状
+
+   **停下来，质疑根本问题：**
+   - 这个模式从根本上是合理的吗？
+   - 我们是不是"纯粹因为惯性在坚持"？
+   - 应该重构架构还是继续修复症状？
+
+   **在尝试更多修复之前与你的人类搭档讨论**
+
+   这不是假设失败，这是架构错误。
+
+## 危险信号 - 停下来，遵循流程
+
+如果你发现自己在想：
+- "先快速修一下，之后再调查"
+- "试试改一下 X 看看行不行"
+- "加多个改动，跑测试"
+- "跳过测试，我手动验证"
+- "大概是 X，让我修一下"
+- "我不完全理解但这可能有用"
+- "模式说的是 X 但我换个方式"
+- "主要问题是这些：[没有调查就列出修复方案]"
+- 在追踪数据流之前就提出解决方案
+- **"再试一次修复"（已经试了 2 次以上）**
+- **每次修复都在不同地方暴露新问题**
+
+**以上所有都意味着：停下来。回到第一阶段。**
+
+**如果 3 次以上修复失败：** 质疑架构（见第四阶段第 5 步）
+
+## 你的人类搭档暗示你做错了
+
+**注意这些纠正：**
+- "那不是没发生吗？" - 你假设了但没验证
+- "它会告诉我们...吗？" - 你应该添加证据收集
+- "别猜了" - 你在没有理解的情况下提出修复
+- "深入思考一下" - 质疑根本问题，不只是症状
+- "我们卡住了？"（沮丧） - 你的方法不管用
+
+**当你看到这些时：** 停下来。回到第一阶段。
+
+## 常见的自我合理化
+
+| 借口 | 现实 |
+|------|------|
+| "问题很简单，不需要流程" | 简单问题也有根因。流程对简单 bug 很快。 |
+| "紧急情况，没时间走流程" | 系统化调试比猜测-检查式瞎折腾更快。 |
+| "先试这个，然后再调查" | 第一次修复定下了模式。从一开始就做对。 |
+| "确认修复有效后再写测试" | 没测试的修复不可靠。先写测试来证明。 |
+| "同时修多个省时间" | 无法隔离哪个有效。会引入新 bug。 |
+| "参考太长了，我改编一下模式" | 部分理解保证出 bug。完整阅读。 |
+| "我看到问题了，让我修" | 看到症状 ≠ 理解根因。 |
+| "再试一次修复"（2 次以上失败后） | 3 次以上失败 = 架构问题。质疑模式，不要再修。 |
+
+## 快速参考
+
+| 阶段 | 关键活动 | 成功标准 |
+|------|----------|----------|
+| **1. 根因** | 阅读错误、复现、检查变更、收集证据 | 理解是什么以及为什么 |
+| **2. 模式** | 找到可用示例、对比 | 识别差异 |
+| **3. 假设** | 形成理论、最小化测试 | 确认或新假设 |
+| **4. 实施** | 创建测试、修复、验证 | Bug 解决，测试通过 |
+
+## 当流程揭示"没有根因"
+
+如果系统化调查揭示问题确实是环境相关、时序依赖或外部因素：
+
+1. 你已经完成了流程
+2. 记录你调查了什么
+3. 实施适当的处理（重试、超时、错误信息）
+4. 添加监控/日志用于未来调查
+
+**但是：** 95% 的"没有根因"情况是调查不充分。
+
+## 辅助技术
+
+这些技术是系统化调试的一部分，在本目录中可用：
+
+- **`root-cause-tracing.md`** - 通过调用栈反向追踪 bug，找到原始触发点
+- **`defense-in-depth.md`** - 找到根因后在多个层添加验证
+- **`condition-based-waiting.md`** - 用条件轮询替代任意超时
+
+**相关 skill：**
+- **specops:test-driven-development** - 用于创建失败测试用例（第四阶段，第 1 步）
+- **specops:verification-before-completion** - 在声称成功之前验证修复有效
+
+## 真实世界的影响
+
+来自调试实践：
+- 系统化方法：15-30 分钟修复
+- 随机修复方法：2-3 小时瞎折腾
+- 一次修复成功率：95% vs 40%
+- 引入新 bug：接近零 vs 常见