用途：面向难以定位的缺陷和性能回退，提供一套分阶段的诊断纪律，仅在明确说明理由时才可跳过阶段。触发场景包括用户要求“diagnose”“debug this”，或报告某处损坏、抛错、失败、变慢。
主要能力与流程：
- 建立反馈回路：这是核心。需要一个针对该缺陷会变红的紧凑通过/失败信号，二分、假设检验和插桩都依赖它。构建方式按大致顺序尝试：在能触达缺陷的接缝写失败测试（单元、集成、e2e）；对运行中的开发服务器用 curl/HTTP 脚本；用固定输入调用 CLI 并对比已知良好快照；用 Playwright/Puppeteer 无头浏览器驱动 UI 并断言 DOM/控制台/网络；回放捕获的 trace；搭建一次性最小 harness；属性/模糊循环；二分 harness；新旧版本差分循环；最后才用人工介入脚本 scripts/hitl-loop.template.sh。回路要更快、信号更锐利、更确定。非确定性缺陷的目标是提高复现率而非干净复现。若确实无法建立回路，应停下并明确说明，列出尝试过的方法，向用户索取可复现环境、捕获产物或临时生产插桩许可，不得在无回路时进入假设阶段。完成标准：能给出一个已运行过、会变红、确定、快速、可无人值守运行的命令。
- 复现与最小化：运行回路确认缺陷出现，核对失败模式与用户描述一致，并捕获确切症状；随后逐步削减输入、调用方、配置、数据和步骤，直到每个剩余元素都是承重的。
- 假设：先提出 3–5 个排序假设，每个必须可证伪并给出预测，展示给用户后再测试。
- 插桩：每个探针映射到具体预测，一次只改一个变量；优先调试器/REPL，其次在区分假设的边界打定向日志，禁止“全量日志再 grep”；调试日志加唯一前缀如 [DEBUG-a4f2] 便于清理。性能回退分支应先建立基线测量再二分。
- 修复与回归测试：仅在存在正确接缝时先写回归测试，观察失败、修复、观察通过，再对原始场景重跑第一阶段回路；若无正确接缝，这本身就是发现，需记录。
- 清理与复盘：确认原始复现不再出现、回归测试通过、所有 [DEBUG-...] 插桩已移除、一次性原型已删除，并在提交/PR 中写明最终正确的假设；随后思考如何预防此类缺陷，若涉及架构问题可转交 /improve-codebase-architecture 技能。
限制：资料未提供该技能的安装方式、收费、支持平台或具体命令细节；探索代码库时应使用项目领域词汇表并查看相关已接受 ADR，拟议 ADR 仅在属于当前缺陷或调查时作为规划上下文。