用途：针对难以定位的 Bug 和性能退化，提供有纪律的诊断流程，避免靠盯代码猜测。当用户要求“诊断这个”“调试这个”、报告功能损坏/抛异常/失败，或描述性能下降时使用。仅在有明确理由时才跳过阶段。探索代码库时，使用项目的领域词汇表建立相关模块的心智模型，并检查所改区域的 ADR。
主要能力与流程： 阶段 1 建立反馈循环。这是核心技能，其余步骤都依赖这个信号。构造方式可依次尝试：失败测试（单元、集成、端到端）、针对运行中开发服务器的 Curl/HTTP 脚本、带 fixture 输入并与已知正确快照 diff 的 CLI 调用、Playwright/Puppeteer 无头浏览器脚本、重放捕获的追踪、一次性最小测试工具、属性/模糊循环、二分测试工具（可配合 git bisect run）、新旧版本或两种配置的差异循环，最后才是用 scripts/hitl-loop.template.sh 驱动人工点击。建立后还要迭代循环本身：更快、信号更尖锐、更确定性；30 秒不稳定循环价值有限，2 秒确定性循环才是调试超能力。非确定性 Bug 的目标不是干净复现而是提高复现率，通过重复触发、并行、加压、缩小时间窗口、注入 sleep 等手段。若确实无法建立循环，应停下并明确说明，列出尝试过的方法，请求能复现的环境、捕获的产物（HAR、日志转储、core dump、带时间戳录屏）或临时生产埋点许可，不要在没有循环时进入假设阶段。 阶段 2 复现：运行循环，观察 Bug 出现，确认失败模式与用户描述一致，可多次复现，并捕获准确症状。 阶段 3 假设：先给出 3–5 个排序的可证伪假设，格式为“如果某原因是因，那么改变 Y 会让 Bug 消失/改变 Z 会让它更糟”，测试前展示给用户；用户不在则按自己排序继续。 阶段 4 埋点：每个探针映射到具体预测，每次只改一个变量；优先调试器/REPL，其次在区分假设的边界打针对性日志，绝不“记录所有再 grep”。每个调试日志加唯一前缀如 [DEBUG-a4f2]，便于最后一次性清理。性能退化分支应先建立基线测量（计时工具、performance.now()、profiler、查询计划）再二分，先测量后修复。 阶段 5 修复与回归测试：仅在存在正确接缝时先写回归测试，接缝要覆盖调用处的真实 Bug 模式；若接缝过浅会带来虚假信心，若不存在正确接缝本身就是发现，应记录并标记。存在接缝时：将最小复现转为失败测试，观察失败、应用修复、观察通过，再对原始未最小化场景重跑阶段 1 循环。 阶段 6 清理与事后回顾：确认原始复现不再出现、回归测试通过或接缝缺失已记录、所有 [DEBUG-...] 埋点已移除、一次性原型已删除，并在 commit/PR 消息中写明正确的假设；最后思考什么能防止该 Bug，若涉及架构问题交给 /improve-codebase-architecture。
限制：资料未提供安装方式、平台、收费价格等具体信息。