gsd-discuss-phase

name	gsd-discuss-phase
description	Gather phase context through adaptive questioning before planning. Use --auto to skip interactive questions (Claude picks recommended defaults).
metadata	{"short-description":"Gather phase context through adaptive questioning before planning. Use --auto to skip interactive questions (Claude picks recommended defaults)."}

<codex_skill_adapter>

A. Skill Invocation

• This skill is invoked by mentioning $gsd-discuss-phase.
• Treat all user text after $gsd-discuss-phase as {{GSD_ARGS}}.
• If no arguments are present, treat {{GSD_ARGS}} as empty.

B. AskUserQuestion → request_user_input Mapping

GSD workflows use AskUserQuestion (Claude Code syntax). Translate to Codex request_user_input:

Parameter mapping:

• header → header
• question → question
• Options formatted as "Label" — description → {label: "Label", description: "description"}
• Generate id from header: lowercase, replace spaces with underscores

Batched calls:

• AskUserQuestion([q1, q2]) → single request_user_input with multiple entries in questions[]

Multi-select workaround:

• Codex has no multiSelect. Use sequential single-selects, or present a numbered freeform list asking the user to enter comma-separated numbers.

Execute mode fallback:

• When request_user_input is rejected (Execute mode), present a plain-text numbered list and pick a reasonable default.

C. Task() → spawn_agent Mapping

GSD workflows use Task(...) (Claude Code syntax). Translate to Codex collaboration tools:

Direct mapping:

• Task(subagent_type="X", prompt="Y") → spawn_agent(agent_type="X", message="Y")
• Task(model="...") → omit (Codex uses per-role config, not inline model selection)
• fork_context: false by default — GSD agents load their own context via <files_to_read> blocks

Parallel fan-out:

• Spawn multiple agents → collect agent IDs → wait(ids) for all to complete

Result parsing:

• Look for structured markers in agent output: CHECKPOINT, PLAN COMPLETE, SUMMARY, etc.
• close_agent(id) after collecting results from each agent </codex_skill_adapter>

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:

1. Load prior context (PROJECT.md, REQUIREMENTS.md, STATE.md, prior CONTEXT.md files)
2. Scout codebase for reusable assets and patterns
3. Analyze phase — skip gray areas already decided in prior phases
4. Present remaining gray areas — user selects which to discuss
5. Deep-dive each selected area until satisfied
6. 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> @/Users/teo/src/tempo/.codex/get-shit-done/workflows/discuss-phase.md @/Users/teo/src/tempo/.codex/get-shit-done/templates/context.md </execution_context>

Phase number: {{GSD_ARGS}} (required)

Context files are resolved in-workflow using init phase-op and roadmap/state tool calls.

1. Validate phase number (error if missing or not in roadmap) 2. Check if CONTEXT.md exists (offer update/view/skip if yes) 3. **Load prior context** — Read PROJECT.md, REQUIREMENTS.md, STATE.md, and all prior CONTEXT.md files 4. **Scout codebase** — Find reusable assets, patterns, and integration points 5. **Analyze phase** — Check prior decisions, skip already-decided areas, generate remaining gray areas 6. **Present gray areas** — Multi-select: which to discuss? Annotate with prior decisions + code context 7. **Deep-dive each area** — 4 questions per area, code-informed options, Context7 for library choices 8. **Write CONTEXT.md** — Sections match areas discussed + code_context section 9. 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

<success_criteria>

• Prior context loaded and applied (no re-asking decided questions)
• 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>