<objective>
Extract implementation decisions that downstream agents need — researcher and planner will use CONTEXT.md to know what to investigate and what choices are locked.
How it works:
- Analyze the phase to identify gray areas (UI, UX, behavior, etc.)
- Present gray areas — user selects which to discuss
- Deep-dive each selected area until satisfied
- Create CONTEXT.md with decisions that guide research and planning
Output: — decisions clear enough that downstream agents can act without asking the user again
</objective>
<execution_context>
@{{PLATFORM_ROOT}}/get-shit-done/workflows/discuss-phase.md
@{{PLATFORM_ROOT}}/get-shit-done/templates/context.md
</execution_context>
<context>
Phase number: $ARGUMENTS (required)
Context files are resolved in-workflow using
and roadmap/state tool calls.
</context>
<process>
1. Validate phase number (error if missing or not in roadmap)
2. Check if CONTEXT.md exists (offer update/view/skip if yes)
3. **Analyze phase** — Identify domain and generate phase-specific gray areas
4. **Present gray areas** — Multi-select: which to discuss? (NO skip option)
5. **Deep-dive each area** — 4 questions per area, then offer more/next
6. **Write CONTEXT.md** — Sections match areas discussed
7. Offer next steps (research or plan)
CRITICAL: Scope guardrail
- Phase boundary from ROADMAP.md is FIXED
- Discussion clarifies HOW to implement, not WHETHER to add more
- If user suggests new capabilities: "That's its own phase. I'll note it for later."
- Capture deferred ideas — don't lose them, don't act on them
Domain-aware gray areas:
Gray areas depend on what's being built. Analyze the phase goal:
- Something users SEE → layout, density, interactions, states
- Something users CALL → responses, errors, auth, versioning
- Something users RUN → output format, flags, modes, error handling
- Something users READ → structure, tone, depth, flow
- Something being ORGANIZED → criteria, grouping, naming, exceptions
Generate 3-4 phase-specific gray areas, not generic categories.
Probing depth:
- Ask 4 questions per area before checking
- "More questions about [area], or move to next?"
- If more → ask 4 more, check again
- After all areas → "Ready to create context?"
Do NOT ask about (Claude handles these):
- Technical implementation
- Architecture choices
- Performance concerns
- Scope expansion
</process>
<success_criteria>
- Gray areas identified through intelligent analysis
- User chose which areas to discuss
- Each selected area explored until satisfied
- Scope creep redirected to deferred ideas
- CONTEXT.md captures decisions, not vague vision
- User knows next steps
</success_criteria>
<objective>
提取下游Agent所需的实施决策——研究员和规划师将使用CONTEXT.md了解需要调研的内容以及已确定的选择。
工作原理:
- 分析阶段以识别模糊领域(UI、UX、行为等)
- 呈现模糊领域——用户选择要讨论的内容
- 深入探讨每个选定领域,直到满意为止
- 创建CONTEXT.md,记录指导调研和规划的决策
输出: —— 决策内容需足够清晰,确保下游Agent无需再次询问用户即可开展工作
</objective>
<execution_context>
@{{PLATFORM_ROOT}}/get-shit-done/workflows/discuss-phase.md
@{{PLATFORM_ROOT}}/get-shit-done/templates/context.md
</execution_context>
<context>
阶段编号:$ARGUMENTS(必填)
上下文文件通过工作流中的
和路线图/状态工具调用解析。
</context>
<process>
1. 验证阶段编号(若缺失或不在路线图中则报错)
2. 检查CONTEXT.md是否存在(若存在则提供更新/查看/跳过选项)
3. **分析阶段** —— 确定领域并生成阶段特定的模糊领域
4. **呈现模糊领域** —— 多选:要讨论哪些内容?(无跳过选项)
5. **深入探讨每个领域** —— 每个领域提出4个问题,然后提供更多/下一个选项
6. **撰写CONTEXT.md** —— 章节与讨论的领域匹配
7. 提供下一步操作选项(调研或规划)
关键:范围护栏
- ROADMAP.md中的阶段边界是固定的
- 讨论旨在明确如何实施,而非是否添加更多内容
- 若用户提出新功能:“这属于独立阶段。我会稍后记录。”
- 记录延迟的想法——不要丢失,但不要立即执行
领域感知的模糊领域:
模糊领域取决于正在构建的内容。分析阶段目标:
- 用户可见的内容 → 布局、密度、交互、状态
- 用户调用的内容 → 响应、错误、认证、版本控制
- 用户运行的内容 → 输出格式、标志、模式、错误处理
- 用户阅读的内容 → 结构、语气、深度、流程
- 正在整理的内容 → 标准、分组、命名、例外情况
生成3-4个阶段特定的模糊领域,而非通用类别。
探索深度:
- 每个领域先提出4个问题,再确认
- “继续提问关于[领域]的问题,还是进入下一个?”
- 若选择更多 → 再提出4个问题,再次确认
- 所有领域讨论完毕后 → “是否准备好创建上下文?”
请勿询问以下内容(由Claude处理):
- 技术实现
- 架构选择
- 性能问题
- 范围扩展
</process>
<success_criteria>
- 通过智能分析识别模糊领域
- 用户选择了要讨论的领域
- 每个选定领域都探讨至用户满意
- 范围蔓延被引导至延迟想法
- CONTEXT.md记录的是决策,而非模糊愿景
- 用户了解下一步操作
</success_criteria>