用途：为难以定位的缺陷与性能回退提供一套有纪律的诊断流程。除有明确理由外，不应跳过阶段。探索代码库时先读 CONTEXT.md（如存在）以建立相关模块的心智模型，并查看所涉区域的 ADR。
阶段一：建立反馈回路。这是技能的核心。需要一条针对该缺陷会变红的紧致通过/失败信号，二分、假设检验与埋点都依赖它。构造方式大致按此顺序尝试：单元/集成/e2e 失败测试；对运行中开发服务器发 curl 或 HTTP 脚本；带固定输入的 CLI 调用并与已知良好快照对比 stdout；无头浏览器脚本（Playwright / Puppeteer）断言 DOM、控制台或网络；回放捕获的 trace；临时最小化测试装置；属性/模糊测试循环；二分测试装置配合 git bisect run；新旧版本或两种配置的差分对比；最后手段是人机协同脚本 scripts/hitl-loop.template.sh。回路建立后要收紧：更快、信号更尖锐、更确定。非确定性缺陷的目标不是干净复现而是提高复现率，可循环触发 100 次、并行、加压、收窄时间窗、注入 sleep。
若确实无法建立回路，应停下并明确说明，列出已尝试内容，向用户索取能复现的环境访问权、捕获的产物（HAR、日志、core dump、带时间戳录屏），或允许在生产环境加临时埋点；不要在无回路时先提假设。阶段一完成标准：能指出一条已至少运行过一次的命令，它对真实缺陷路径断言用户描述的确切症状，可红可绿、确定、快速（秒级而非分钟级）、可无人值守运行。
阶段二：复现并最小化。运行回路确认失败模式与用户描述一致，可多次复现（非确定性缺陷需足够高复现率），并记录确切症状。随后逐步削减输入、调用方、配置、数据与步骤，每次削减后重跑，直到每个剩余元素都是承重的。未复现并最小化前不要继续。
阶段三：假设。先提出 3–5 个排序假设再测试，每个都要可证伪，格式为“若某原因是根因，则某操作会让缺陷消失或加重”。可把排序列表给用户看以借用领域知识，但不必阻塞等待。
阶段四：埋点。每个探针应对应阶段三的某个预测，一次只改一个变量。优先调试器/REPL 检查，其次在区分假设的边界打定向日志，不要“全量日志再 grep”。每条调试日志加唯一前缀如 [DEBUG-a4f2] 以便收尾 grep。性能回退通常看日志无用，应先建立基线测量（计时装置、performance.now()、profiler、查询计划）再二分，先测量后修复。
阶段五：修复与回归测试。若存在正确的测试接缝，先写回归测试：把最小化复现变成该接缝上的失败测试，看它失败，修复，看它通过，再对原始未最小化场景重跑阶段一回路。若只存在过浅接缝，回归测试会带来虚假信心；若无正确接缝，这本身就是发现，应记录并指出架构阻碍了锁定缺陷。
阶段六：清理与复盘。宣布完成前需确认：原始复现不再出现、回归测试通过（或记录缺少接缝）、所有 [DEBUG-...] 埋点已移除、临时原型已删除或移入明确标记的调试位置、正确的假设写入提交或 PR 说明。然后思考如何从源头预防，若答案涉及架构改动（缺少测试接缝、调用方纠缠、隐藏耦合），在修复后携具体细节交给 codebase-design 技能处理。
限制：资料未提供价格、平台支持范围、安装命令或具体自动化实现细节；其中 scripts/hitl-loop.template.sh 与 CONTEXT.md、ADR 为文中提及的约定，是否随包提供暂未说明。