bug

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"]

触发场景

必须触发（满足任意一条）

1. 用户说"有个 bug""修一下""报错了""不工作""出问题了""帮我看看这个错误"
2. 用户描述了异常行为（预期 X 但实际 Y）
3. 用户贴了一段错误日志、堆栈跟踪、测试失败输出
4. 用户说"怎么崩溃了""为什么不对""帮我排查一下"
5. 任何涉及修复现有代码缺陷的请求——无论 bug 大小
6. 测试失败、构建失败、运行时异常
7. 用户说"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），不自己修代码（派发子智能体）。职责：收细节 → 委托排查 → 派发修复 → 审查 → 循环。

1. 硬门禁——用户必须填完 5 项细节：复现步骤、预期 vs 实际行为、环境信息、日志/错误信息、出现频率。不填完不进入步骤 ②
2. 禁止跳过排查：必须先委托「myworkflow:根因定位与全面排查」找到根因，才能进入修复。不允许"这个简单，我直接修"
   • 轻量分析例外：根因一目了然的 bug（语法错误、类型不匹配、缺 import、拼写错误）→ 允许跳过委托，由本 skill 在步骤 ② 直接完成轻量根因确认（Grep 定位、Read 确认上下文），标注"根因自明，已跳过深度排查"并附理由。逻辑错误、行为异常、性能问题、竞态问题不可跳过
3. 禁止自己动手修代码：修复由隔离 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. 输入邮箱 [e-mail]  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实际）是可用的	→ 标注缺失项为"待排查补充"，进入步骤 ②
❌ 不通过	核心信息缺失（没有错误信息且无法描述实际行为、复现步骤完全不知道）	→ 继续追问，直到至少达到 ⚠️ 级别

硬门禁规则：

• 不通过 → 绝不进入步骤 ②。追问直到通过或用户明确表示无法提供更多信息（此时降级为 ⚠️ 勉强通过）
• 用户急躁（"直接帮我查吧，我不知道这些"）→ 回复："我理解你的着急。但没有复现步骤和错误信息，排查就像大海捞针。请至少告诉我：你当时在做什么操作？看到了什么现象？"
• 用户跳过提问（直接选了选项但不回复具体内容）→ 追问具体内容，不放过

步骤 ① 出口条件：

• 5 项信息清单全部填写（状态为 ✅ 或 ⚠️）
• 质量等级至少为 ⚠️（勉强通过）
• 缺失项已标注"待排查补充"（供步骤 ② 传递给排查 skill）

---

步骤 ②：调用排查 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 无法确认根因（可信度为 🟡 中或 🔴 低）→ 将排查报告中的"被推翻的假设"和"已知局限"展示给用户，询问是否：

• 接受当前最佳假设，带着不确定性继续修复
• 用户补充更多信息后重新排查
• 将问题标记为"需人工深入调查"

步骤 ② 出口条件：

• 排查委托已格式化并传入「myworkflow:根因定位与全面排查」
• 排查报告已返回（完整的 7 章节）
• 根因已确认（可信度至少 🟡 中）或用户已接受不确定性
• 修复目标清单已提取（🔴 + 🟠 位置），每个位置有文件路径和修复方向
• 已知局限已记录（将在步骤 ④ 审查时参考）

---

步骤 ③：并行派发修复

将排查报告中的 🔴 和 🟠 类 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")

第五步：收集各子智能体的修复结果

所有子智能体完成后，收集每个子智能体的产出：

• 修改的文件和变更内容
• 验证结果和证据
• 已知疑虑

步骤 ③ 出口条件：

• 修复任务清单已展示给用户并获确认
• bug 已按模块/文件分组（避免冲突）
• 每个子智能体的修复 prompt 包含：根因 + 修复清单 + 约束 + 验证要求
• 所有子智能体已并行派发（带 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 / 补充的排查信息 / 追加的用户提问]

### 本轮审查结果
- [子智能体/分组]：审查三问重新判定 → ✅/❌

步骤 ⑤ 出口条件：

• 所有修复在步骤 ④ 审查中判定为 ✅ 通过
• 或：3 轮循环后仍未通过，已生成升级报告并提交给用户
• 每轮循环都有记录

---

后置更新步骤

1. 确认所有修复已通过审查（或已升级给用户）
2. 汇总最终结果：根因、修复范围、审查结论、已知局限
3. 如果 🟡 类 bug 决定不修 → 建议用户建独立 issue 跟踪
4. 如果 🔵 类潜在风险存在 → 在最终报告中列出，建议记录跟踪
5. 向用户报告最终结果
6. 如果修复需要提交到远程仓库（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 不通过
• 你说服自己"这个 ❌ 其实不重要，可以标成 ⚠️" → 不允许降级。❌ 就是 ❌，必须处理

---

完成标志

• 步骤 ①：5 项信息清单已填写（至少 ⚠️ 级别），硬门禁已通过
• 步骤 ②：「myworkflow:根因定位与全面排查」已返回完整排查报告（7 章节）
• 步骤 ②：根因已确认（可信度 ≥ 🟡），修复目标清单已提取
• 步骤 ③：修复任务清单已展示并获用户确认
• 步骤 ③：bug 已分组，每个子智能体有完整的修复 prompt
• 步骤 ③：所有子智能体已并行派发（worktree 隔离），并返回修复结果
• 步骤 ④：每个子智能体的每个修复已通过审查三问
• 步骤 ④：审查记录已生成（每个子智能体一份）
• 步骤 ⑤：所有修复 ✅ 通过（或 3 轮后已升级给用户）
• 步骤 ⑤：每轮循环有记录
• 🟡 类 bug 的处理方式已与用户确认（修复 / 建 issue / 记录跟踪）
• 🔵 类潜在风险已记录在最终报告中
• 最终结果已向用户报告（根因 + 修复范围 + 审查结论 + 已知局限）