/kata:discuss-phase
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}-CONTEXT.md — decisions clear enough that downstream agents can act without asking the user again
Load project state:
@.planning/STATE.md
Load roadmap:
@.planning/ROADMAP.md
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: discussing-phases3description: Use this skill when gathering phase context through adaptive questioning before planning, clarifying implementation decisions, or exploring gray areas for a phase. Triggers include "discuss phase", "clarify phase", "gather context", "what are the gray areas", and "phase discussion".4---5
6<user_command>/kata:discuss-phase</user_command>
7
8
9<objective>
10Extract implementation decisions that downstream agents need — researcher and planner will use CONTEXT.md to know what to investigate and what choices are locked.
11
12**How it works:**
131. Analyze the phase to identify gray areas (UI, UX, behavior, etc.)
142. Present gray areas — user selects which to discuss
153. Deep-dive each selected area until satisfied
164. Create CONTEXT.md with decisions that guide research and planning
17
18**Output:** `{phase}-CONTEXT.md` — decisions clear enough that downstream agents can act without asking the user again
19</objective>
20
21<execution_context>
22@./references/phase-discuss.md
23@./references/context-template.md
24</execution_context>
25
26<context>
27Phase number: $ARGUMENTS (required)
28
29**Load project state:**
30@.planning/STATE.md
31
32**Load roadmap:**
33@.planning/ROADMAP.md
34</context>
35
36<process>
371. Validate phase number (error if missing or not in roadmap)
382. Check if CONTEXT.md exists (offer update/view/skip if yes)
393. **Analyze phase** — Identify domain and generate phase-specific gray areas
404. **Present gray areas** — Multi-select: which to discuss? (NO skip option)
415. **Deep-dive each area** — 4 questions per area, then offer more/next
426. **Write CONTEXT.md** — Sections match areas discussed
437. Offer next steps (research or plan)
44
45**CRITICAL: Scope guardrail**
46- Phase boundary from ROADMAP.md is FIXED
47- Discussion clarifies HOW to implement, not WHETHER to add more
48- If user suggests new capabilities: "That's its own phase. I'll note it for later."
49- Capture deferred ideas — don't lose them, don't act on them
50
51**Domain-aware gray areas:**
52Gray areas depend on what's being built. Analyze the phase goal:
53- Something users SEE → layout, density, interactions, states
54- Something users CALL → responses, errors, auth, versioning
55- Something users RUN → output format, flags, modes, error handling
56- Something users READ → structure, tone, depth, flow
57- Something being ORGANIZED → criteria, grouping, naming, exceptions
58
59Generate 3-4 **phase-specific** gray areas, not generic categories.
60
61**Probing depth:**
62- Ask 4 questions per area before checking
63- "More questions about [area], or move to next?"
64- If more → ask 4 more, check again
65- After all areas → "Ready to create context?"
66
67**Do NOT ask about (Claude handles these):**
68- Technical implementation
69- Architecture choices
70- Performance concerns
71- Scope expansion
72</process>
73
74<success_criteria>
75- Gray areas identified through intelligent analysis
76- User chose which areas to discuss
77- Each selected area explored until satisfied
78- Scope creep redirected to deferred ideas
79- CONTEXT.md captures decisions, not vague vision
80- User knows next steps
81</success_criteria>
majiayu000