thedixitjain Discuss Phase
用途
- 把"需求文字看起来清楚了就开干"改成"先把灰色地带和隐含假设摊开讨论"。
- 适合需求有模糊空间、存在多种可行路线、或用户偏好尚未表达的场景。
- 在
/team-intake完成后、/team-plan之前推荐触发。
两种模式
discuss（交互质疑模式）
逐项质疑需求中的灰色地带，引导用户做出偏好选择。适用于用户在场、可以即时回答的场景。
assumptions（代码分析优先模式）
先扫描代码库识别现有模式和约束，把代码中已有的事实作为假设基础，仅对代码无法回答的灰色地带提问。适用于代码库已有大量存量逻辑的迭代场景。
默认做法
收集输入：读取
/team-intake的产出（PRD、需求简报），提取目标、范围、约束和待确认项。识别灰色地带：按以下维度自动扫描未锁定的决策点：
- UI 交互：状态管理方式、加载/空/错误态策略、动效取舍
- API/数据：分页策略、错误码规范、缓存策略、数据保留周期
- 架构：同步/异步、推/拉、单体/微服务边界
- 业务规则：边界条件处理、权限粒度、审批流程节点
- 质量：性能预算、浏览器兼容基线、可访问性等级
- 部署：环境策略、Feature Flag、灰度比例
Forcing Questions（来自 gstack office-hours 方法论）：
- 如果这个功能只能做一件事，那件事是什么？
- 这个功能的用户是谁？他们当前的替代方案是什么？
- 半年后回看，什么情况下我们会认为这是浪费时间？
- 最小可交付版本是什么？跟完整版的差距在哪？
- 有哪些假设一旦不成立，方案就会完全不同？
- 哪个决策如果做错了代价最大？
逐项讨论：每个灰色地带呈现为：
- 背景：为什么这是一个需要讨论的点
- 选项：可行方案列表，每个带利弊分析
- 推荐：基于代码分析和最佳实践的建议
- 等待用户确认或修改
产出 CONTEXT.md：将所有讨论结论写入
docs/artifacts/{slug}/context.md，包含：- 确认的技术偏好和约束
- 灰色地带的最终决策
- 待进一步验证的假设（标记为
[ASSUMPTION]） - 明确排除的选项及排除原因
触发信号
/team-intake产出中包含 3 个以上待确认项。- 需求涉及新领域或新技术栈，团队缺乏先验经验。
- 存在多个合理的技术路线，无法在 intake 阶段直接锁定。
- 需求涉及跨团队或跨系统边界。
- 用户显式要求"先讨论一下再开始"。
配套约束
- 不替代 intake：discuss-phase 消费 intake 的输出，不重新做需求收集。
- 不替代 plan：discuss-phase 产出偏好和约束，不产出任务拆解和排期。
- 时间控制：单次 discuss 控制在 6-10 个灰色地带以内，超出时建议分批或升级给
architect。 - 结论必须落盘：所有讨论结论写入
context.md，不停留在对话上下文中。 - assumptions 模式红线：代码分析得出的假设必须标注证据来源（文件路径 + 行号），不能凭直觉编造。
Source: hashgraph-online/awesome-codex-plugins → plugins/Colin4k1024/tsp/skills/discuss-phase/SKILL.md