gsd-discuss-phase by vamseeachanta/workspace-hub

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

How it works:

Load prior context (PROJECT.md, REQUIREMENTS.md, STATE.md, prior CONTEXT.md files)
Product validation via 6 forcing questions (optional, --product flag)
Scout codebase for reusable assets and patterns
Analyze phase — skip gray areas already decided in prior phases
Present remaining 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> @/mnt/local-analysis/workspace-hub/.codex/get-shit-done/workflows/discuss-phase.md @/mnt/local-analysis/workspace-hub/.codex/get-shit-done/workflows/discuss-phase-assumptions.md @/mnt/local-analysis/workspace-hub/.codex/get-shit-done/templates/context.md </execution_context>

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

If DISCUSS_MODE is "assumptions": Read and execute @/mnt/local-analysis/workspace-hub/.codex/get-shit-done/workflows/discuss-phase-assumptions.md end-to-end.

If DISCUSS_MODE is "discuss" (or unset, or any other value): Read and execute @/mnt/local-analysis/workspace-hub/.codex/get-shit-done/workflows/discuss-phase.md end-to-end.

MANDATORY: The execution_context files listed above ARE the instructions. Read the workflow file BEFORE taking any action. The objective and success_criteria sections in this command file are summaries — the workflow file contains the complete step-by-step process with all required behaviors, config checks, and interaction patterns. Do not improvise from the summary.

<success_criteria>

Prior context loaded and applied (no re-asking decided questions)
Product validation completed if --product flag used (6 forcing questions, premises confirmed)
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>