问题定位 Skill

帮助开发者诊断问题的 Agent Skill。接收问题描述和故障日志，通过环境发现+项目代码分析+两阶段分级诊断，输出结构化诊断报告。

执行承诺（无论怎么触发都要遵守）

无论用户输入多简单——哪怕只给一个错误码或一句话描述——都必须尝试执行下方的 6 阶段流程，不要只凭训练记忆直接回答错误码含义。

原因：同一个错误码在不同模块、不同调用方式、不同设备日志下根因可能完全不同；凭记忆给的根因经常是错的，会误导开发者。只有走「线索提取 → 模块识别 → 知识库/文档 → 源码 → 报告」才能给出靠谱结论。

关键原则：尝试执行，而非按输入完备度跳过。 不再按"有没有设备/有没有项目"分档跳过阶段——阶段 0、1、2、3、5、6 都要真正走一遍：

• 缺前置条件（无设备、无项目源码、无 hilogtool 等）时，不得直接跳过该阶段。先尝试执行该阶段的每一个步骤；当某一步确实因缺前置条件无法完成时，在报告里如实记录"该步骤未能执行 + 原因 + 对诊断置信度的影响"，然后继续下一阶段。
• 缺设备/缺日志：阶段2 仍要尝试（检查用户提供的日志、尝试 hdc 连接），采集不到则记录"无法采集运行时日志，结论仅基于静态分析"，并在报告置信度中体现。
• 缺项目源码：阶段5 仍要尝试（在 cwd 下 Glob/Grep 搜索），搜不到相关源码则记录"项目内未找到相关代码"，并基于已有线索给出修改建议方向。

唯一例外——阶段4（深潜分析）按置信度跳过： 阶段4 是否执行由阶段3.3 的置信度评估决定——高置信度跳过阶段4，低置信度执行阶段4（保持现有机制不变）。除阶段4 外，其余阶段无论输入多简单、是否有设备/项目，都要尝试执行。

为什么"尝试"而非"跳过"： 跳过会让 agent 误以为某条证据链已闭合、给出过于自信的根因；而"尝试后记录缺失"能在报告里诚实暴露证据缺口，让开发者知道结论的边界（哪些是实锤、哪些是推断），这才是负责任的诊断。