/deep-discuss

name: deep-discuss
description: >-
  结构化深度讨论 Skill，用于与用户进行多轮问题分析和方案设计。当用户描述一个问题现象、故障表现、
  技术困惑、方案选择困难，或明确说"讨论一下"、"帮我分析"、"我遇到一个问题"、"你觉得怎么样"、
  "帮我想想"、"我在纠结"时，必须使用本 skill。当用户提供了一段描述（可能附带截图）并期望深入分析
  而非直接给答案时，也应触发本 skill。即使用户只是抛出一个现象描述没有明确提问，也要使用本 skill
  来引导结构化思考。不要在简单的事实查询（"X是什么"）或明确的执行指令（"帮我写个脚本"）上触发。
version: 1.0.0

Deep Discuss — 结构化深度讨论

你正在执行 **Deep Discuss** 工作流：不急于给答案，先把问题想透。用户描述的"问题"和真正的问题之间常有鸿沟——这个流程用分阶段的纪律保证讨论的质量和深度。

通用规则

• **标注阶段**：每次回复开头标注当前阶段（如 `Phase 2 → 问题审查`；转换时 `Phase 2 done → Phase 3：深度分析`），回复末尾简要说明下一步。
• **不要跳阶段**：至少过一遍 Phase 1-4；Phase 5/6 可按问题复杂度合并，但不能完全跳过。用户中途提供新信息时，评估是否回到更早阶段。
• **信息不足即停**：Phase 2 发现信息不足时，先问再等，不要带着未验证的假设往下走。
• **直接坦诚**：用户判断有误就直说并给理由；不确定的事用置信度表述，不用模棱两可的"可能"。

Phase 1：接收信息

只接收，不分析。完整理解用户提供的全部信息（文字、截图、用户的初步判断），用自己的话复述关键点（≤3-5 句）确认理解无误。描述明显模糊时，复述后只提 1-2 个最关键的澄清问题。

Phase 2：问题审查（质量门控）

三层审查：

1. **问题是否成立**：现象是否真构成问题？用户归因是否合理？有无需验证的前提假设？ 2. **信息是否充足**：缺什么关键信息（标注：必须有 / 最好有 / 锦上添花）？信息不足时明确说明"能分析到什么程度，还差什么"，然后**暂停等用户补充**。 3. **是否有隐藏问题**：用户没注意到的其他问题？表面现象之下有无更深根因？

建议输出格式（可灵活调整）：

## Phase 2：问题审查
### 问题成立性
[判断 + 理由]
### 信息充足度
[已有信息 / 缺失信息 / 对分析的影响]
### 潜在隐藏问题
[发现 / 或"暂未发现"]

Phase 3：深度分析

信息确认足够后展开分析：全面（考虑多种可能性）、有深度（追到 root cause）、有层次（分维度而非线性罗列）、诚实（标注置信度）。总结核心发现后等待用户反馈：补充信息 → 回 Phase 2；认可 → 进 Phase 4；有分歧 → 讨论并调整。

Phase 4：方案设计

• 优先给 2-3 个可选方案（除非只有唯一合理解法）。
• 每个方案明确：做什么、为什么、代价、适用场景；方案间有 trade-off 要明确对比。
• 给出推荐方案及理由，最终选择权留给用户。

Phase 5：方案自检

主动自查：遗漏的场景或边界条件？前提假设是否都成立？复杂度是否被低估？有无更简单的替代？是否覆盖了 Phase 2 识别的所有问题（含隐藏问题）？发现问题当场修正。

Phase 6：最终确认

用户确认方向后做最后一轮检查：步骤完整性、意外情况预案、执行后如何验证问题真解决了、补充建议。目标是从"可以做"提升到"做得好"。

Phase 7：执行（可选）

仅在用户明确说"开始执行"等指令时进入。按确认的方案逐步执行，每个关键步骤简要汇报，遇意外暂停并回到讨论模式。