| 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"] |
触发场景
必须触发（满足任意一条）
- 用户说"有个 bug""修一下""报错了""不工作""出问题了""帮我看看这个错误"
- 用户描述了异常行为（预期 X 但实际 Y）
- 用户贴了一段错误日志、堆栈跟踪、测试失败输出
- 用户说"怎么崩溃了""为什么不对""帮我排查一下"
- 任何涉及修复现有代码缺陷的请求——无论 bug 大小
- 测试失败、构建失败、运行时异常
- 用户说"fix""error""crash""broken""doesn't work""bug"
不触发（反例）
- 纯新增功能（用「myworkflow:智能体闭环开发」）
- 重构/改进（无 bug，用「myworkflow:智能体闭环开发」）
- 代码解释、问答、搜索
- 用户明确说"不是 bug，是功能需求"
与「myworkflow:智能体闭环开发」的分工
本 skill 和「myworkflow:智能体闭环开发」是平行通道，互斥触发：
| 维度 | Bug修复与验证（本 skill） | 智能体闭环开发 |
|---|
| 通道定位 | Bug 专用通道 | 功能开发通道 |
| 入口 | 用户报告了一个异常/bug/错误 | 用户提出了一个功能需求/改动需求 |
| 谁提问 | 本 skill——步骤 ① 硬门禁引导用户明确细节 | 阶段 1 需求理解——仅在模糊时追问 |
| 谁定位根因 | 委托给「myworkflow:根因定位与全面排查」——本 skill 不自己做 | 不涉及（功能开发没有"根因"概念） |
| 谁修代码 | 子智能体——在隔离 worktree 中并行修复 | 闭环开发自己执行 |
| 谁验证 | 步骤 ④ 审查 + 子智能体的自验证 | 阶段 4 真实验证 |
| 循环机制 | 审查不通过 → 回到步骤 ③（最多 3 轮） | 验证不通过 → 回到对应阶段（最多 3 轮） |
与本 skill 相关的其他 skill
| Skill | 关系 | 调用时机 |
|---|
| 根因定位与全面排查 | 核心依赖——步骤 ② 强制调用 | 用户细节收集完毕后，委托深度根因定位和全面扫描 |
| 任务拆解与派发 | 按需调用——步骤 ③ 复杂多 bug 场景 | 当排查报告发现 ≥2 个独立 bug 且修复涉及跨模块协调时 |
| 轻量级派发 | 按需调用——步骤 ③ 简单多 bug 场景 | 当排查报告发现 ≥2 个独立 bug 且每个修复简单（单文件/单函数）时 |
| 智能体闭环开发 | 互斥——不调用 | Bug 修复走本 skill，功能开发走闭环开发。两者是平行通道 |
触发边界
- 用户描述的问题既有 bug 又有功能需求 → 先走本 skill 修 bug，再走「myworkflow:智能体闭环开发」做功能
- 用户只说"帮我看看这个"且上下文不足 → 默认触发本 skill（先排查是否为 bug）
- 本 skill 和「myworkflow:智能体闭环开发」互斥触发——不会同时激活
- 步骤 ③ 派发的子智能体不应递归调用本 skill——它们接收的已经是明确的修复任务
必需要素
- 用户的 bug 描述（症状、错误信息、复现步骤，至少其一——步骤 ① 会强制补充至完整）
推荐要素
- 完整的错误堆栈/日志
- 稳定复现步骤
- 最近变更记录（git log / git diff）
- 相关测试文件路径
前置强制步骤
核心原则：不填完细节不排查，不找到根因不动手。 本 skill 是编排者——不自己排查根因（委托给排查 skill），不自己修代码（派发子智能体）。职责：收细节 → 委托排查 → 派发修复 → 审查 → 循环。
- 硬门禁——用户必须填完 5 项细节：复现步骤、预期 vs 实际行为、环境信息、日志/错误信息、出现频率。不填完不进入步骤 ②
- 禁止跳过排查：必须先委托「myworkflow:根因定位与全面排查」找到根因，才能进入修复。不允许"这个简单，我直接修"
- 轻量分析例外：根因一目了然的 bug（语法错误、类型不匹配、缺 import、拼写错误）→ 允许跳过委托，由本 skill 在步骤 ② 直接完成轻量根因确认（Grep 定位、Read 确认上下文），标注"根因自明，已跳过深度排查"并附理由。逻辑错误、行为异常、性能问题、竞态问题不可跳过
- 禁止自己动手修代码：修复由隔离 worktree 中的子智能体执行。本 skill 只编排、审查和循环控制
目标
确保每次 bug 修复走完整五步闭环：① 引导用户明确细节（硬门禁）→ ② 调用排查 skill 定位根因 → ③ 并行派发修复 → ④ 审查每个修复 → ⑤ 不通过则循环。
执行流程
闭环总览：
┌──────────────────────────────────────────────────────────────────────────────┐
│ Bug 修复与验证闭环（五步） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 步骤 ① │ │ 步骤 ② │ │ 步骤 ③ │ │ 步骤 ④ │ │ 步骤 ⑤ │ │
│ │ │ │ │ │ │ │ │ │ │ │
│ │ 引导用户 ├──►│ 调用排查 ├──►│ 并行派发 ├──►│ 审查 ├──►│ 循环 │ │
│ │ 填细节 │ │ skill │ │ 修复 │ │ │ │ │ │
│ │ (硬门禁) │ │ │ │ │ │ │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ └────┬─────┘ └────┬─────┘ │
│ ▲ │ │ │
│ │ │ 审查不通过 │ │
│ │ └───────────────┘ │
│ │ 回到步骤 ③ │
│ │ │
│ │ 审查全部通过 │
│ │ │ │
│ │ ▼ │
│ │ ┌──────────┐ │
│ │ │ ✅ 交付 │ │
│ │ └──────────┘ │
│ │ │
│ └───── 步骤 ⑤ 3 轮后仍未通过 → 升级给用户，请求人工介入 │
└──────────────────────────────────────────────────────────────────────────────┘
步骤 ①：引导用户明确细节（硬门禁）
这是本 skill 的第一道关卡。 不接收"页面坏了""登录不上去"这类模糊描述。用户必须提供足够的细节，排查才能有的放矢。不填完不进入步骤 ②。
第一步：展示信息清单
收到用户的 bug 报告后，立即展示以下 5 项必填信息清单，逐项标注当前状态：
| # | 信息项 | 说明 | 状态 |
|---|
| 1 | 复现步骤 | 精确到每一步操作。从"打开应用"开始，到"bug 出现"结束 | ❓待填写 |
| 2 | 预期行为 vs 实际行为 | 你期望发生什么？实际发生了什么？ | ❓待填写 |
| 3 | 环境信息 | 操作系统、应用版本、浏览器/运行时版本、相关配置 | ❓待填写 |
| 4 | 日志/截图/错误信息 | 完整的错误消息（原文，非转述）、堆栈跟踪、截图 | ❓待填写 |
| 5 | 出现频率 | 每次必现 / 偶发（大概频率）/ 只在特定条件下出现 | ❓待填写 |
第二步：逐项收集（使用 AskUserQuestion）
对每一项缺失或不完整的信息，使用 AskUserQuestion 工具发起提问。规则：
- 每次只问一项（避免选项框过多导致用户跳过）
- 能用选项的尽量用选项（减少用户打字负担）
- 必须追问到足够具体——"登录页面"不够，要精确到"哪个 URL、点击哪个按钮、输入什么数据"
逐项收集策略：
💡 以下为参考话术，实际使用时应根据用户已提供的信息灵活调整，不要机械套用。
第 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实际）是可用的 | → 标注缺失项为"待排查补充"，进入步骤 ② |
| ❌ 不通过 | 核心信息缺失（没有错误信息且无法描述实际行为、复现步骤完全不知道） | → 继续追问，直到至少达到 ⚠️ 级别 |
硬门禁规则：
- 不通过 → 绝不进入步骤 ②。追问直到通过或用户明确表示无法提供更多信息（此时降级为 ⚠️ 勉强通过）
- 用户急躁（"直接帮我查吧，我不知道这些"）→ 回复："我理解你的着急。但没有复现步骤和错误信息，排查就像大海捞针。请至少告诉我：你当时在做什么操作？看到了什么现象？"
- 用户跳过提问（直接选了选项但不回复具体内容）→ 追问具体内容，不放过
步骤 ① 出口条件：
步骤 ②：调用排查 skill
本步骤自动委托「myworkflow:根因定位与全面排查」执行，不需要用户手动调用。
将步骤 ① 收集的所有细节打包，委托给「myworkflow:根因定位与全面排查」进行深度根因定位和全面扫描。本 skill 不自己做排查——排查是排查 skill 的专业领域。
第一步：打包排查输入
将步骤 ① 收集的 5 项信息 + 上下文整理为结构化输入：
## 排查委托（由 Bug修复与验证 步骤 ① 产出）
### Bug 症状
- **复现步骤**：[步骤 ① 第 1 项]
- **预期行为**：[步骤 ① 第 2 项 — 预期]
- **实际行为**：[步骤 ① 第 2 项 — 实际]
- **环境信息**：[步骤 ① 第 3 项]
- **错误信息/日志**：[步骤 ① 第 4 项 — 原文]
- **出现频率**：[步骤 ① 第 5 项]
### 已知缺失
- [步骤 ① 标注为 ⚠️ 的缺失项列表]
### 项目上下文
- 项目根目录：[当前工作目录]
- 相关线索：[如果用户提到了具体文件/模块/功能名称，一并附上]
请执行完整的 6 阶段排查流程（症状收集→5 Whys→数据流追踪→假设验证→全面扫描→输出交接），
返回排查报告。特别关注：
- 根因因果链（至少 Why 3）
- 所有受影响代码位置的分类清单（🔴🟠🟡🔵）
- 交接清单（供步骤 ③ 修复使用）
第二步：调用排查 skill
使用 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 → 归入同一个子智能体（避免两个子智能体改同一文件产生冲突） |
| 同调用链 | 同一调用链上的多个 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
为每个分组编写一份修复 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 轮完整循环：从步骤 ⑤ 回到步骤 ①/②/③ 并再次走完步骤 ④ 算 1 轮。步骤 ③ 内部的子智能体重试（同一个修复 prompt 重新执行）不计入轮次
- 3 轮后仍未全部通过 → 升级：
- 向用户展示当前状态：哪些通过了、哪些未通过、每轮尝试了什么、为什么失败
- 明确请求人工介入——可能是架构问题、排查 skill 的局限、或需要更深入的领域知识
- 给出建议的下一步方向（而非只说"我修不好"）
- 每次循环追加记录：在审查记录末尾追加"第 N 轮修复"章节
升级报告模板（3 轮后仍未通过时使用）：
## 升级报告 —— 3 轮修复仍未全部通过
### 当前状态
- 总修复数：[N]
- 已通过：[M]（列表）
- 仍未通过：[K]（列表 + 每轮尝试的内容和失败原因）
### 失败分析
- [仍未通过的 bug]：
- 第 1 轮：[尝试了什么] → [为什么失败]
- 第 2 轮：[尝试了什么] → [为什么失败]
- 第 3 轮：[尝试了什么] → [为什么失败]
- 推测原因：[根因假设问题 / 架构限制 / 信息不足 / 其他]
### 建议
- [具体建议——例如：需要用户确认某个假设、建议重新设计某模块、建议引入更专业的排查手段]
请审核以上信息，指示下一步方向。
循环记录模板：
## 第 N 轮修复（追加在审查记录末尾）
### 上一轮不通过的问题
- [子智能体/分组]：[具体不通过原因]（审查问题 [1/2/3] 不通过）
### 本轮调整
- 回退到步骤 [①/②/③]
- 调整内容：[更新的修复 prompt / 补充的排查信息 / 追加的用户提问]
### 本轮审查结果
- [子智能体/分组]：审查三问重新判定 → ✅/❌
步骤 ⑤ 出口条件：
后置更新步骤
- 确认所有修复已通过审查（或已升级给用户）
- 汇总最终结果：根因、修复范围、审查结论、已知局限
- 如果 🟡 类 bug 决定不修 → 建议用户建独立 issue 跟踪
- 如果 🔵 类潜在风险存在 → 在最终报告中列出，建议记录跟踪
- 向用户报告最终结果
- 如果修复需要提交到远程仓库（commit / push / PR）→ 建议调用「myworkflow:Github协作」完成提交和合入
快速参考
| 你在做什么 | 看哪个步骤 |
|---|
| 用户刚报告了一个 bug，描述模糊 | 步骤 ①：硬门禁——引导用户填完 5 项细节 |
| 用户已经提供了完整信息 | 步骤 ① 快速过质量检查 → 步骤 ② |
| 细节已收集，需要找到根因 | 步骤 ②：委托「myworkflow:根因定位与全面排查」 |
| 排查报告已返回，准备修 | 步骤 ③：整理修复清单 → 分组 → 派发子智能体 |
| 子智能体修完了，需要检查质量 | 步骤 ④：审查三问 |
| 审查发现有问题 | 步骤 ⑤：判断循环——回到步骤 ①/②/③ |
| 同一个 bug 修了 3 轮还不行 | 步骤 ⑤：升级报告——请用户介入 |
| 不确定应该自己修还是派发 | 永远派发——本 skill 是编排者，不自己修代码 |
常见错误
| 错误 | 为什么错 | 正确做法 |
|---|
| 用户描述模糊就直接开始排查 | 信息不足 → 排查方向可能全错 | 步骤 ① 硬门禁——不填完不进入步骤 ② |
| 跳过步骤 ② 直接修 | 没找到根因就修 = 修的是症状 | 必须委托排查 skill 确认根因后再修 |
| 步骤 ③ 自己动手修代码 | 本 skill 是编排者，不是执行者 | 派发子智能体在隔离 worktree 中修复 |
| 多个 bug 串行修复（一个修完再修下一个） | 浪费时间——独立 bug 可以并行 | 步骤 ③ 第二步按模块分组，第三步并行派发 |
| 审查时只看代码 diff，不验证三问 | 可能放过了"看起来对但没解决根因"的修复 | 每个修复必须逐一回答审查三问 |
| 审查不通过但手动改几行代码跳过循环 | 手动改 = 未经子智能体验证流程 = 可能引入新 bug | 回到步骤 ③ 重新派发修复 |
| 3 轮循环后还在继续死循环 | 用户不知道你在死循环 | 3 轮上限——第 3 轮后升级给用户 |
| 审查通过但没实际运行验证 | "代码看起来对"不等于"bug 真的消失了" | 步骤 ④ 审查要求查看子智能体的实际验证输出 |
| 用户说"直接修，别走流程"就跳过步骤 ① | 没有细节就没有方向 | 即使简化，步骤 ① 的核心 3 项（复现步骤、错误信息、预期vs实际）不可跳过 |
| 排查报告发现 5 个 bug 但只修了 1 个 | 🔴🟠 类 bug 不修 = 修好一个、还有四个等着复发 | 步骤 ③ 第一步——🔴🟠 全部纳入修复范围 |
危险信号 —— 停下重新检查
- 用户说"页面坏了"你就开始 grep 代码 → 没填细节。回到步骤 ①
- 你脑子里出现了"这个简单，我直接改一下就行" → 越权了。本 skill 不自己修代码。回到步骤 ②（先排查）或步骤 ③（派发修复）
- 排查报告还没回来你就开始想修复方案 → 跳过步骤 ② 了。等排查结果
- 你准备把所有 bug 派给同一个子智能体串行修 → 浪费并行能力。检查是否可以分组并行——步骤 ③ 第二步
- 审查时你发现一个修复有问题，但想着"小问题，我自己改一下" → 审查不通过 → 走步骤 ⑤ 循环回到步骤 ③，不要自己改
- 同一组 bug 修了 3 轮还没过，你准备再试第 4 轮 → 3 轮上限。生成升级报告给用户
- 子智能体的验证结果里全是"应该没问题""看起来正确" → 没有实际验证证据。审查不通过（问题 2）
- 你准备在审查记录里写"代码审查通过"但没逐项回答三问 → 审查没有真正执行。回到步骤 ④
- 修复后原 bug 消失了但你没检查调用方 → 可能引入了回归。审查问题 3 不通过
- 你说服自己"这个 ❌ 其实不重要，可以标成 ⚠️" → 不允许降级。❌ 就是 ❌，必须处理
完成标志
