Menu
当你遇到任何 bug、错误、异常行为、测试失败时，必须在提出任何修复方案之前使用本 skill。触发词：bug、修 bug、报错、错误、异常、崩溃、不工作、出问题、坏了、不对、怎么报错了、帮我修一下、fix、error、crash、broken、doesn't work。即使 bug 看起来很简单也必须触发——简单 bug 同样需要系统化定位根因。禁止跳过任何步骤。禁止仅用单元测试代替真实验证。反例：纯问答、代码解释、功能开发（功能开发请用「智能体闭环开发」）。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| 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 不修 = 修好一个、还有四个等着复发 | 步骤 ③ 第一步——🔴🟠 全部纳入修复范围 |
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 需要以"少即是多"的方式思考与协作时触发——回答过长、方案过度设计、输出冗余、或需要克制时。触发词：少即是多、简洁一点、精简、less is more、别写太多、克制一点。本 skill 是行为准则，横切不绑定具体任务。
Use when 需要编辑或审阅文本，去除 AI 生成痕迹使其听起来更自然、更像人类书写。触发词：去 AI 味、润色文本、改写、humanize、去机器人味、太像 AI 写的。不触发：纯技术文档审阅、代码审查、文本翻译。
Extract content from scanned/image-based PDFs using OCR, then reconstruct formulas, equations, and technical notation into proper LaTeX using contextual reasoning. Use this skill whenever the user asks to: extract text from scanned PDFs, OCR a PDF, convert scanned textbook/document pages to Markdown, reconstruct formulas/symbols from OCR output, digitize a physical document containing equations, convert image-based PDF to Markdown with LaTeX, or process scanned technical/scientific content. Works with any language supported by Tesseract OCR.
Transform structured STEM content (textbooks, lectures, academic papers) into rigorous, accessible study guides — delivered as if a university lecturer is teaching a student from scratch (textbook mode) or a research mentor is walking a junior through a paper (paper mode). Use whenever the user asks to create study notes, distill textbook sections, make exam prep materials, read/explain a paper, or "提炼/整理/总结" course/paper content — for math, physics, computer science, engineering, and related disciplines. Each invocation processes ONE chapter or paper section as a self-contained lecture. The skill follows a "formal statement → plain-language explanation" paradigm: every definition, theorem, and notation is stated formally first, then immediately unpacked in plain language with physical intuition and step-by-step reasoning. Includes a mandatory self-review phase before output.