Diagnose

---
name: diagnose
description: "调查根因未知的运行、构建、测试或性能故障。以日志、复现、对照和可证伪假设定位原因；已知局部修复无需完整诊断流程。"
---

# Evidence-based diagnosis

将用户描述的故障与真实环境对应，区分现象、假设、已证实原因和修复证据。不要用隐藏错误、跳过测试或扩大容错来冒充修复。

## 流程

1. 捕获相关命令、cwd、环境、退出码、日志、输入和最近改动；避免输出凭据。
2. 能安全且合理成本复现时复现；只有需要判断稳定性时重复。昂贵 GPU、线上或破坏性任务不为满足固定次数重复运行。
3. 难以复现时可先用既有日志、回放、源码和配置提出假设，并标明不确定性。无复现不禁止调查，但不能据此声称修复已验证。
4. 对有证据支持的候选排序，用最小检查区分原因。单个因果实验保持变量可归因，独立只读检查可以并行；不强制固定假设数量。
5. 证据充分后做授权范围内的最小修复，验证原始症状及受影响路径。不要把相邻无关失败混成同一个根因。
6. 持续有信息增益且在预算内时继续。无新证据、需要外部访问或成本超出授权时说明具体缺口；不以固定三轮自动宣布阻塞。

## 完成与输出

给出故障、支持/排除的关键假设、根因或未定项、修改及验证。只读诊断可交付有边界的结论，无需强制修代码。调查中途即把关键 dead ends、排除的假设和恢复命令写入本轨道 state 的 Evidence 行（不写其他轨道文件；无本轨道行时不暗示新建，随本次报告交付），不等收尾；长调查后重读任务入口防漂移。值得复用的根因按 lessons 格式提升到项目恢复面的 lessons；项目为 harness backend 而 lessons 文件不存在时，随首次落笔创建。

工作台级问题可参考 `references/harness-layer-patterns.md`；不要因一条命令失败就安装新工具或重建 harness。

## Recommended next skill

- 原因已明但需修改：`implement`；修复复杂或用户要求评审：`review`。
- 简单修复已验证或只读诊断已交付：结束。
- 仅在实际缺口需改工作台时：`harness-builder`；目标改变才回 `plan`。