Menu
当你遇到任何 bug、错误、异常行为、测试失败时，必须在提出任何修复方案之前使用本 skill。触发词：bug、修 bug、报错、错误、异常、崩溃、不工作、出问题、坏了、不对、怎么报错了、帮我修一下、fix、error、crash、broken、doesn't work。即使 bug 看起来很简单也必须触发——简单 bug 同样需要系统化定位根因。禁止跳过任何步骤。禁止仅用单元测试代替真实验证。反例：纯问答、代码解释、功能开发（功能开发请用「智能体闭环开发」）。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use when 需要将代码变更推送到 GitHub、创建 PR、进行 code review、合并分支、使用 git worktree 隔离开发，或任何涉及 Git/GitHub 协作的操作。触发词：提交代码、push、PR、pull request、创建 PR、合并、merge、rebase、分支、branch、worktree、代码审查、code review、推送到远程、发起合入、审查这个 PR。不触发：纯本地只读查询（git log/git diff/git status/git branch -v 等不改变仓库状态的命令）。
Use when 需要编辑或审阅文本，去除 AI 生成痕迹使其听起来更自然、更像人类书写。触发词：去 AI 味、润色文本、改写、humanize、去机器人味、太像 AI 写的。不触发：纯技术文档审阅、代码审查、文本翻译。
| name | Bug修复与验证 |
| description | 当你遇到任何 bug、错误、异常行为、测试失败时，必须在提出任何修复方案之前使用本 skill。触发词：bug、修 bug、报错、错误、异常、崩溃、不工作、出问题、坏了、不对、怎么报错了、帮我修一下、fix、error、crash、broken、doesn't work。即使 bug 看起来很简单也必须触发——简单 bug 同样需要系统化定位根因。禁止跳过任何步骤。禁止仅用单元测试代替真实验证。反例：纯问答、代码解释、功能开发（功能开发请用「智能体闭环开发」）。 |
| allowed-tools | ["Read","Write","Edit","AskUserQuestion","Agent","Glob","Grep","Bash","PowerShell","Skill"] |
本 skill 和「myworkflow:智能体闭环开发」是平行通道，互斥触发：
| 维度 | Bug修复与验证（本 skill） | 智能体闭环开发 |
|---|---|---|
| 通道定位 | Bug 专用通道 | 功能开发通道 |
| 入口 | 用户报告了一个异常/bug/错误 | 用户提出了一个功能需求/改动需求 |
| 谁提问 | 本 skill——步骤 ① 硬门禁引导用户明确细节 | 阶段 1 需求理解——仅在模糊时追问 |
| 谁定位根因 | 委托给「myworkflow:根因定位与全面排查」——本 skill 不自己做 | 不涉及（功能开发没有"根因"概念） |
| 谁修代码 | 子智能体——在隔离 worktree 中并行修复 | 闭环开发自己执行 |
| 谁验证 | 步骤 ④ 审查 + 子智能体的自验证 | 阶段 4 真实验证 |
| 循环机制 | 审查不通过 → 回到步骤 ③（最多 3 轮） | 验证不通过 → 回到对应阶段（最多 3 轮） |
| Skill | 关系 | 调用时机 |
|---|---|---|
| 根因定位与全面排查 | 核心依赖——步骤 ② 强制调用 | 用户细节收集完毕后，委托深度根因定位和全面扫描 |
| 任务拆解与派发 | 按需调用——步骤 ③ 复杂多 bug 场景 | 当排查报告发现 ≥2 个独立 bug 且修复涉及跨模块协调时 |
| 轻量级派发 | 按需调用——步骤 ③ 简单多 bug 场景 | 当排查报告发现 ≥2 个独立 bug 且每个修复简单（单文件/单函数）时 |
| 智能体闭环开发 | 互斥——不调用 | Bug 修复走本 skill，功能开发走闭环开发。两者是平行通道 |
核心原则：不填完细节不排查，不找到根因不动手。 本 skill 是编排者——不自己排查根因（委托给排查 skill），不自己修代码（派发子智能体）。职责：收细节 → 委托排查 → 派发修复 → 审查 → 循环。
确保每次 bug 修复走完整五步闭环：① 引导用户明确细节（硬门禁）→ ② 调用排查 skill 定位根因 → ③ 并行派发修复 → ④ 审查每个修复 → ⑤ 不通过则循环。
闭环总览：
┌──────────────────────────────────────────────────────────────────────────────┐
│ Bug 修复与验证闭环（五步） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 步骤 ① │ │ 步骤 ② │ │ 步骤 ③ │ │ 步骤 ④ │ │ 步骤 ⑤ │ │
│ │ │ │ │ │ │ │ │ │ │ │
│ │ 引导用户 ├──►│ 调用排查 ├──►│ 并行派发 ├──►│ 审查 ├──►│ 循环 │ │
│ │ 填细节 │ │ skill │ │ 修复 │ │ │ │ │ │
│ │ (硬门禁) │ │ │ │ │ │ │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ └────┬─────┘ └────┬─────┘ │
│ ▲ │ │ │
│ │ │ 审查不通过 │ │
│ │ └───────────────┘ │
│ │ 回到步骤 ③ │
│ │ │
│ │ 审查全部通过 │
│ │ │ │
│ │ ▼ │
│ │ ┌──────────┐ │
│ │ │ ✅ 交付 │ │
│ │ └──────────┘ │
│ │ │
│ └───── 步骤 ⑤ 3 轮后仍未通过 → 升级给用户，请求人工介入 │
└──────────────────────────────────────────────────────────────────────────────┘
这是本 skill 的第一道关卡。 不接收"页面坏了""登录不上去"这类模糊描述。用户必须提供足够的细节，排查才能有的放矢。不填完不进入步骤 ②。
收到用户的 bug 报告后，立即展示以下 5 项必填信息清单，逐项标注当前状态：
| # | 信息项 | 说明 | 状态 |
|---|---|---|---|
| 1 | 复现步骤 | 精确到每一步操作。从"打开应用"开始，到"bug 出现"结束 | ❓待填写 |
| 2 | 预期行为 vs 实际行为 | 你期望发生什么？实际发生了什么？ | ❓待填写 |
| 3 | 环境信息 | 操作系统、应用版本、浏览器/运行时版本、相关配置 | ❓待填写 |
| 4 | 日志/截图/错误信息 | 完整的错误消息（原文，非转述）、堆栈跟踪、截图 | ❓待填写 |
| 5 | 出现频率 | 每次必现 / 偶发（大概频率）/ 只在特定条件下出现 | ❓待填写 |
对每一项缺失或不完整的信息，使用 AskUserQuestion 工具发起提问。规则：
逐项收集策略：
💡 以下为参考话术，实际使用时应根据用户已提供的信息灵活调整，不要机械套用。
第 1 项（复现步骤）——优先收集：
问题：请描述复现步骤，从打开应用开始，每步写清楚你做了什么操作。
提示：例如"1. 打开 https://example.com/login 2. 输入邮箱 test@example.com 3. 点击'登录'按钮 4. 页面显示'网络错误'"
如果用户实在无法精确复现，描述最近一次遇到 bug 时你在做什么。
第 2 项（预期 vs 实际）：
问题：你期望发生什么？实际发生了什么？
选项：
- "我期望 [A]，但实际 [B]"（请在回复中补充 A 和 B）
- "我不确定预期行为应该是什么"
第 3 项（环境信息）：
问题：bug 出现在什么环境？
选项（可多选）：
- 操作系统：Windows / macOS / Linux
- 浏览器（如适用）：Chrome / Firefox / Safari / Edge
- 环境类型：本地开发 (localhost) / 测试环境 (staging) / 生产环境
- 我会在回复中补充版本号和具体配置
第 4 项（日志/错误信息）：
问题：有没有错误信息、日志或截图？
选项：
- "有，我会贴完整的错误消息和堆栈跟踪"
- "有截图，但我无法粘贴文字——我会描述截图内容"
- "没有保存错误信息，但我记得大概内容——我会描述"
- "没有任何错误信息——bug 的表现是 [静默错误/行为异常/卡住不动]"
第 5 项（出现频率）：
问题：bug 出现的频率是？
选项：
- "每次必现——只要按复现步骤操作就一定出现"
- "偶发——大概 [N] 次中有 [M] 次出现"（请补充 N 和 M）
- "只在特定条件下出现——条件是 [描述条件]"
- "只出现过一次，还没试过第二次"
已提供信息的补充追问：
如果用户一开始就贴了错误日志，但信息不完整（如堆栈跟踪被截断、只贴了一行错误消息），追问：
你贴的错误信息中 [具体缺失部分] 不完整。完整的堆栈跟踪通常包含更多行，特别是 "Caused by" 或更上层的调用链。能否提供完整版本？如果没有，请确认。
在所有 5 项都收到回复后，执行质量检查：
| 质量等级 | 判定标准 | 处理 |
|---|---|---|
| ✅ 通过 | 所有 5 项都有足够具体的信息。复现步骤可操作、错误信息原文可用、环境信息明确 | → 进入步骤 ② |
| ⚠️ 勉强通过 | 1-2 项不够具体（如"环境不确定"、"复现步骤大致如上"），但核心信息（错误信息 + 预期vs实际）是可用的 | → 标注缺失项为"待排查补充"，进入步骤 ② |
| ❌ 不通过 | 核心信息缺失（没有错误信息且无法描述实际行为、复现步骤完全不知道） | → 继续追问，直到至少达到 ⚠️ 级别 |
硬门禁规则：
步骤 ① 出口条件：
本步骤自动委托「myworkflow:根因定位与全面排查」执行，不需要用户手动调用。
将步骤 ① 收集的所有细节打包，委托给「myworkflow:根因定位与全面排查」进行深度根因定位和全面扫描。本 skill 不自己做排查——排查是排查 skill 的专业领域。
将步骤 ① 收集的 5 项信息 + 上下文整理为结构化输入：
## 排查委托（由 Bug修复与验证 步骤 ① 产出）
### Bug 症状
- **复现步骤**：[步骤 ① 第 1 项]
- **预期行为**：[步骤 ① 第 2 项 — 预期]
- **实际行为**：[步骤 ① 第 2 项 — 实际]
- **环境信息**：[步骤 ① 第 3 项]
- **错误信息/日志**：[步骤 ① 第 4 项 — 原文]
- **出现频率**：[步骤 ① 第 5 项]
### 已知缺失
- [步骤 ① 标注为 ⚠️ 的缺失项列表]
### 项目上下文
- 项目根目录：[当前工作目录]
- 相关线索：[如果用户提到了具体文件/模块/功能名称，一并附上]
请执行完整的 6 阶段排查流程（症状收集→5 Whys→数据流追踪→假设验证→全面扫描→输出交接），
返回排查报告。特别关注：
- 根因因果链（至少 Why 3）
- 所有受影响代码位置的分类清单（🔴🟠🟡🔵）
- 交接清单（供步骤 ③ 修复使用）
使用 Skill 工具调用「myworkflow:根因定位与全面排查」，将打包后的排查输入作为 args 传入：
Skill(skill="myworkflow:根因定位与全面排查", args="[上面格式化的排查委托]")
排查 skill 将走完其完整的 6 阶段闭环，产出包含 7 个章节的排查报告。
排查 skill 返回后，从其报告中提取以下关键信息：
| 提取内容 | 来源（排查报告章节） | 用途 |
|---|---|---|
| 确认的根因（一句话） | 第 4 节：根因确认 | 步骤 ③ 每个子智能体的修复目标 |
| 🔴 同类 bug（确认）— 位置清单 | 第 5 节：全面扫描结果 | 步骤 ③ 必须修复的 bug 列表 |
| 🟠 同类 bug（高概率）— 位置清单 | 第 5 节：全面扫描结果 | 步骤 ③ 强烈建议修复的 bug 列表 |
| 建议修复方式 | 第 5 节：详细位置清单 | 步骤 ③ 每个子智能体的修复方向指引 |
| 回归检查清单 | 第 6 节：交接清单 | 步骤 ④ 审查时的回归验证依据 |
| 已知局限 | 第 7 节：已知局限 | 步骤 ④ 审查时注意无法验证的部分 |
如果排查 skill 无法确认根因（可信度为 🟡 中或 🔴 低）→ 将排查报告中的"被推翻的假设"和"已知局限"展示给用户，询问是否：
- 接受当前最佳假设，带着不确定性继续修复
- 用户补充更多信息后重新排查
- 将问题标记为"需人工深入调查"
步骤 ② 出口条件：
将排查报告中的 🔴 和 🟠 类 bug 派发给子智能体并行修复。每个子智能体在隔离的 worktree 中独立工作，互不干扰。本 skill 不自己修代码。
从步骤 ② 提取的位置清单中，筛选出需要本次修复的 bug：
| 优先级 | 分类 | 处理策略 |
|---|---|---|
| 必须修 | 🔴 同类 bug（确认） | 全部纳入本次修复 |
| 强烈建议修 | 🟠 同类 bug（高概率） | 全部纳入本次修复 |
| 可选 | 🟡 相似 bug（中概率） | 询问用户是否一并修复；默认纳入但可排除 |
| 记录跟踪 | 🔵 潜在风险（低概率） | 不修复——记录在最终报告中，建议用户建独立 issue |
向用户展示修复任务清单，确认范围后进入下一步。
按以下规则将 bug 分组：
| 分组规则 | 说明 |
|---|---|
| 同文件/同模块 | 同一文件或同一模块内的多个 bug → 归入同一个子智能体（避免两个子智能体改同一文件产生冲突） |
| 同调用链 | 同一调用链上的多个 bug → 归入同一个子智能体（修复可能相互影响） |
| 独立文件/独立模块 | 不同文件、不同模块、无依赖关系 → 分别派发不同子智能体（可并行） |
分组结果示例：
组 1（auth 模块）：auth/login.ts:47, auth/register.ts:32, auth/middleware.ts:18
组 2（user 模块）：user/profile.ts:89
组 3（admin 模块）：admin/users.ts:123
→ 3 个子智能体并行修复
为每个分组编写一份修复 prompt，包含：
## Bug 修复任务
### 要修复的 bug
**根因**：[排查报告第 4 节 —— 一句话根因描述]
**修复清单**：
| # | 文件:行号 | 问题 | 建议修复方式 |
|---|----------|------|-------------|
| 1 | [路径:行号] | [一句话描述] | [排查报告中的建议] |
| 2 | ... | ... | ... |
### 修复约束
- **只修复上述清单中的 bug，不夹带重构、优化或范围外的改动**
- **修复根因而非症状**——对照根因描述，确保你的修复从根因层面解决问题
- **修改完每个文件后自检**：改动是否最小化？是否引入了新问题？
- **验证你的修复**：
- 对于可运行的项目：实际运行相关测试或用例，确认 bug 已消失
- 检查所有受影响调用方的行为未退化
- 确保不引入新的类型错误、lint 错误、编译错误
### 排查报告参考
[附上排查报告的关键章节摘要：根因因果链 + 数据流分析 + 该组 bug 的详细位置描述]
### 产出要求
修复完成后，返回以下信息：
1. 修改了哪些文件、做了什么改动（每个文件的具体变更说明）
2. 验证方式和验证结果（实际的运行输出/测试结果，不可用"应该没问题"代替）
3. 任何未解决的疑虑或已知局限
根据分组数量选择派发方式：
| 情况 | 派发方式 |
|---|---|
| 只有 1 组 | 在当前会话中直接使用 Agent 工具派发单个子智能体（isolation: "worktree"） |
| 2-3 组，均为简单修复 | 并行使用 Agent 工具派发多个子智能体（每个 isolation: "worktree"）。如「myworkflow:轻量级派发」skill 可用则优先使用 |
| 2+ 组，含复杂修复（跨模块协调、需要接口合约） | 优先使用「myworkflow:任务拆解与派发」skill（如可用）。不可用时降级为并行 Agent 调用 |
每个子智能体应尽量使用 worktree 隔离。使用 Agent 工具时传入 isolation: "worktree" 参数，确保各修复互不干扰。
⚠️ worktree 降级：如果项目不是 git 仓库或无 git 历史，worktree 隔离不可用。此时降级为：在同一会话中顺序派发子智能体（无需隔离），但在审查阶段（步骤④）需特别关注文件冲突。在最终报告中标注"无 worktree 隔离，已通过审查确认无文件冲突"。
并行派发示例（多个 Agent 工具调用放在同一消息中）：
Agent(subagent_type="general-purpose", description="修复 auth 模块 bug", prompt="[组1的修复prompt]", isolation="worktree")
Agent(subagent_type="general-purpose", description="修复 user 模块 bug", prompt="[组2的修复prompt]", isolation="worktree")
Agent(subagent_type="general-purpose", description="修复 admin 模块 bug", prompt="[组3的修复prompt]", isolation="worktree")
所有子智能体完成后，收集每个子智能体的产出：
步骤 ③ 出口条件：
逐个审查每个子智能体的修复结果。不因为"看起来差不多"就放过——每个修复必须经得起以下三个问题的拷问。
对每个子智能体的每个修复，回答以下三个问题：
问题 1：修复是否真正解决了根因（而非掩盖症状）？
| 检查项 | 通过标准 |
|---|---|
| 修复位置是否与排查报告中的根因一致？ | 修复在根因层面（因果链最深标注层），而非在症状层面 |
| 如果修复不在根因层，是否会导致 bug 在其他条件下复发？ | 不会——修复消除了根因条件，而非仅处理触发条件 |
| 修复后，因果链中的上层症状是否全部消失？ | 是——可以从 Why 1 到 Why N-1 逐层验证 |
问题 2：是否引入了新问题？
| 检查项 | 通过标准 |
|---|---|
| 改动是否最小化（没有夹带重构、优化、格式化）？ | 改动仅涉及修复根因的必要代码，无 scope creep |
| 改动是否破坏了已有的类型/接口约定？ | 类型检查通过，接口签名未变（或变更了所有调用方） |
| 改动是否引入了新的 edge case（空值、边界、并发）？ | 新的代码路径对所有输入都有合理处理 |
| 是否有遗漏的受影响调用方？ | Grep 搜索被修改函数/类型的所有引用，逐一确认 |
问题 3：是否覆盖了排查报告中标记的所有影响范围？
| 检查项 | 通过标准 |
|---|---|
| 🔴 和 🟠 类 bug 是否全部修复？ | 排查报告中的每一个 🔴🟠 位置都有对应的修复 |
| 排查报告中的回归检查清单是否逐项验证？ | 每一项都有验证结果（✅ 或明确的不适用说明） |
| 🟡 类 bug 是否按用户决定处理？ | 已修复 或 已记录待后续处理 |
对每个子智能体的修复结果做出判定：
| 判定 | 标准 | 处理 |
|---|---|---|
| ✅ 通过 | 三问全部通过，验证证据充分 | 该修复合格，进入步骤 ⑤ |
| ❌ 不通过——需返工 | 三问中任一不通过，但问题明确可在子智能体层面修复 | 进入步骤 ⑤ 循环，回到步骤 ③ 对该组重新修复 |
| ❌ 不通过——需重新排查 | 修复过程中发现根因假设有误，或排查报告遗漏了关键信息 | 进入步骤 ⑤ 循环，回到步骤 ② 重新排查 |
审查记录模板：
## 审查记录 — [子智能体/分组名称]
### 修复概要
- 修复文件：[列表]
- 修复内容摘要：[一段话]
### 三问审查
**问题 1：是否真正解决根因？**
- [回答 + 证据]
- 判定：✅ / ❌
**问题 2：是否引入新问题？**
- 改动最小化：[是/否 — 如否则列出非必要的改动]
- 类型/接口：[未变/已变但所有调用方已更新/有问题]
- edge case：[已覆盖/有遗漏 — 具体说明]
- 调用方覆盖：[已全部检查/有遗漏 — 具体文件]
- 判定：✅ / ❌
**问题 3：是否覆盖所有影响范围？**
- 🔴🟠 修复覆盖：[N/N]
- 回归检查：[逐项结果]
- 判定：✅ / ❌
### 总体判定
- ✅ 通过 / ❌ 不通过（需返工 / 需重新排查）
步骤 ④ 出口条件：
任何修复在步骤 ④ 审查中不通过 → 回到对应步骤重新来。3 轮后仍未全部通过 → 升级给用户，请求人工介入。
步骤 ④ 审查结果
│
├── 全部 ✅ 通过 → 🎉 完成。向用户报告最终结果
│
└── 存在 ❌ 不通过
│
▼
不通过原因？
│
├── "需返工"（问题明确，修复方向正确但实现有问题）
│ → 回到步骤 ③：将该组的修复 prompt 更新
│ （加入审查发现的具体问题 + 修正要求），重新派发
│
├── "需重新排查"（根因假设有误、排查遗漏、或发现新的影响因素）
│ → 回到步骤 ②：将新发现的信息传给排查 skill，
│ 请求补充排查或修正根因假设
│
└── "需补充信息"（发现用户最初提供的信息有误或不完整）
→ 回到步骤 ①：对具体缺失项追加提问
| 典型场景 | 严重程度 | 回退到 |
|---|---|---|
| 修复代码有 bug（逻辑错误、typo、漏了边界条件） | 小——返工 | 步骤 ③ |
| 修复后类型检查失败、import 路径错误 | 小——返工 | 步骤 ③ |
| 子智能体只修了症状没修根因（审查问题 1 不通过） | 小——返工 | 步骤 ③ |
| 子智能体夹带了范围外的重构/优化 | 小——返工 | 步骤 ③ |
| 修复后发现新的受影响位置（排查报告遗漏） | 中——补充排查 | 步骤 ② |
| 根因假设被修复过程推翻（"修了 A 但 bug 还在"） | 中——重新排查 | 步骤 ② |
| 用户最初提供的复现步骤有误 | 中——补充信息 | 步骤 ① |
| 两个子智能体的修复产生了冲突 | 中——重新分组 | 步骤 ③ |
| 排查报告的根因判断在修复过程中被证伪 | 大——重新排查 | 步骤 ② |
| 用户说"不对，我说的 bug 不是这个意思" | 大——重新理解 | 步骤 ① |
升级报告模板（3 轮后仍未通过时使用）：
## 升级报告 —— 3 轮修复仍未全部通过
### 当前状态
- 总修复数：[N]
- 已通过：[M]（列表）
- 仍未通过：[K]（列表 + 每轮尝试的内容和失败原因）
### 失败分析
- [仍未通过的 bug]：
- 第 1 轮：[尝试了什么] → [为什么失败]
- 第 2 轮：[尝试了什么] → [为什么失败]
- 第 3 轮：[尝试了什么] → [为什么失败]
- 推测原因：[根因假设问题 / 架构限制 / 信息不足 / 其他]
### 建议
- [具体建议——例如：需要用户确认某个假设、建议重新设计某模块、建议引入更专业的排查手段]
请审核以上信息，指示下一步方向。
循环记录模板：
## 第 N 轮修复（追加在审查记录末尾）
### 上一轮不通过的问题
- [子智能体/分组]：[具体不通过原因]（审查问题 [1/2/3] 不通过）
### 本轮调整
- 回退到步骤 [①/②/③]
- 调整内容：[更新的修复 prompt / 补充的排查信息 / 追加的用户提问]
### 本轮审查结果
- [子智能体/分组]：审查三问重新判定 → ✅/❌
步骤 ⑤ 出口条件：
| 你在做什么 | 看哪个步骤 |
|---|---|
| 用户刚报告了一个 bug，描述模糊 | 步骤 ①：硬门禁——引导用户填完 5 项细节 |
| 用户已经提供了完整信息 | 步骤 ① 快速过质量检查 → 步骤 ② |
| 细节已收集，需要找到根因 | 步骤 ②：委托「myworkflow:根因定位与全面排查」 |
| 排查报告已返回，准备修 | 步骤 ③：整理修复清单 → 分组 → 派发子智能体 |
| 子智能体修完了，需要检查质量 | 步骤 ④：审查三问 |
| 审查发现有问题 | 步骤 ⑤：判断循环——回到步骤 ①/②/③ |
| 同一个 bug 修了 3 轮还不行 | 步骤 ⑤：升级报告——请用户介入 |
| 不确定应该自己修还是派发 | 永远派发——本 skill 是编排者，不自己修代码 |
| 错误 | 为什么错 | 正确做法 |
|---|---|---|
| 用户描述模糊就直接开始排查 | 信息不足 → 排查方向可能全错 | 步骤 ① 硬门禁——不填完不进入步骤 ② |
| 跳过步骤 ② 直接修 | 没找到根因就修 = 修的是症状 | 必须委托排查 skill 确认根因后再修 |
| 步骤 ③ 自己动手修代码 | 本 skill 是编排者，不是执行者 | 派发子智能体在隔离 worktree 中修复 |
| 多个 bug 串行修复（一个修完再修下一个） | 浪费时间——独立 bug 可以并行 | 步骤 ③ 第二步按模块分组，第三步并行派发 |
| 审查时只看代码 diff，不验证三问 | 可能放过了"看起来对但没解决根因"的修复 | 每个修复必须逐一回答审查三问 |
| 审查不通过但手动改几行代码跳过循环 | 手动改 = 未经子智能体验证流程 = 可能引入新 bug | 回到步骤 ③ 重新派发修复 |
| 3 轮循环后还在继续死循环 | 用户不知道你在死循环 | 3 轮上限——第 3 轮后升级给用户 |
| 审查通过但没实际运行验证 | "代码看起来对"不等于"bug 真的消失了" | 步骤 ④ 审查要求查看子智能体的实际验证输出 |
| 用户说"直接修，别走流程"就跳过步骤 ① | 没有细节就没有方向 | 即使简化，步骤 ① 的核心 3 项（复现步骤、错误信息、预期vs实际）不可跳过 |
| 排查报告发现 5 个 bug 但只修了 1 个 | 🔴🟠 类 bug 不修 = 修好一个、还有四个等着复发 | 步骤 ③ 第一步——🔴🟠 全部纳入修复范围 |