用途：为难以定位的缺陷和性能回退提供结构化诊断流程，每个阶段仅在明确有理由时才可跳过。
主要能力： 一、建立反馈回路。这是核心步骤，其余多为机械执行。需构造快速、确定性、可自动运行的通过/失败信号，方式包括：可触达缺陷的失败测试（单元、集成、端到端）；对运行中开发服务器发 curl/HTTP 脚本；带夹具输入的 CLI 调用并对 stdout 与已知良好快照做 diff；无头浏览器脚本（Playwright/Puppeteer）断言 DOM、控制台与网络；回放捕获的 trace；一次性最小化测试装置；属性/模糊测试循环；二分测试装置；新旧版本差分对比；最后才用带人工介入的 bash 脚本。回路本身也要迭代：更快、信号更锐利、更确定，30 秒不稳定的回路几乎等于没有。对非确定性 Bug，目标不是干净复现而是提高复现率。若确实无法建立回路，应停下明说，列出尝试过的方法，请用户提供可复现环境、捕获的产物（HAR、日志、核心转储、带时间戳录屏）或临时生产插桩许可，未获回路前不进入假设阶段。 二、复现。运行回路观察缺陷出现，确认失败模式与用户所述一致、可多次复现、已捕获确切症状。 三、假设。先给出 3–5 个排序假设，每条必须可证伪并写出预测，在测试前把排序列表给用户看。 四、插桩。每个探针须对应某条预测，一次只改一个变量。优先使用调试器/REPL，其次在区分假设的边界打定向日志，避免“全部打日志再 grep”。日志加唯一前缀如 [DEBUG-a4f2] 便于清理。性能问题分支：先建立基线测量再二分，先测量后修复。 五、修复与回归测试。仅在存在正确测试缝隙时先写回归测试，观察失败、修复、观察通过，再用第一阶段回路复验原始场景；若缝隙不存在，这本身就是发现，应记录。 六、清理与复盘。要求原始复现不再出现、回归测试通过（或记录无缝隙）、清除所有调试插桩、删除一次性原型、在提交信息中写明最终正确的假设。随后思考什么能预防该缺陷，若涉及架构变更，修复完成后转交 /improve-codebase-architecture。
使用方式与限制：作为技能在开发环境中按上述阶段执行；探索代码库时使用项目领域术语表，并查看相关已接受 ADR，拟议中的 ADR 仅作为当前调查的规划背景。资料未提供具体安装命令、价格、支持平台与调用参数。