用途
diagnose-issue 是一个问题诊断技能，用于定位缺陷、失败的测试、构建失败、不稳定行为、异常输出或性能回退的根本原因。它的核心原则是：在改变行为之前，先用证据找到原因。诊断过程默认是只读的，除非用户明确要求修复或实现。
当外部文档或工具行为重要时，使用 research-ladder.md；当仓库中存在术语表（Glossary）和 ADR 时，也应参考。
主要能力
- 建立最快的有效反馈回路：聚焦测试、构建、CLI 调用、请求、浏览器检查、trace 回放、基准测试或小型一次性测试工具。
- 尽可能复现报告的症状并捕获确切的失败信息。对于不稳定行为，记录基线复现率，并提高到足以比较变化的程度。如果无法复现，区分结论与假设，只请求真正缺失的证据。
- 阅读完整错误、日志、堆栈跟踪、近期 diff、依赖/配置变更、环境差异、调用方以及相关的相近可用示例。
- 在不确定性存在时，只保留可排序、可证伪的假设。当直接证据能解释原因时，进入验证，而不是制造替代解释。
- 对区分可能原因的边界进行插桩。通过逐一移除输入、步骤、配置或调用方，将可复现症状最小化，直到只剩关键要素。追踪坏值到其来源，测量性能，并等待真实的异步条件，而不是任意 sleep。
- 陈述最受支持的成因，以及支持或排除重要替代解释的证据。
使用方式
诊断阶段
按上述流程建立反馈回路、复现、阅读证据、保留假设、插桩边界、最小化复现并给出结论。
获得修复授权后
- 当存在有用的接缝时，优先在修复前建立失败的回归路径。
- 应用能解决成因的最小改动。
- 如果公共契约、迁移、持久化、认证/安全行为、生产状态或性能权衡需要负责人判断，先停下并给出选项，再决定是否变更。
- 如果反复修改失败，停止叠加补丁。利用新证据重新评估心智模型、反馈回路和架构。
- 重跑原始反馈回路和相关回归检查；在声称成功前阅读结果。
- 交付前，通过 review-work 将整个范围（不只是最新补丁）交给独立的新上下文审查者；对照主要证据核实被接受的结论，修复被授权的阻塞性发现，并重跑受影响的检查。
- 只移除本任务创建的临时插桩和草稿产物。保留已有的草稿、fixture 和无关工作。
- 如果正确的修复缺少安全的测试或架构接缝，报告该约束，并将未解决的设计问题转给 improve-architecture 或 plan-work。将已经理解、保持行为的清理工作转给 simplify-work，而不是把它藏在 bugfix 里。
适用场景
- 排查 bug、失败的测试、构建失败。
- 处理不稳定（flaky）行为、异常输出。
- 诊断性能回退。
- 在需要证据支撑根因分析、且可能后续需要修复的工程场景中使用。
限制
- 诊断默认只读，不会在未获授权时修改行为。
- 无法复现时，只能区分结论与假设，并请求缺失的关键证据。
- 涉及公共契约、迁移、持久化、认证/安全、生产状态或性能权衡的修复，需要负责人判断，不能自行变更。
- 若缺少安全的测试或架构接缝，需报告约束并转交其他流程。
- 输出应保持紧凑，不应变成实验记录，也不应超出证据声称确定性。
输出
报告保持紧凑，包含：
- 原因与证据
- 修复（仅当获得授权）
- 已执行的验证
- 限制、残余风险或建议的下一步