mcpField
B
bug-fix

bug-fix

github.com/kenlck开发545 次安装9 周前更新
代码仓库

关于 bug-fix

分阶段处理缺陷的技能，从复现和根因分析引导至获批修复与回归检查。它强调最小改动、实施前取得用户批准，并支持记录决策。

主要功能

  1. 01修复前先复现问题
  2. 02追踪根因和受影响路径
  3. 03提交修复方案供批准
  4. 04使用 TodoWrite 跟踪工作
  5. 05验证回归并记录决策

适用场景

  1. 01调查已报告的软件缺陷
  2. 02比较针对性修复方案
  3. 03修复后添加回归检查

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/kenlck/skills --skill bug-fix

安装后在 Claude Code 中输入/bug-fix确认已加载。

附带文件AGENTS.mdLOG.md

详细介绍

Bug 修复

严谨、分阶段地修复 Bug：理解 Bug → 追踪根本原因 → 设计修复方案 → 实施 → 验证并检查回归。

快速开始

使用 Bug 报告调用：/bug-fix the login button does nothing on mobile

Claude 会询问你的提问模式以及是否启用日志模式，然后逐步完成各个阶段——应用任何修复前都会暂停并等待批准。

核心原则

  • 先复现，再修复——绝不为尚未理解的 Bug 编写修复方案
  • 追踪根本原因——修复原因，而不是症状
  • 最小化、针对性修复——优先选择能正确解决根本原因的最小改动
  • 保障回归安全——每项修复都可能影响其他功能；务必验证不会造成影响
  • 跟踪所有事项——使用 TodoWrite 跟踪所有阶段和进度
  • 记录决策——启用日志模式后，根据 LOG.md 将发现记录到 plans/

阶段 0：准备

  1. 创建一个涵盖所有阶段的待办列表。
  2. 阅读报告：$ARGUMENTS
  3. 在记忆中检查该领域相关的既往 Bug 或已知问题。
  4. 通过 AskUserQuestion 向用户提出两个问题（一次调用，两个问题）：
    • 提问模式：Quick / Normal / Grill Me（见下文模式说明）
    • 日志模式：开启或关闭

提问模式

Quick Mode——适用于原因明确的显而易见的 Bug。确认疑似根本原因和修复方案后，以最少的问题继续。

Normal Mode——提出有针对性的问题：预期行为与实际行为、复现步骤、问题何时开始、近期是否有相关改动。每次只使用一个 AskUserQuestion。

Grill Me Mode——仔细追问每个细节：准确的错误消息、复现条件、环境、边缘情况、近期改动和相关症状。每次只使用一个 AskUserQuestion。绝不妄加假设。

所有模式下：如果可以通过阅读代码库或错误输出回答问题，就自行回答。

阶段 1：接收并复现 Bug

  1. 使用所选模式，确认预期行为、实际行为、复现步骤和严重程度／影响。
  2. 阅读相关文件，并从报告中提到的入口点追踪代码路径。
  3. 确认你对复现过程的理解：记录故障发生的位置和原因。
  4. 如果启用了日志模式，根据 LOG.md 将初步发现写入日志。

阶段 2：根本原因分析

先看代码地图。 如果 .codemap/MAP.md 存在，在搜索前先阅读。使用 .codemap/graph.json 中的边来追踪可疑符号的调用方／被调用方（type: "calls"、type: "imports"），不要通过搜索使用位置来追踪。对于代码地图未涵盖的细节，再使用 Glob/Grep/Read。如果代码地图缺失或已过时，请建议使用合适的构建工具：TS/JS 使用 /ken-swe:ts-codemap，Java/Go/Python/Rust 使用 /ken-swe:codemap。

  1. 根据 AGENTS.md 中的 Tracer 提示词，并行启动 2–3 个通用 Agent。
  2. 阅读 Agent 找出的所有文件。
  3. 展示发现：已确认的根本原因、确切的故障点，以及所有受影响的代码路径。
  4. 使用当前提问模式提出任何后续问题。
  5. 如果启用了日志模式，将根本原因记录到日志中。

阶段 3：修复方案设计

  1. 根据 AGENTS.md 中的 Fixer 提示词，并行启动 2–3 个通用 Agent。
  2. 审查所有方案，并形成自己的建议。
  3. 展示：各方案摘要、每种方案的权衡与回归风险，以及你的建议和理由。
  4. 询问用户偏好哪种方案（AskUserQuestion）。
  5. 如果启用了日志模式，将修复决策记录到日志中。

阶段 4：实施

未经用户明确批准，绝不开始实施。

  1. 等待用户批准所选修复方案。
  2. 阅读前面阶段中确定的所有相关文件。
  3. 遵循代码库规范应用修复。随进展更新待办事项。
  4. 回归测试：如果存在测试框架，编写能够捕获此 Bug 的测试。如果不存在测试框架，询问用户是否要在没有测试的情况下继续。

第 5 阶段：回归与质量检查

  1. 询问用户是否希望执行自动化质量检查（AskUserQuestion）。
  2. 如果希望：对已更改的代码进行审查（正确性、副作用、约定）。按严重程度报告，并询问哪些问题现在修复、哪些延后处理。
  3. 根据 AGENTS.md 中的 Regression 和 Reviewer 提示词，并行启动 Agent。
  4. 指出发现的回归问题或新问题，并根据用户的决定处理。

第 6 阶段：总结

  1. 将所有待办事项标记为已完成。
  2. 总结：问题、根本原因、已应用的修复、添加的回归测试、已更改的文件、回归风险及建议的后续工作。
  3. 如果启用了日志模式，请在日志中添加总结部分并完成日志。

评论

支持 Markdown