diagnose 是一个用于排查疑难缺陷和性能回归的诊断技能，核心是一套有纪律的循环：复现 → 最小化 → 假设 → 插桩 → 修复 → 回归测试。只有在明确说明理由时才可跳过阶段。探索代码库时，建议使用项目的领域术语表建立模块心智模型，并查看所涉区域的 ADR。
第一阶段是构建反馈回路，这是整个技能的关键。若能为缺陷建立快速、确定、可由智能体运行的通过/失败信号，二分、假设检验和插桩都只是消费该信号；没有信号，单看代码无济于事。构建方式大致按顺序尝试：在能触达缺陷的接缝处写失败测试（单元、集成、端到端）；对运行中的开发服务器用 curl 或 HTTP 脚本；用固定输入调用 CLI 并对比已知良好快照；用 Playwright/Puppeteer 无头浏览器驱动 UI 并断言 DOM、控制台或网络；回放捕获的 trace；搭建一次性最小化 harness；属性或模糊测试循环；二分 harness 以配合 git bisect run；差分循环对比新旧版本或两种配置；最后才用人工介入的 bash 脚本。回路本身也要迭代：更快、信号更锐利、更确定。非确定性缺陷的目标不是干净复现，而是提高复现率。若确实无法构建回路，应停下并明确说明，列出尝试过的方法，向用户请求环境访问、捕获产物或临时生产插桩许可，不要在没有回路时进入假设阶段。
第二阶段是复现：运行回路，确认失败模式与用户描述一致、可多次复现或复现率足够高，并捕获确切症状。第三阶段是假设：先给出 3–5 个排序假设，每个必须可证伪并说明预测，展示给用户后再测试。第四阶段是插桩：每个探针对应一个具体预测，一次只改一个变量；优先调试器或 REPL，其次在区分假设的边界打定向日志，避免“全量日志再 grep”，调试日志加唯一前缀如 [DEBUG-a4f2] 便于清理；性能回归应先建立基线测量再二分。第五阶段是修复与回归测试：先写回归测试，但仅在存在正确接缝时；若接缝过浅，应记录该发现。第六阶段是清理与复盘：确认原始复现不再出现、回归测试通过或记录接缝缺失、移除所有调试插桩、删除一次性原型，并在提交信息中写明最终正确的假设；随后思考如何预防此类缺陷，若涉及架构问题可转交 /improve-codebase-architecture 技能。
适用场景为难以定位的缺陷与性能回归排查。限制：资料未提供安装命令、平台支持、收费方式或具体使用步骤，这些信息暂未提供。