Discuss Before Plan

决策归讨论，计划归计划。本 skill 的职责是把「先想清楚」和「再拆执行」明确分开：先摸底、再讨论、再确认、最后进入 Plan。这样可以避免在事实还没对齐、边界还没收敛的时候，一边做方案决策、一边写执行步骤，导致计划质量差、返工频繁、讨论和执行相互污染。

目标

• 让用户先确认关键决策，再开始做计划。
• 把事实、假设、建议、已确认决策明确分开，减少误解。
• 产出一份足够清晰的决策摘要，作为后续 Plan 或执行步骤的输入。

快速判定

满足下面任一强信号，或同时满足两项以上弱信号，就应使用本 skill。

强信号

弱信号

应跳过本 skill 的情况

进度清单

1. 摸底 — 读代码/文档，输出「我的理解」+ 待决策问题清单，等用户确认
2. 讨论 — 逐个推荐方案、比较取舍、暴露风险
3. 决策 — 形成决策记录，只记录已确认内容
4. 落盘 — 输出决策摘要，用显式问句询问用户是否保存为文档；未收到明确回复前不继续
5. 转入 Plan — 用户确认后进入 Plan 或执行步骤拆解

核心规则

输出要求

• 语言: 中文
• 风格: 对话式，关键节点输出结构化决策摘要
• 格式: 讨论阶段自然对话，进入决策和转入阶段后使用结构化模板

工作模式

标准模式

适用于复杂任务。按 Phase 1-5 顺序推进，每一轮只收敛一个决策点。

轻量模式

当方案不超过 2 个、预计影响文件不超过 3 个、没有明显架构级影响时，可将 Phase 1-3 压缩为 1-2 轮对话：

• 摸底与初步推荐可以合并到同一轮
• 仍须明确列出决策记录
• 仍须用户确认后，才能进入 Plan 或执行步骤

用户坚持跳过讨论

如果用户明确说“直接 plan / 直接做”，按下面的最小流程处理：

1. 用 2-4 句说明当前仍未确认的关键决策或风险
2. 只追问一个最影响后续方案的问题
3. 如果用户仍坚持跳过，记录为“按用户指定继续”，再进入 Plan 或执行

无显式 Plan Mode 的环境

如果宿主环境没有真正的 Plan Mode：

• 讨论阶段仍然照常执行
• “转入 Plan”改为“开始输出执行步骤”
• 继续保持边界：先确认决策，再拆步骤，不要把两者混在同一轮

讨论工作流 (SOP)

按 Phase 1 → 2 → 3 → 4 → 5 顺序推进。不要跳 Phase，也不要在尚未确认决策时提前写计划。

Phase 1: 摸底 (Understand)

目标: 先建立对现状的共同理解，确保后续讨论不是建立在错误假设上。

做什么:

1. 读代码、读配置、读文档，分析与任务相关的现状。
2. 输出「我的理解」，明确区分：
   • 已确认事实
   • 当前假设
   • 尚未确认的问题
3. 只问一个当前最影响方案选择的问题。
4. 没有用户确认前，不进入方案推荐。

推荐输出模板:

我的理解

现状事实
- ...

当前假设
- ...

还需确认
- ...

需要拍板的决策点
1. [决策问题 1]
2. [决策问题 2]（如有）

现在最需要先定的是第 1 点：[单个问题]

Phase 2: 讨论 (Discuss)

目标: 围绕单个决策点展开讨论，让用户在成本、收益、风险之间做有信息量的选择。

做什么:

1. 主动推荐方案：先亮出推荐选项和理由，再列替代方案及其取舍。
2. 每轮只聚焦一个决策点，优先用选择题或明确选项呈现。
3. 讨论影响面：实现复杂度、受影响模块、测试成本、回滚难度、长期维护成本。
4. 对用户提出的方案做 YAGNI 挑战，不为“也许以后会用到”背书。
5. 如果某个方案有致命缺陷，直接指出并解释原因。

推荐单轮结构:

我建议选 [方案 A]，因为 [核心理由]。

备选方案：
- [方案 B]：优点 ...；代价 ...
- [方案 C]：优点 ...；风险 ...

这个决策真正影响的是：
- 范围：...
- 风险：...
- 后续计划：...

这一步我需要你确认的是：[一个问题]

Phase 3: 决策 (Decide)

目标: 把讨论结果压缩成可执行的决策记录，只保留用户明确确认过的内容。

做什么:

1. 梳理讨论中已达成的共识，列出决策点清单。
2. 每个决策点包含：
   • 决策问题（一句话描述）
   • 确认的选择
   • 选择理由（一句话）
   • 放弃的替代方案（如有）
3. 将未确认项单独放到“待定事项”，不要混入已确认决策。
4. 明确记录非目标，避免后续 scope creep。
5. 逐一和用户确认，未确认项不计入最终记录。

