用途：为难以定位的 Bug 和回归问题提供一套有纪律的诊断流程，按“构建反馈回路 → 复现并最小化 → 提出假设 → 插桩验证 → 修复并加回归测试 → 清理与复盘”推进，只有明确说明理由时才可跳过阶段。探索代码库时建议参考项目领域术语表和所涉区域的 ADR；诊断复杂顽固问题时也可考虑同时启用 systematic-debugging 技能。
主要能力：核心是第一阶段构建快速、确定、可由智能体无人值守运行的 pass/fail 信号，手段包括失败测试、curl/HTTP 脚本、CLI 夹具对比、Playwright/Puppeteer 无头浏览器、回放捕获的 trace、一次性最小 harness、属性/模糊测试、二分 harness、新旧版本差分，以及最后手段的人机 bash 脚本（scripts/hitl-loop.template.sh）。随后对回路本身迭代，追求更快、信号更锐利、更确定；非确定性 Bug 以提高复现率为目标。
使用方式：先运行回路确认复现用户描述的症状，再逐步裁剪输入、调用方、配置与步骤做最小化；提出 3-5 个可证伪的排序假设并展示给用户；插桩时每个探针只对应一个预测，一次只改一个变量，调试日志加唯一前缀如 [DEBUG-a4f2]；修复前先写回归测试，但仅在存在正确测试接缝时；最后确认原复现不再出现、回归测试通过、清理所有调试插桩与临时原型，并在提交信息中写明最终正确的假设。
限制与注意：展示命令、输出和捕获物前必须脱敏，用 <REDACTED> 替换密钥，凭据通过环境变量传递，捕获物只引用含信号的片段；若脱敏后不足以诊断，应说明并询问用户。若确实无法构建回路，应停止并列出尝试，向用户请求可复现环境、脱敏捕获物或临时生产插桩许可，不得在无回路时进入假设阶段。性能回归应先建立基线测量再二分，日志通常不适用。若不存在正确测试接缝，应记录该发现并考虑移交 /improve-codebase-architecture 技能。