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

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

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

<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>