这个 Skill 能做什么，适合哪些场景？
该技能把调试难题提炼为一个六阶段纪律流程，核心是构建一个紧致、可复现的反馈循环：先让 bug 稳定红，再最小化复现，列出可证伪的假设，用定向插桩验证，写出回归测试，最后清理并复盘。它强调在提出假设之前必须有一个能变红的命令，并要求在展示输出前对所有秘密进行编辑。它适用于任意编程语言，且与仓库中的其他技能配合使用（如 /tdd、/improve-codebase-architecture）。该技能来自 mattpocock/skills 合集，该合集中包含 35 个技能，采用 MIT 许可。
该技能提供逐步调试协议：第一阶段优先构建反馈循环（失败测试、curl 脚本、Playwright、捕获的轨迹、临时 harness、模糊测试、git bisect harness、对比循环或 human-in-the-loop 脚本），并要求循环具备 'red-capable'、确定性、快速且可由 agent 自动运行。它指引阅读 CONTEXT.md 和 ADR，在展示前对命令输出、捕获的工件和认证头进行编辑，生成 3-5 个可证伪的假设并在测试前向用户展示，使用带唯一前缀的日志（如 [DEBUG-a4f2]），在性能回退时测量基线，在修复前编写回归测试，并在完成后清理所有调试痕迹并记录正确的假设。
- 当用户报告一个随机崩溃或数据损坏 bug，没有任何明显的复现步骤时，开发人员使用该技能构建系统化的反馈循环。
- 当 CI 测试偶尔失败（flaky）时，工程师应用该技能提高复现率，直到可调试。
- 当生产环境中的某个端点出现性能回退时，开发者使用性能分支：先测量基线，再进行二分。
- 当 agent 在修复 bug 前倾向于猜测时，该技能通过在允许假设之前要求一个可复现的命令来阻止这种行为。
- 当需要在代码库中安全调试且不泄露敏感信息时，该技能内置了编辑规则。
- 当修复 bug 后需要确保不会再次出现时，该技能指导在正确的 seam 处编写回归测试。
如何安装这个 Skill？
- 技能允许在生产环境添加临时仪表，但未明确要求用户确认和提供回滚计划，实施时需谨慎并先征得同意。
- 技能高度依赖本地环境和代码库，可能不适用于无代码或远程环境，且未提及对中国大陆网络环境的适配。
- 静态审查无法验证技能的实际效果，建议在实际项目中试用并验证其调试循环的有效性。
- Shell / 命令行
通过 skills.sh 安装整个合集：运行 npx skills@latest add mattpocock/skills 并选择要安装的技能以及目标 agent（确保选择 /setup-matt-pocock-skills）。或者，作为 Claude Code 插件安装：在 Claude Code 中运行 /plugin marketplace add mattpocock/skills 和 /plugin install mattpocock-skills@mattpocock。然后每个仓库运行一次 /setup-matt-pocock-skills 进行配置。
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/mattpocock/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/engineering/diagnosing-bugs" ~/.claude/skills/
rm -rf "$tmp"根据源仓库地址和 Skill 路径自动生成，只复制这个 Skill 的文件夹。如果上文有作者提供的安装方式，请优先按作者说明操作；想只在当前项目中使用，把 ~/.claude/skills 换成项目里的 .claude/skills。
如何使用这个 Skill？
当用户说 'diagnose' 或 'debug this'，或报告代码抛出异常、失败或运行缓慢时，该技能会自动触发。或者手动调用它。然后在仓库中执行 SKILL.md 中的阶段：阅读现有的 CONTEXT.md 和 ADR，在 Phase 1 中构建一个紧致的反馈循环（如果无法构建，请明确说明并请求用户提供资源），再进行 repro-minimise-hypothesise-instrument-fix-regression-test 循环，最后遵循清理清单。
这个 Skill 有哪些优点和局限？
- 强制先构建反馈循环，避免过早猜测。
- 可操作且指标驱动：明确定义了 'tight' 和 'red-capable' 的标准。
- 内置编辑规则，安全处理敏感信息。
- 引导生成多个可证伪的假设，并通过用户检查来重新排序。
- 包括系统性的回归测试和清理协议，降低重复 bug 的风险。
- 专为 agent 自动执行而设计，支持有限的人类介入。
- 对快速修复或简单 bug 而言过于繁琐，会跳过阶段。
- 严重依赖用户提供环境和访问权限来构建反馈循环；如果缺少这些，技能会停滞。
- 未包含任何测试套件或 CI 来验证技能本身的效果。
- 一些建议（如 HITL 脚本）尚未在仓库中实作，需要用户自行创建。
- 并未覆盖非代码调试场景（如基础设施问题）。
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| 疑难 Bug 诊断法 本页 | 47 · 谨慎使用 | ★ 281k | 3 天前 | MIT |
| cmux 测试二分定位（cmux-test-bisect） | 51 · 谨慎使用 | ★ 28k | 1 天前 | NOASSERTION |
| e2e Verify —— 端到端变更验证技能 | 64 · 推荐 | ★ 8.7k | 1 天前 | Apache-2.0 |
| TDD Guard | 61 · 推荐 | ★ 2.4k | 6 天前 | MIT |
| 测试驱动开发工作流 | 57 · 谨慎使用 | ★ 103k | 8 天前 | MIT |
FollowSkills 如何评估这个 Skill？
技能明确要求在执行命令、展示输出前对机密进行脱敏（<REDACTED>），并建议将凭据保存在环境中而非输出中，体现了数据流透明性和最小权限原则。然而，技能允许在必要时添加生产环境临时仪表（阶段1），但未明确要求用户确认或提供回滚计划，存在潜在风险。发布者身份未经验证，但来源归属在README和许可证中明确标识为Matt Pocock。扣分点：生产仪表添加前未明确要求用户确认，且缺乏明确的回滚机制。
技能提供了结构化的分阶段调试流程，包括反馈循环构建、最小化、假设、仪器化、修复和清理，逻辑自洽。然而，静态审查无法验证实际运行效果，且技能依赖用户提供环境和人工介入（如HITL脚本），错误处理和失败反馈机制仅在无法构建循环时提及，缺乏详细指导。扣分点：无测试证明关键路径可行性，失败反馈描述不够详细。
技能明确定义了适用场景（硬bug和性能回归）和触发条件（用户说'diagnose'/'debug'时），并提供了详细的操作流程。但技能未明确声明非适用场景（如简单bug、无代码环境），且对环境适配（如中国大陆网络可达性）没有提及。扣分点：非适用场景边界模糊，缺乏对中国大陆环境适配的说明。
技能文件结构清晰，包含描述、元数据、阶段划分和检查清单，信息架构合理。有许可（MIT）、版本管理（package.json和changesets）和发布工作流（release.yml），维护责任明确（Matt Pocock）。但缺少安装/依赖说明（如运行技能所需的环境变量），以及常见问题和已知限制部分不完整。扣分点：依赖说明和故障排除部分不足。
技能提供了详细的调试方法论，有望高效解决硬bug。但静态审查无法验证实际输出是否直接可用，且技能输出高度依赖用户环境和代码库情况，边际价值难以量化。扣分点：缺少代表性输出示例，无法验证实际效果。
仓库包含CI工作流（release.yml），但该工作流仅处理版本发布，不包含针对技能内容的测试。缺少独立第三方验证证据，技能核心内容无法通过静态审查独立复现。扣分点：无测试套件或第三方执行证据。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →