用途：为疑难缺陷和性能回归提供一套分阶段诊断流程，仅在明确合理时才可跳过阶段。触发条件：用户说“diagnose”“debug this”，或报告某处损坏、抛错、失败、变慢。探索代码库时，先读 CONTEXT.md（若存在）以建立相关模块的心智模型，并查看涉及区域的 ADR。
安全要求：展示命令、输出与捕获产物前必须脱敏，机密一律写为 <REDACTED>；循环通过环境变量构建，使凭据留在环境中而非展示内容里。捕获产物常含鉴权头，只引用携带信号的行。若脱敏后输出不足以诊断，应说明并询问用户。
流程：阶段一构建反馈循环——这是核心，其余皆为机械步骤；需能做到可判红、确定性、快速（秒级）、可无人值守运行，并已实际运行过一次。构建方式按大致顺序包括：在触达缺陷的接缝写失败测试、对运行中开发服务器用 curl/HTTP 脚本、用夹具输入调用 CLI 并 diff 标准输出与已知良好快照、用 Playwright/Puppeteer 驱动 UI、重放捕获的 trace、一次性最小化 harness、属性/模糊循环、二分 harness、差分循环，最后是人工脚本 scripts/hitl-loop.template.sh。随后收紧循环：更快、信号更锐利、更确定。对非确定性缺陷，目标是提高复现率而非干净复现。若确实无法构建循环，应停止并明确说明，列出已尝试内容，向用户索取环境访问、脱敏产物或临时生产埋点许可，不得在无循环的情况下进入假设阶段。
阶段二复现并最小化：确认循环产生的正是用户描述的症状，可多次复现，并捕获精确症状；随后逐步削减输入、调用者、配置、数据与步骤，直到每个剩余元素都是承重的。
阶段三提出 3–5 个可证伪、有排序的假设，每个须写出预测，并在测试前展示给用户。
阶段四埋点：每个探针映射到具体预测，一次只改一个变量；优先调试器/REPL，其次定向日志；禁止“记录一切再 grep”；日志加唯一前缀如 [DEBUG-a4f2] 便于清理。性能分支应先建立基线测量，再二分，先测量后修复。
阶段五修复与回归测试：仅当存在正确接缝时才先写回归测试；若无正确接缝，这本身就是发现，需记录。有则把最小复现变成失败测试，看其失败，应用修复，看其通过，再对原始场景重跑阶段一循环。
阶段六清理：确认原始复现不再出现、回归测试通过（或记录接缝缺失）、所有 [DEBUG-...] 埋点已移除、一次性原型已删除，并在提交/PR 信息中写明最终正确的假设。
最佳实践：保持上游流程完整，偏离需明确记录；在每个由用户决策的节点停下来交还控制权；优先小而可逆的改动，明示假设。参考资料：上游技能 mattpocock/skills（commit 3cca18b，MIT）、脚本 scripts/hitl-loop.template.sh、项目标准 .agent-skills/skill-standardization/SKILL.md、校验脚本 .agent-skills/skill-standardization/scripts/validate_skill.sh。限制：具体支持的编程语言、平台或运行环境未提供。