遇到明确报错或堆栈时，适合先建立可验证的排查假设。
解析错误消息，通过堆栈跟踪追踪执行流程，关联日志条目以识别故障点，并应用系统化的假设驱动方
01
Bug 修复 Skill 是什么？
Bug 修复 Skill 是帮助 Agent 处理报错、日志、堆栈和失败用例的任务技能。它们将复现、取证、根因假设、最小修复和回归验证组织成可复查的排障流程，帮助开发者避免从“看起来可能”直接跳到改代码。当问题还不能稳定复现时，正确用法是先补证据，而不是让 Skill 猜一个补丁。
| 应用场景 | 主要作用 |
|---|---|
| 复现与证据收集 | 先保留最小失败输入、完整报错、运行环境和关键日志，把“偶发现象”变成其他人也能复查的稳定复现。这一组 Skill 适合在改代码前完成证据整理。 |
| 根因定位与最小修复 | 利用堆栈、trace、配置和对照实验逐步排除假设，将根因缩小到可解释的模块或条件。候选 Skill 应给出最小改动及其因果理由，而不是只交付一个表面可用的补丁。 |
| 回归保护与交付 | 用原始失败用例、新增回归用例和受影响测试共同验证修复，再整理变更说明与发布检查项。这一组负责证明问题没有被隐藏或转移。 |
本文整理 6 个 Bug 修复 Skill。复现与证据组先把故障变成可复查的失败用例，根因与最小修复组负责验证假设，回归与交付组补齐测试和发布证据；开发者可按当前阻塞阶段组合使用。
02
Bug 修复 Skill 推荐
DeepSkill 将 Bug 排障中的复现、取证、定位、修复和回归任务整理成可直接安装的 Skill，你可以根据当前故障阶段灵活使用。本页推荐的 6 个 Skill 分别面向复现与证据、根因与最小修复、回归与交付；选择时先固定同一失败用例，再比较证据链、修复边界和回归结果。
应用场景：复现与证据收集
先保留最小失败输入、完整报错、运行环境和关键日志，把“偶发现象”变成其他人也能复查的稳定复现。这一组 Skill 适合在改代码前完成证据整理。
适合日志量大、崩溃链路长或问题偶发时整理证据。
解析错误日志、堆栈跟踪和崩溃报告，生成结构化的根本原因诊断。当应用程序抛出异常、崩溃或产生
应用场景：根因定位与最小修复
利用堆栈、trace、配置和对照实验逐步排除假设，将根因缩小到可解释的模块或条件。候选 Skill 应给出最小改动及其因果理由，而不是只交付一个表面可用的补丁。
需要把失败路径缩小到具体模块时，用它约束修复范围。
从现象出发，通过可复现路径定位根因，给出最小修复方案及防回归措施，覆盖 bug 处理全流程
应用场景：回归保护与交付
用原始失败用例、新增回归用例和受影响测试共同验证修复，再整理变更说明与发布检查项。这一组负责证明问题没有被隐藏或转移。
想探索更多 Skill？搜索更多好用的skill
03
如何找到更多 Bug 修复 Skill？
DeepSkill 收录40万+ Skills，所有skill都经过真实的安全审查与风险验证。复现故障、梳理日志、定位根因、生成最小修复和补齐回归等任务都可以按阶段查找。搜索时写明技术栈、完整报错、复现状态和已有证据，比只输入“修复 Bug”更容易找到能处理当前阻塞的 Skill。
方式一：在 DeepSkill 直接搜索
1
在输入框中描述任务
在搜索框写下完整报错、语言与运行环境、是否能稳定复现，以及已经拿到的日志或 trace。将“先取证”还是“已可修复”说清楚。
2
从返回列表选择 Skill
先看推荐理由与适用阶段，再核对候选需要读取的代码、日志、凭据和外部访问。优先选择能说明证据、修改边界和回归方法的 Skill。
3
复制对应安装口令
复制一个候选的安装口令，在独立分支或工作树中用同一个失败用例试跑。记录它的假设、改动和验证结果，再决定是否保留。
方式二：在 Agent 中安装 DeepSkill
如果希望 Agent 在任务中主动查找 Skill，可以把下面的安装指令直接发送给它。完成安装后，Agent 就能根据当前任务搜索并安装匹配的 Skill。该指令适用于 Codex、Claude Code、WorkBuddy 等主流 Agent。
复制给 Agent 的安装指令
根据 https://www.deepskill.market/deepskill.md 安装 DeepSkill。04
如何更高效地使用 Bug 修复 Skill？
使用 Bug 修复 Skill 时，先固定失败输入、期望行为、可修改范围和回归命令。让它先解释证据和假设，再提交可回退的最小改动；任何自动修复都应通过原始失败用例、新增回归和相关测试后再进入评审。
先固定可复现现象
记录错误文本、环境、复现频率和最小失败输入；证据不足时先用 debugging-log-analyser 梳理日志。
提供能验证假设的材料
把堆栈、trace、相关配置和最近变更一起交给 debugging-wizard，不要只输入一句“修好它”。
限定可修改范围
明确只读区域、不可更改的接口和禁止访问的凭据，让 oma-debug 只提交可回滚的最小改动。
用四类证据验收
同时要求原始失败用例转绿、新增回归测试、无关用例不退化，并说明根因与修复的因果关系。
失败时回到上一个假设
如果补丁不能解释现象，撤销变更并保留实验记录，不要让连续猜测把问题扩大。
把缺陷闭环沉淀进团队
用 bugfix-farming 记录分诊、复现、修复、补测和发布检查点，下次同类故障先复用已验证流程。
让 Bug 修复从“补丁能跑”走到“根因可证明”
Bug 修复 Skill 的价值，不是替开发者猜得更快，而是把报错、证据、假设、改动和验证连成一条能被复查的因果链。面对偶发故障或复杂运行时问题，可以先用日志分析类 Skill 整理时间线，再用定位类 Skill 验证假设，最后交给回归与交付类 Skill 补齐证据。组合使用时要保证每个阶段只有一个明确输出，并保留人工对根因、影响范围和发布风险的最终判断。将有效的复现方法、回归用例和回滚路径记录下来，下一次类似故障才能从已验证的基线开始，而不是再做一次临时补丁。
去DeepSkill探索更多好用的skill