用途：为难以定位的缺陷和性能回归提供一套有纪律的诊断流程，仅在明确说明理由时才可跳过阶段。探索代码库时应使用项目领域术语表建立模块心智模型，并查看所触及区域的 ADR。
主要能力与阶段：第一阶段构建反馈回路，这是核心；手段包括失败测试（单元、集成、端到端）、对开发服务器的 curl/HTTP 脚本、带样例输入的 CLI 调用并与已知良好快照比对、无头浏览器脚本（Playwright/Puppeteer）、重放捕获的 trace、一次性最小化测试环境、属性/模糊循环、二分法测试装置、差分循环，最后才考虑scripts/hitl-loop.template.sh 的人机协同脚本。需持续优化回路本身的速度、信号锐度和确定性；非确定性缺陷追求更高复现率而非干净复现；确实无法构建回路时应明确停止并说明已尝试内容。第二阶段运行回路确认复现，且须是用户描述的那个失败模式。第三阶段在测试前给出 3–5 条可证伪的排序假设，格式为“若某原因是主因，则某操作会使其消失/恶化”，可先展示给用户做低成本检查。第四阶段插桩，每个探针须对应某个预测，一次只改一个变量，优先使用调试器，日志需加唯一前缀如 [DEBUG-a4f2]；性能分支则先建立基线测量再二分。第五阶段先写回归测试再修复，但仅当存在正确接缝时；若无正确接缝，这本身即为发现，需记录。第六阶段清理与事后复盘，要求原始复现不再出现、回归测试通过、所有调试标记移除、原型删除，并在提交信息中写明正确的假设，最后思考如何从架构上预防，必要时移交 /improve-codebase-architecture 技能。
适用场景：硬缺陷、间歇性故障、性能退化等需要系统性而非靠盯代码解决的排查工作。
限制：未提供收费、价格、平台支持等信息；命令与路径需按项目实际情况使用，资料未给出具体命令示例。