用途：为难以定位的缺陷和性能回退提供一套有纪律的诊断循环。资料称，除有正当理由外，不应跳过阶段。探索代码库时，若存在 CONTEXT.md 应阅读，并查看所涉区域的 ADR。
主要阶段与能力：第一阶段建立反馈回路，这是该技能的核心。回路需满足可红灯（能断言用户描述的具体症状）、确定性、快（秒级）、可无人值守运行，且已至少运行过一次并贴出调用与输出。构造方式依次可尝试：在可达缺陷的接缝处写失败测试；对运行中的开发服务器用 curl 或 HTTP 脚本；用夹具输入调用 CLI 并对比 stdout 快照；用 Playwright/Puppeteer 无头脚本；回放捕获的请求或事件日志；搭建最小临时 harness；用属性或模糊循环跑上千随机输入；用二分 harness 配合 git bisect run；对比新旧版本或两种配置的输出差异；最后才用人工参与的脚本 scripts/hitl-loop.template.sh。回路建立后还要提速、让信号更锐利、更确定。对非确定缺陷，目标不是干净复现，而是提高复现率。若确实无法建立回路，应明确说明并列出尝试过的方法，向用户索取可复现环境、捕获产物（HAR、日志、核心转储、带时间戳录屏）或临时生产插桩许可，在无回路时不要进入假设阶段。
后续阶段：第二阶段运行回路确认红灯，并最小化复现，逐个删减直到每个剩余元素都不可或缺。第三阶段先列出 3–5 个可证伪的假设并排序，向用户展示但不阻塞。第四阶段插桩，每个探针映射到具体预测，一次只改一个变量，优先调试器或 REPL，定向日志加唯一前缀如 [DEBUG-a4f2]；性能回退先建立基线测量再二分。第五阶段若存在正确接缝，先写失败回归测试，看它失败，修复，看它通过，再跑原场景回路。第六阶段清理与复盘：原复现不再出现、回归测试通过（或记录缺少接缝）、grep 清除所有 [DEBUG-...] 插桩、删除临时原型，并在提交信息中写明最终正确的假设；若答案是架构问题，转交 /improve-codebase-architecture 技能。
限制：该技能是流程纪律，不保证在无反馈回路时定位到原因；无正确接缝时无法锁定回归测试，需记录为发现。收费、价格、平台与具体安装方式暂未提供。