用途：为难以定位的缺陷和性能回归提供一套纪律化的诊断流程，仅在明确说明理由时才跳过阶段。探索代码库时可先读 CONTEXT.md 了解相关模块，并查看所触及区域的 ADR。
主要能力与阶段： 第一阶段建立反馈回路，这是核心。可用失败测试、curl/HTTP 脚本、CLI 夹具比对、Playwright/Puppeteer 无头浏览器、回放抓取轨迹、一次性最小 harness、属性/模糊测试、二分测试、差分对比，最后才用人工介入脚本（scripts/hitl-loop.template.sh）。回路要求能“变红”、确定、快速、可无人值守运行；非确定性缺陷目标是提高复现率。找不到回路时应停下，列出尝试过的方法，向用户索取环境、脱敏产物或临时生产插桩许可。 第二阶段复现并最小化，确认失败模式与用户描述一致且可重复，逐步裁剪输入与步骤直到每个剩余元素都是必要的。 第三阶段生成 3–5 个可证伪的排序假设，每个假设须给出预测，并在测试前展示给用户。 第四阶段插桩，每个探针映射到一个预测，一次只改一个变量，优先调试器/REPL 与定向日志，日志加唯一前缀如 [DEBUG-a4f2]；性能分支先建立基线再二分。 第五阶段修复并写回归测试：仅在存在正确接缝时，先让最小复现变为失败测试，再修复使其通过，并重跑原场景回路。 第六阶段清理与复盘：确认原复现不再出现、回归测试通过（或记录缺少接缝）、用前缀 grep 清除调试日志、删除一次性原型，并在提交或 PR 中写明最终正确的假设；随后分析可预防该缺陷的措施，必要时交给 /improve-codebase-architecture。
使用方式与限制：当用户说“diagnose”“debug this”，或报告损坏、抛错、失败、变慢时使用。展示命令、输出和抓取产物前必须脱敏，用 <REDACTED> 替换秘密，尽量通过环境变量传递凭据，只引用有信号的行；若脱敏后信息不足以诊断，应说明并询问用户。未提供具体安装命令、代码实现或其他平台信息。