gsd-discuss-phase

提取下游 Agent 需要的实施决策——研究人员和规划人员会使用 CONTEXT.md 了解需要调查的内容，以及哪些选择已经确定。

工作方式：

1. 分析阶段，找出模糊之处（UI、UX、行为等）
2. 列出模糊之处——由用户选择要讨论的内容
3. 深入讨论每个选定的方面，直到用户满意
4. 创建 CONTEXT.md，其中的决策将为研究和规划提供指导

输出： {phase_num}-CONTEXT.md——决策清晰明确，下游 Agent 无需再次询问用户即可采取行动

<execution_context> @{{PLATFORM_ROOT}}/get-shit-done/workflows/discuss-phase.md @{{PLATFORM_ROOT}}/get-shit-done/templates/context.md </execution_context>

阶段编号：$ARGUMENTS（必填）

上下文文件会在工作流中通过 init phase-op 和路线图／状态工具调用进行解析。

1. 验证阶段编号（如果缺失或不在路线图中，则报错） 2. 检查 CONTEXT.md 是否存在（如果存在，则提供更新、查看或跳过选项） 3. **分析阶段**——识别领域并生成针对该阶段的模糊之处 4. **列出模糊之处**——多选：要讨论哪些？（不提供跳过选项） 5. **深入讨论每个方面**——每个方面提问 4 个问题，然后询问是继续还是进入下一项 6. **编写 CONTEXT.md**——各个章节与讨论过的方面相对应 7. 提供后续步骤（研究或规划）

重要：范围边界

• ROADMAP.md 中的阶段边界是固定的
• 讨论用于明确如何实现，而不是是否增加更多内容
• 如果用户提出新功能：“这属于另一个阶段。我会记下来，留待以后处理。”
• 记录延期的想法——不要遗漏，也不要采取行动

根据领域确定模糊之处： 模糊之处取决于要构建的内容。分析阶段目标：

• 用户会看到的内容 → 布局、信息密度、交互、状态
• 用户会调用的内容 → 响应、错误、身份验证、版本控制
• 用户会运行的内容 → 输出格式、标志、模式、错误处理
• 用户会阅读的内容 → 结构、语气、深度、流程
• 需要整理的内容 → 标准、分组、命名、例外情况

生成 3–4 个针对该阶段的模糊之处，而非通用类别。

深入探讨：

• 每个方面先提问 4 个问题，再确认是否继续
• “关于 [方面] 还要问更多问题，还是进入下一项？”
• 如果要继续，则再提问 4 个问题，然后再次确认
• 讨论完所有方面后，询问：“是否准备好创建上下文文件？”

不要询问以下内容（由 Claude 处理）：

• 技术实现
• 架构选择
• 性能问题
• 扩大范围

<success_criteria>

• 通过智能分析找出模糊之处
• 用户选择要讨论的方面
• 对每个选定的方面进行探讨，直到用户满意
• 将范围蔓延引导为延期想法
• CONTEXT.md 记录的是明确决策，而非模糊愿景
• 用户了解后续步骤 </success_criteria>