用途：为疑难 Bug 和性能回归提供一套有纪律的诊断流程，避免直接凭猜测读代码。当用户说“diagnose”“debug this”，或报告某处损坏、抛错、失败、变慢时使用。探索代码库时，若存在 CONTEXT.md 应先阅读以建立相关模块的心智模型，并查看所触及区域的 ADR。
主要能力与流程： 阶段1 构建反馈回路：这是核心，其余步骤都是机械执行。优先尝试失败测试、curl/HTTP 脚本、CLI 夹具对比、无头浏览器脚本（Playwright/Puppeteer）、回放捕获的 trace、一次性最小 harness、属性/模糊测试、二分 harness、差分回路，最后才用人工回路脚本 scripts/hitl-loop.template.sh。回路要更快、信号更锐利、更确定；非确定性 Bug 的目标是提高复现率而非干净复现。若确实无法构建回路，应停下并明确说明，列出尝试过的方法，向用户索取环境访问、捕获产物或临时生产插桩许可。阶段1 完成标准是存在一条已运行过、能变红、确定、快速、可无人值守运行的命令。进入阶段2 前必须向用户报告回路、信号等信息并等待确认。 阶段2 复现与最小化：运行回路确认失败模式与用户描述一致、可复现、已捕获确切症状；随后逐步削减输入、调用方、配置、数据与步骤，直到每个剩余元素都是承重的。 阶段3 假设：先给出3–5个排序假设，每个必须可证伪并写明预测，展示给用户后再测试。 阶段4 插桩：每个探针映射到具体预测，一次只改一个变量；优先调试器/REPL，其次定向日志，禁止“全量日志再 grep”；调试日志加唯一前缀如 [DEBUG-a4f2] 便于清理。性能回归应先建立基线测量再二分。进入阶段5 前必须报告根因、被确认的假设、拟议修复及修复类型（根因修复或防御性修复），并等待确认。 阶段5 修复与回归测试：仅在存在正确接缝时先写回归测试，观察失败、应用修复、观察通过，再对原始未最小化场景重跑阶段1 回路。若无正确接缝，这本身就是发现，应记录并转交架构改进。 阶段6 清理与复盘：确认原始复现不再出现、回归测试通过、所有 [DEBUG-...] 插桩已移除、一次性原型已删除、正确假设写入提交/PR 信息；再思考什么能预防此 Bug，若涉及架构问题则转交 /improve-codebase-architecture。
限制：资料未提供该技能的安装方式、收费、平台支持或效果数据，暂未提供。