Diagnose 是一个面向疑难缺陷（hard bugs）与性能回退（performance regressions）的诊断技能，核心是提供一套有纪律的诊断循环：复现 → 最小化 → 假设 → 插桩 → 修复 → 回归测试。资料强调只有在明确论证合理时才可跳过阶段，并建议在探索代码库时结合项目的领域术语表建立模块心智模型，同时查看所触碰区域的 ADR（架构决策记录）。
用途与核心思路 该技能把“构建反馈回路”视为诊断的关键步骤，其余环节相对机械。若能为缺陷建立一个快速、确定、可由智能体运行的通过/失败信号，那么二分、假设检验与插桩都只是消费这一信号；反之，仅靠阅读代码难以定位问题。因此资料建议在这一阶段投入不成比例的努力，保持积极与创造性，不轻易放弃。
主要能力 资料列出了多种构建反馈回路的途径，大致按顺序尝试：在能触达缺陷的接缝处写失败测试（单元、集成、端到端）；针对运行中的开发服务器编写 curl / HTTP 脚本；用固定输入调用 CLI 并将 stdout 与已知良好快照做 diff；使用无头浏览器脚本（Playwright / Puppeteer）驱动 UI 并对 DOM、控制台、网络进行断言；回放捕获的 trace（将真实网络请求、载荷或事件日志存盘，在隔离环境中重放代码路径）；搭建一次性 harness（启动系统最小子集，用一次性函数调用触达缺陷代码路径）；属性/模糊测试循环（针对“有时输出错误”运行大量随机输入寻找失败模式）；二分 harness（缺陷出现在两个已知状态之间时，自动化“在状态 X 启动、检查、重复”，以便用 git bisect run）；差分循环（同一输入分别经过旧版本与新版本或两套配置并对比输出）；最后是人机协同的 bash 脚本，借助 scripts/hitl-loop.template.sh 驱动人工点击并把捕获输出回传。
回路本身的迭代 资料把回路当作产品来打磨：能否更快（缓存初始化、跳过无关初始化、缩小测试范围）；能否让信号更锐利（断言具体症状而非“没有崩溃”）；能否更确定（固定时间、设置随机种子、隔离文件系统、冻结网络）。30 秒的不稳定回路几乎不比没有回路好，2 秒的确定性回路则是调试利器。对于非确定性缺陷，目标不是干净的复现，而是提高复现率：循环触发 100 次、并行化、加压、缩小时间窗口、注入 sleep，直到复现率达到可调试水平。
使用方式与阶段 若确实无法构建回路，应停下并明确说明，列出尝试过的办法，并向用户请求：能复现问题的环境访问权限、捕获的产物（HAR 文件、日志转储、核心转储、带时间戳的录屏），或添加临时生产插桩的许可；在没有回路前不要进入假设阶段。第二阶段是运行回路并观察缺陷出现，确认它与用户描述一致、可多次复现（或非确定性缺陷复现率足够高），并捕获确切症状供后续验证。第三阶段生成 3–5 个排序假设再逐一测试，每个假设须可证伪并说明预测，在测试前把排序列表给用户看以利用其领域知识，用户不在时按自己的排序继续。第四阶段插桩，每个探针须对应第三阶段的某个预测，一次只改一个变量；优先使用调试器/REPL，其次在能区分假设的边界处打定向日志，不要“记录一切再 grep”，每条调试日志带唯一前缀（如 [DEBUG-a4f2]）以便最终用一次 grep 清理；性能问题则先建立基线测量（计时 harness、performance.now()、profiler、查询计划）再二分，先测量后修复。第五阶段先写回归测试再修复，但前提是存在正确的接缝（测试能按调用点真实触发缺陷模式）；若接缝过浅，测试会带来虚假信心，此时应把“缺少正确接缝”本身作为发现记录下来。有正确接缝时，把最小化复现转为该接缝处的失败测试，观察其失败，应用修复，观察其通过，并再次对原始未最小化场景运行第一阶段回路。第六阶段为清理与复盘，宣布完成前必须确认：原始复现不再出现、回归测试通过（或记录接缝缺失）、所有 [DEBUG-...] 插桩已通过前缀 grep 清除、一次性原型已删除或移至明确标记的调试位置、正确的假设写入 commit / PR 信息；随后思考本可如何预防该缺陷，若涉及架构变更则连同细节移交给 /improve-codebase-architecture 技能，且该建议应在修复落地后提出。
适用场景与限制 该技能适用于疑难缺陷排查、间歇性故障、性能回退定位和需要系统化回归防护的工程场景。限制与约束包括：资料未提供具体安装命令、运行环境、许可或收费信息；其流程依赖能否构建反馈回路，若无法构建则需外部配合；回归测试的可行性取决于代码库是否存在正确接缝。