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: {phase_num}-CONTEXT.md — decisions clear enough that downstream agents can act without asking the user again
Context files are resolved in-workflow using init phase-op and roadmap/state tool calls.
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
1---2name: gsd-discuss-phase3description: Gather phase context through adaptive questioning before planning4---5
6<objective>
7Extract implementation decisions that downstream agents need — researcher and planner will use CONTEXT.md to know what to investigate and what choices are locked.
8
9**How it works:**
101. Analyze the phase to identify gray areas (UI, UX, behavior, etc.)
112. Present gray areas — user selects which to discuss
123. Deep-dive each selected area until satisfied
134. Create CONTEXT.md with decisions that guide research and planning
14
15**Output:** `{phase_num}-CONTEXT.md` — decisions clear enough that downstream agents can act without asking the user again
16</objective>
17
18<execution_context>
19@{{PLATFORM_ROOT}}/get-shit-done/workflows/discuss-phase.md
20@{{PLATFORM_ROOT}}/get-shit-done/templates/context.md
21</execution_context>
22
23<context>
24Phase number: $ARGUMENTS (required)
25
26Context files are resolved in-workflow using `init phase-op` and roadmap/state tool calls.
27</context>
28
29<process>
301. Validate phase number (error if missing or not in roadmap)
312. Check if CONTEXT.md exists (offer update/view/skip if yes)
323. **Analyze phase** — Identify domain and generate phase-specific gray areas
334. **Present gray areas** — Multi-select: which to discuss? (NO skip option)
345. **Deep-dive each area** — 4 questions per area, then offer more/next
356. **Write CONTEXT.md** — Sections match areas discussed
367. Offer next steps (research or plan)
37
38**CRITICAL: Scope guardrail**
39- Phase boundary from ROADMAP.md is FIXED
40- Discussion clarifies HOW to implement, not WHETHER to add more
41- If user suggests new capabilities: "That's its own phase. I'll note it for later."
42- Capture deferred ideas — don't lose them, don't act on them
43
44**Domain-aware gray areas:**
45Gray areas depend on what's being built. Analyze the phase goal:
46- Something users SEE → layout, density, interactions, states
47- Something users CALL → responses, errors, auth, versioning
48- Something users RUN → output format, flags, modes, error handling
49- Something users READ → structure, tone, depth, flow
50- Something being ORGANIZED → criteria, grouping, naming, exceptions
51
52Generate 3-4 **phase-specific** gray areas, not generic categories.
53
54**Probing depth:**
55- Ask 4 questions per area before checking
56- "More questions about [area], or move to next?"
57- If more → ask 4 more, check again
58- After all areas → "Ready to create context?"
59
60**Do NOT ask about (Claude handles these):**
61- Technical implementation
62- Architecture choices
63- Performance concerns
64- Scope expansion
65</process>
66
67<success_criteria>
68- Gray areas identified through intelligent analysis
69- User chose which areas to discuss
70- Each selected area explored until satisfied
71- Scope creep redirected to deferred ideas
72- CONTEXT.md captures decisions, not vague vision
73- User knows next steps
74</success_criteria>
shoootyou