决策记录格式:

决策记录

| # | 决策问题 | 确认选择 | 理由 | 放弃的替代方案 |
|---|---------|---------|------|----------------|
| 1 | [问题] | [选择] | [理由] | [替代方案] |
| 2 | [问题] | [选择] | [理由] | [替代方案] |

非目标
- [当前明确不做的事项]

待定事项
- [仍需确认的内容]

Phase 4: 落盘 (Persist)

目标: 输出决策摘要，并稳定触发一次明确的“是否保存记录”问询。必须在本轮完成后，再进入 Phase 5。

做什么:

1. 输出完整的决策摘要，包含：
   • 已确认决策
   • 实施范围（预计影响的文件/模块）
   • 非目标
   • 已识别的风险及对策
   • 仍待定的事项（如有）
2. 如果待定事项会阻塞计划，明确指出“暂不建议进入 Plan”。
3. 如果待定事项不阻塞计划，明确说明哪些部分可先推进。
4. 询问是否保存为文档：标准模式下默认建议保存；轻量模式也必须显式问一句，不要只用建议语气带过。优先使用用户能直接回答“要 / 不要”的问句。路径优先遵循仓库已有约定（如 .docs/、docs/plans/），无约定时给出建议路径。
5. 等用户对保存与否给出明确回复后再进入 Phase 5。不要把落盘和转入 Plan 合并到同一轮输出。
6. 如果用户没有回答“是否保存”，而是只回复其他信息，先追问一次保存选择，再继续。

决策摘要格式:

决策摘要

已确认决策
- [编号 + 决策内容]

实施范围
- [预计影响的文件/模块列表]

非目标
- [当前不做的事项]

风险与对策
| 风险 | 对策 |
|------|------|
| [风险描述] | [应对方案] |

待定事项
- [如有未决定的事项列在这里]

---
> 我已经把本次已确认决策整理成可直接继续 plan 的摘要了。要不要我顺手把它保存成文档？
> - 如果要，我建议保存到 [建议路径]。
> - 如果不要，我就直接基于这份摘要继续拆 plan。

Phase 5: 转入 Plan (Transition)

目标: 用户对“是否落盘”给出明确选择后，询问是否进入 Plan 或执行步骤拆解。

做什么:

1. 如果用户选择保存，执行保存并确认保存路径。
2. 如果用户选择不保存，明确记录为“未落盘，按当前摘要继续”。
3. 询问用户是否进入 Plan 阶段；只有用户确认后再进入。

决策完备性信号

以下信号表明讨论可以收敛，准备转入 Plan：

1. 待定项已清空或已被降级为不阻塞项：没有阻塞后续计划的未知数
2. 收敛信号：最近 1-2 轮对话没有新增关键决策点
3. 关键类别已覆盖:
   • 范围：做什么、不做什么
   • 方案：技术选型、实现路径
   • 约束：性能要求、兼容性、时间限制
   • 接口：对外暴露的 API / 数据格式
   • 风险：已知风险及对策
4. 用户主动表示: "可以了" / "就这样吧" / "开始 plan"

不需要所有信号同时满足。用户主动表示时可以转入，但若仍有关键风险，应先简短提醒再继续。

常见合理化与应对

反模式 (Anti-Patterns)

常用提示模板

以下是各阶段的参考措辞，不要求逐字使用，目的是传达正确的沟通姿态——先调查再发言、先推荐再展开、先确认再推进。

摸底阶段

• "我先快速看一下现有实现，整理当前事实和还没确认的点。"
• "这是我对现状的理解：[摘要]。如果有偏差，你先纠正我。"
• "现在最影响方案选择的是这个问题：[问题]。先把它定下来。"

讨论阶段

• "我倾向于 [方案 A]，因为 [理由]；[方案 B] 也能做，但代价是 [代价]。"
• "这个方案最大的风险不是抽象上的复杂，而是 [具体失败场景]。"
• "这里我建议先砍掉 [功能/复杂度]，因为它会扩大范围，但暂时不提升当前目标的成功率。"

决策阶段

• "我先把已经确认的决策整理出来，未确认的我会单独列为待定。"
• "下面这些是已确认项；如果其中有哪条还没拍板，你直接指出。"

落盘阶段

• "我已经把本次已确认决策整理成摘要了。要不要我顺手落一份文档，方便后续继续 plan 或团队回看？"
• "如果要保存，我建议放到 [路径]；如果不保存，我就直接基于这份摘要继续。"
• "还有一个待定项会影响实现路径：[事项]。如果现在不定，后面的 plan 只能先写到一半。"

转入阶段

• "决策已保存到 [路径]。是否进入 Plan 阶段，拆成执行步骤？"
• "我先不落盘，直接基于当前摘要继续。是否进入 Plan 阶段？"
• "若你确认无误，我开始把这些决策拆成执行步骤。"