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