用途：为疑难缺陷和性能回归提供一套有纪律的诊断循环，仅在明确说明理由时才可跳过阶段。触发场景是用户说“diagnose”“debug this”，或报告某处损坏、抛错、失败、变慢。
主要能力与流程：探索代码库时先读 GLOSSARY.md（若存在）以建立相关模块的心智模型，并查看所触及区域的 ADR。展示命令、输出和捕获物前必须脱敏，用 <REDACTED> 替换密钥；回路尽量基于环境变量构建，使凭据留在环境中；捕获物含认证头时只引用携带信号的行。若脱敏后输出不足以诊断，应说明并询问用户。
阶段一：构建反馈回路，这是核心，其余都是机械操作。构造方式大致按序：在能触达缺陷的接缝写失败测试（单元、集成、e2e）；对运行中的开发服务器用 curl/HTTP 脚本；用固定输入调用 CLI 并对比 stdout 与已知良好快照；用 Playwright/Puppeteer 无头浏览器驱动 UI 并断言 DOM/控制台/网络；回放捕获的 trace；搭建一次性最小化 harness；属性/模糊循环；二分 harness；差分循环；最后才用 HITL bash 脚本（scripts/hitl-loop.template.sh）。随后收紧回路：更快、信号更锐利、更确定。非确定性缺陷的目标不是干净复现，而是提高复现率。若确实无法构建回路，应停下明说，列出尝试，向用户索取可复现环境访问、脱敏捕获物或临时生产插桩许可，不得在无回路时进入假设。完成标准是一条已运行过、能变红、确定、快速、可无人值守运行的命令。
阶段二：运行回路复现并确认失败模式与用户描述一致，再逐步削减输入、调用方、配置、数据和步骤，直到每个剩余元素都是承重的。
阶段三：先提出 3–5 个排序假设，每个必须可证伪并给出预测，展示给用户后再测试。
阶段四：插桩，每个探针映射到具体预测，一次只改一个变量；优先调试器/REPL，其次边界处的定向日志，禁止“全量日志再 grep”；调试日志加唯一前缀如 [DEBUG-a4f2] 便于清理。性能回归分支应先建立基线测量再二分。
阶段五：修复与回归测试，先写回归测试但仅在存在正确接缝时；若无正确接缝，这本身就是发现，应记录并上报。
阶段六：清理，确认原始复现不再出现、回归测试通过（或记录接缝缺失）、移除所有 [DEBUG-...] 插桩、删除一次性原型，并在提交/PR 信息中写明最终正确的假设。
限制：资料未提供该技能的安装方式、平台支持、收费或价格信息。