discuss-phase

name	discuss-phase
description	融合 GSD discuss-phase 与 gstack office-hours 的预编码设计讨论技能。 在 /team-intake 之后、/team-plan 之前，通过苏格拉底式质疑捕获灰色地带、 用户偏好和关键假设，产出 CONTEXT.md 供后续规划和实现消费。

Discuss Phase

用途

• 把"需求文字看起来清楚了就开干"改成"先把灰色地带和隐含假设摊开讨论"。
• 适合需求有模糊空间、存在多种可行路线、或用户偏好尚未表达的场景。
• 在 /team-intake 完成后、/team-plan 之前推荐触发。

两种模式

discuss（交互质疑模式）

逐项质疑需求中的灰色地带，引导用户做出偏好选择。适用于用户在场、可以即时回答的场景。

assumptions（代码分析优先模式）

先扫描代码库识别现有模式和约束，把代码中已有的事实作为假设基础，仅对代码无法回答的灰色地带提问。适用于代码库已有大量存量逻辑的迭代场景。

默认做法

1. 收集输入：读取 /team-intake 的产出（PRD、需求简报），提取目标、范围、约束和待确认项。

2. 识别灰色地带：按以下维度自动扫描未锁定的决策点：

   • UI 交互：状态管理方式、加载/空/错误态策略、动效取舍
   • API/数据：分页策略、错误码规范、缓存策略、数据保留周期
   • 架构：同步/异步、推/拉、单体/微服务边界
   • 业务规则：边界条件处理、权限粒度、审批流程节点
   • 质量：性能预算、浏览器兼容基线、可访问性等级
   • 部署：环境策略、Feature Flag、灰度比例

3. Forcing Questions（来自 gstack office-hours 方法论）：

   • 如果这个功能只能做一件事，那件事是什么？
   • 这个功能的用户是谁？他们当前的替代方案是什么？
   • 半年后回看，什么情况下我们会认为这是浪费时间？
   • 最小可交付版本是什么？跟完整版的差距在哪？
   • 有哪些假设一旦不成立，方案就会完全不同？
   • 哪个决策如果做错了代价最大？

4. 逐项讨论：每个灰色地带呈现为：

   • 背景：为什么这是一个需要讨论的点
   • 选项：可行方案列表，每个带利弊分析
   • 推荐：基于代码分析和最佳实践的建议
   • 等待用户确认或修改

5. 产出 CONTEXT.md：将所有讨论结论写入 docs/artifacts/{slug}/context.md，包含：

   • 确认的技术偏好和约束
   • 灰色地带的最终决策
   • 待进一步验证的假设（标记为 [ASSUMPTION]）
   • 明确排除的选项及排除原因

触发信号

• /team-intake 产出中包含 3 个以上待确认项。
• 需求涉及新领域或新技术栈，团队缺乏先验经验。
• 存在多个合理的技术路线，无法在 intake 阶段直接锁定。
• 需求涉及跨团队或跨系统边界。
• 用户显式要求"先讨论一下再开始"。

配套约束

1. 不替代 intake：discuss-phase 消费 intake 的输出，不重新做需求收集。
2. 不替代 plan：discuss-phase 产出偏好和约束，不产出任务拆解和排期。
3. 时间控制：单次 discuss 控制在 6-10 个灰色地带以内，超出时建议分批或升级给 architect。
4. 结论必须落盘：所有讨论结论写入 context.md，不停留在对话上下文中。
5. assumptions 模式红线：代码分析得出的假设必须标注证据来源（文件路径 + 行号），不能凭直觉编造。