---
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 模式红线**：代码分析得出的假设必须标注证据来源（文件路径 + 行号），不能凭直觉编造。