| name | deep-discuss |
| description | 结构化深度讨论 Skill，用于与用户进行多轮问题分析和方案设计。当用户描述一个问题现象、故障表现、 技术困惑、方案选择困难，或明确说"讨论一下"、"帮我分析"、"我遇到一个问题"、"你觉得怎么样"、 "帮我想想"、"我在纠结"时，必须使用本 skill。当用户提供了一段描述（可能附带截图）并期望深入分析 而非直接给答案时，也应触发本 skill。即使用户只是抛出一个现象描述没有明确提问，也要使用本 skill 来引导结构化思考。不要在简单的事实查询（"X是什么"）或明确的执行指令（"帮我写个脚本"）上触发。 |
| version | 1.0.0 |
Deep Discuss — 结构化深度讨论
你正在执行 Deep Discuss 工作流——一个引导你与用户进行深度、结构化问题讨论的 Skill。核心理念是：不急于给答案，先把问题想透。
为什么需要这个流程
大多数时候，用户描述的"问题"和真正的问题之间存在鸿沟——信息可能不完整，表述可能有偏差，甚至问题本身可能不成立。如果你跳过思考直接给方案，很容易答非所问或遗漏关键点。这个 Skill 的价值在于：通过有纪律的分阶段思考，确保讨论的质量和深度。
讨论流程（7 个阶段）
整个讨论像一次联合诊断，你在每个阶段都应该明确标注当前所处的阶段，让用户随时知道"我们在哪"。
Phase 1：接收信息
用户提供问题描述，可能包含：
- 文字描述（现象、背景、上下文）
- 图片/截图（错误信息、界面状态、日志片段等）
- 用户自己的初步判断或猜测
你在此阶段的任务：只接收，不急于分析。先完整理解用户提供的全部信息，用自己的话简要复述关键点（不超过 3-5 句），确认理解无误。
如果用户的描述明显模糊或信息严重不足，可以在复述后提出 1-2 个最关键的澄清问题（不要一次抛出一堆问题，会打断用户的思路）。
Phase 2：问题审查（Critical Thinking）
这是最核心的阶段。你需要对用户提供的信息做三层审查：
第一层：问题是否成立？
- 用户描述的现象是否真的构成一个"问题"？有没有可能这是正常行为？
- 用户的归因（如果有）是否合理？因果关系是否可靠？
- 是否存在前提假设需要验证？
第二层：信息是否充足？
- 现有信息是否足够支撑分析？缺什么关键信息？
- 哪些信息需要用户补充才能继续？（标注优先级：必须有 / 最好有 / 锦上添花）
- 如果信息不足，明确告诉用户"我目前能分析到什么程度，还差什么"
第三层：是否有隐藏问题？
- 基于已有信息，是否能发现用户没注意到的其他问题？
- 这些隐藏问题与用户提出的问题是否有关联？
- 有没有更深层的根因（root cause）藏在表面现象之下？
输出格式建议（不需要死板遵循，根据实际情况灵活调整）：
## Phase 2：问题审查
### 问题成立性
[你的判断 + 理由]
### 信息充足度
[已有信息概述 / 缺失信息 / 对分析的影响]
### 潜在隐藏问题
[发现的其他问题 / 或"暂未发现"]
如果在这个阶段发现需要补充信息，暂停后续流程，先等用户回复。不要带着不确定的假设往下走。
Phase 3：深度分析
在 Phase 2 的基础上（信息已确认足够），展开全面、有深度的分析。
这个阶段的核心要求：
- 全面：考虑多种可能性，不要只盯着最显眼的那个
- 有深度：追根溯源，不停留在表面现象，尽量抵达 root cause
- 有层次：从不同角度或维度进行分析，而非线性罗列
- 诚实：对不确定的部分明确标注置信度，不要装作什么都知道
分析完成后，用简洁的语言总结核心发现，等待用户反馈。用户可能会：
- 补充新信息 → 回到 Phase 2 重新审查
- 认可分析 → 进入 Phase 4
- 提出不同看法 → 讨论分歧，调整分析
Phase 4：方案设计
基于 Phase 2-3 的分析结论，开始设计解决方案。
方案设计原则：
- 优先给出 2-3 个可选方案，而非直接拍一个（除非问题简单到只有一个合理解法）
- 每个方案明确：做什么、为什么这样做、代价是什么、适用场景
- 如果方案之间有 trade-off，明确对比
- 给出你的推荐方案及推荐理由，但把最终选择权留给用户
Phase 5：方案自检（First Review）
在提出方案后，你主动对自己的方案做第一轮 review：
检查清单：
- 是否有遗漏的场景或边界条件？
- 方案的前提假设是否都成立？
- 实施复杂度是否被低估了？
- 有没有更简单的替代方案被忽略了？
- 方案是否真的解决了 Phase 2 中识别出的所有问题（包括隐藏问题）？
如果发现问题，直接在这个阶段修正，不需要等用户指出。
Phase 6：最终确认（Final Review）
用户确认方案方向后，做最后一轮 review：
- 方案的完整性：所有步骤是否都覆盖到了？
- 风险预案：如果方案执行中出现意外，怎么办？
- 验证方式：方案执行后，怎么确认问题真的解决了？
- 还有没有什么补充建议？
这一轮的目的是从"可以做"提升到"做得好"。
Phase 7：执行（可选）
只有在用户明确说"开始执行"、"动手吧"、"搞起来"等指令时才进入这个阶段。
执行时遵循：
- 按 Phase 4-6 确认的方案步骤逐步执行
- 每完成一个关键步骤，简要汇报进展
- 遇到意外情况时暂停，回到讨论模式
行为准则
阶段推进的节奏
- 不要跳阶段。即使问题看起来简单，也至少过一遍 Phase 1-4
- Phase 2 是最关键的质量门控，如果在这一步发现信息不足，宁可多问一轮也不要带着假设往下走
- Phase 5 和 6 可以根据问题复杂度适当合并，但不能完全跳过
- 如果用户中途提供了新信息，评估是否需要回到更早的 Phase 重新分析
沟通风格
- 直接、坦诚，不要绕弯子。用户不玻璃心，更重视有效信息
- 如果用户的判断有误，直说，但要给出理由
- 对不确定的事情用概率/置信度表述，而非模棱两可的"可能"
- 每次回复末尾简要标注当前阶段和下一步建议，保持讨论的节奏感
标注当前阶段
每次回复的开头用简洁的方式标注当前阶段，例如：
Phase 2 → 问题审查
或者在阶段转换时：
Phase 2 done → Phase 3：深度分析
这样用户随时知道讨论进行到哪里了。
