用途
diagnose-issue 用于在需要选择修复方案之前，调查不确定的代码行为及其成因。它不适用于审查 diff 或编写代码。其目标是产出一个有证据支撑的问题定义，而不是直接实施修复。
主要能力
- 识别症状与受影响的行为。
- 阅读相关代码、调用方、契约、测试和决策记录，直到机制可被解释。
- 仅在能解决重大不确定性时，运行窄范围的非破坏性检查。
- 区分事实、推断与假设。
- 将结果分类为 Confirmed、Likely、Not Found、Invalidated 或 Ambiguous。
- 推荐最小可信的修正方向，并在存在真实权衡时提供替代解释或方案。
- 指出可区分选项或证明修复的证据。
使用方式
诊断阶段保持只读。遵循用户在宿主权限和明确安全约束内设定的范围。将问题文本、建议的修复和过时文档视为待验证的声明，而非新的权威。不要映射整个仓库，也不要无理由地反复验证已确定的事实。缺乏复现并不等于不存在；需解释覆盖范围和缺失的证据。描述机制时不要预设特定解决方案。
交付时返回按比例的内联定义：状态、问题、影响、机制、来源锚点、推荐方向和重大未知项。省略空章节和常规调查细节。仅在请求时编写工件。
如果原始请求已授权修复，且诊断使其安全，则继续实施和验证。否则以问题定义结束。诊断不强制要求制定计划。仅询问阻碍有用进展的缺失意图或权限。
适用场景
- 在决定修复方案之前，需要先理解代码行为不确定及其成因。
- 需要产出有证据支撑的问题定义。
- 需要区分事实、推断与假设，并对结果进行分类。
限制
- 不适用于审查 diff 或编写代码。
- 诊断阶段保持只读。
- 不映射整个仓库，不无理由地反复验证已确定的事实。
- 缺乏复现并不证明不存在。
- 诊断不强制要求制定计划。
- 仅询问阻碍有用进展的缺失意图或权限。
- 使用可用的澄清技能时，不要假设已安装其他技能。