用途：为疑难 Bug 和性能回归提供一套有纪律的诊断流程，核心原则是先构建紧凑的反馈回路，再提出假设。除有明确理由外，不应跳过任何阶段。开始前先阅读项目的 CLAUDE.md、模块的 CONTEXT.md，并查看相关 ADR。
主要能力与流程： 阶段1 建立反馈回路：这是技能的核心。需要一条能对该 Bug 变红的通过/失败信号，可用失败测试、curl/HTTP 脚本、CLI 夹具对比、无头浏览器脚本、回放捕获的 trace、一次性最小 harness、属性/模糊测试、二分 harness、新旧版本差分回路，最后才用 HITL 脚本。回路要更快、信号更锐利、更确定；非确定性 Bug 的目标是提高复现率。完成标准是能指出一条已运行过、可红、确定、快速、可无人值守运行的命令。若确实无法构建回路，应明确说明并列出尝试，请求可复现环境、捕获产物或临时生产埋点权限，不得在无回路时进入假设。 阶段2 复现并最小化：确认失败与用户描述一致、可跨运行复现、症状被捕获，再逐步裁剪到最小场景。 阶段3 假设：先给出 3–5 个可证伪、带预测的排序假设，展示给用户后再测试。 阶段4 埋点：每个探针对应一个预测，一次只改一个变量；调试日志加唯一前缀如 [DEBUG-a4f2]；性能回归先建立基线再二分。 阶段5 修复与回归测试：在正确接缝处先写回归测试，看它失败、修复、看它通过，再跑阶段1回路。若无正确接缝，这本身就是发现。 阶段6 清理与复盘：确认原复现不再出现、回归测试通过、移除所有调试埋点、删除临时 harness，并在提交信息中写明正确假设。
限制与注意：绿色回路不等于已修复；若修复前回路从未变红则无证明力。不要在存在可红命令前读代码形成理论，也不要修复回路恰好捕获的邻近失败而非用户报告的症状。该技能改编自 Matt Pocock 的 diagnosing-bugs（MIT）。