Discuss Before Plan

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

目标

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

快速判定

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

强信号

信号	示例
存在 2 种以上可行方案	"API 缓存要用 Redis、内存，还是依赖 CDN？"
涉及架构、数据流、接口或发布策略决策	"把轮询改成实时推送"
预计影响多个模块或约 5+ 文件	路由、服务层、类型、测试、前端联动一起改
用户明确要求先讨论、分析、对比、评审方案	"我们先别做，先把方案聊清楚"

弱信号

信号	示例
需求仍有歧义	"让它更快一点"
用户想直接要 plan，但问题本身还没收敛	"先给我一个实现计划"
方案选择会显著影响成本、风险、可维护性	单体/拆服务、同步/异步、数据库选型

应跳过本 skill 的情况

信号	示例
纯执行任务	跑测试、格式化、改文案
需求非常明确且几乎无岔路	指定文件、指定行为、指定改法
低风险小改动	修 typo、改常量、重命名变量
用户明确要求直接做且确实不存在关键未决策项	"按这个接口定义实现就行"

进度清单

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

核心规则

原则	说明
事实、假设、确认分开写	不要把推测写成事实，也不要把建议写成已确认决定
每轮只推进一个高杠杆问题	降低用户回答成本，避免一次性扔出问题清单
先给推荐，再给替代	不做中立信息堆砌，要明确表达判断与理由
YAGNI 优先	主动挑战过度设计，明确什么暂时不做
风险必须具体	说清楚失败场景、影响范围、应对方式
决策权在用户	AI 提供分析与建议，关键拍板必须由用户确认
新决策不能混进 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"

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

常见合理化与应对

你可能的想法	现实
"这个需求很清楚，不需要讨论"	你认为清楚 ≠ 用户认为清楚。摸底只需 2 分钟，返工要 2 小时。
"用户说要 plan，我应该直接给 plan"	未收敛的 plan 质量很差，做到一半发现方向不对更浪费。
"先做一版出来再迭代"	关键决策没对齐的实现是赌博，不是迭代。
"问题太多了，我一起问效率更高"	一次多个问题 = 用户挑最简单的回答，剩下的被忽略。逐个推进更快收敛。
"讨论差不多了，落盘这步跳过吧"	不落盘的决策 = 没有决策。下次对话再问一遍，双方都浪费时间。

反模式 (Anti-Patterns)

编号	反模式	正确做法
AP-1	未讨论就进 Plan — 跳过讨论直接分解执行步骤	先走完 Phase 1-3，确认决策后再转入
AP-2	一次抛出多个问题 — 一轮列出多个问题让用户回答	每次只推进一个决策点，逐题深入
AP-3	过度形式化 — 讨论阶段每轮都输出完整决策表格	讨论中自然对话，只在 Phase 3/4 输出结构化记录
AP-4	摘要混入未确认内容 — 把建议写成已确认决策	决策摘要严格只含用户明确 confirm 的内容
AP-5	不做 YAGNI 挑战 — 照单全收不质疑复杂度	主动挑战过度设计，建议移除当前不需要的功能
AP-6	假设环境能力 — 默认一定有 Plan Mode 或专用提问工具	根据环境调整落地方式，原则不变

常用提示模板

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

摸底阶段

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

讨论阶段

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

决策阶段

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

落盘阶段

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

转入阶段

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