用途：针对困难缺陷和性能回归的诊断纪律，适用于用户请求诊断或调试、或报告某处损坏、抛错、失败、变慢的场景。资料强调：跳过任何阶段都需明确说明理由。
核心方法分阶段。阶段一建立反馈回路，这是关键：需要一个针对该缺陷会变红的通过/失败信号。可选方式大致按顺序为：在触及缺陷的接缝写失败测试（单元、集成、e2e）；对运行中的开发服务器用 curl 或 HTTP 脚本；用固定输入调用 CLI 并 diff 标准输出与已知良好快照；用 Playwright/Puppeteer 无头浏览器驱动 UI 并断言 DOM、控制台、网络；回放捕获的 trace；搭建一次性最小 harness；属性/模糊测试循环；二分 harness；差分循环；人工介入脚本 scripts/hitl-loop.template.sh。回路需尽量更快、信号更锐利、更确定。非确定性缺陷的目标是提高复现率而非干净复现。若确实无法建立回路，应停止并明确说明，列出尝试过的方法，向用户索取复现环境访问权、捕获产物（HAR、日志、core dump、带时间戳录屏）或临时生产插桩许可，不要在无回路时直接假设。阶段一完成标准是存在一条紧致且可变红的命令，须已实际运行过，具备可红、确定、快速、可无人值守运行四个特征。
阶段二复现并最小化：运行回路观察变红，确认失败模式与用户描述一致、可多次复现、已捕获确切症状；随后逐步裁剪输入、调用方、配置、数据和步骤，保留对失败有承载作用的元素。
阶段三假设：先产生 3–5 个排序假设，每个可证伪并给出预测，格式如“若…是原因，则…会消失/更糟”。可在测试前把排序列表给用户看，但用户不在时不要阻塞。
阶段四插桩：每个探针映射到具体预测，一次只改一个变量。优先调试器或 REPL，其次在区分假设的边界加定向日志，禁止“全量打日志再 grep”。调试日志加唯一前缀如 [DEBUG-a4f2]，便于最后一次性清理。性能回归应设立基线测量并二分，先测量后修复。
阶段五修复与回归测试：先写回归测试，但仅当存在正确接缝时。若接缝太浅会产生虚假信心，此时应记录该发现并转交架构改进。正确接缝下：把最小复现变成失败测试、观察失败、应用修复、观察通过，再对原始未最小化场景重跑阶段一回路。
阶段六清理与事后分析：要求原始复现不再出现、回归测试通过或已记录接缝缺失、所有 [DEBUG-...] 插桩用 grep 清除、一次性原型删除或移到明确调试位置、在提交/PR 中写明最终正确的假设。随后追问什么能预防此缺陷，若涉及架构问题，在修复完成后交给 /improve-codebase-architecture 技能。限制：资料未提供收费、平台、安装方式等信息。