name	gsd-discuss-phase
description	Gather phase context through adaptive questioning before planning.
metadata	{"short-description":"Gather phase context through adaptive questioning before planning."}

<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 or unavailable, activate TEXT_MODE: append --text to {{GSD_ARGS}} so the workflow's built-in text-mode branching takes over. Present every AskUserQuestion call as a plain-text numbered list, then stop and wait for the user's reply. Do NOT pick a default and continue (#3018 / #3808).
You may only proceed without a user answer when one of these is true: (a) the invocation included an explicit non-interactive flag (--auto or --all), (b) the user has explicitly approved a specific default for this question, or (c) the workflow's documented contract says defaults are safe (e.g. autonomous lifecycle paths).
Do NOT write workflow artifacts (CONTEXT.md, DISCUSSION-LOG.md, PLAN.md, checkpoint files) until the user has answered the plain-text questions or one of (a)-(c) above applies. Surfacing the questions and waiting is the correct response — silently defaulting and writing artifacts is the #3018 failure mode.

C. Task() → spawn_agent Mapping

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

Schema detection (required first step): Codex exposes two spawn_agent schemas:

agent_type-capable schema (e.g. multi_agent_v2): spawn_agent accepts agent_type, message, reasoning_effort, fork_context, etc. — typed GSD agent dispatch is available.
Generic schema (multi_agent_v1): spawn_agent accepts only message, items, fork_context — there is no agent_type field. Typed GSD agent dispatch is unavailable in this session.

Before spawning, inspect the spawn_agent tool's visible parameter schema (via tool_search or the tool list) to determine which form is active.

Typed mapping (agent_type-capable schema only):

Task(subagent_type="X", prompt="Y") → spawn_agent(agent_type="X", message="Y")
Agent(subagent_type="X", prompt="Y") → spawn_agent(agent_type="X", message="Y")
Task(model="...") → omit. spawn_agent has no inline model parameter; GSD embeds the resolved per-agent model directly into each agent's .toml at install time so model_overrides from .planning/config.json and ~/.gsd/defaults.json are honored automatically by Codex's agent router.
Resolved reasoning_effort="low|medium|high|xhigh" (xhigh is a GSD/Codex tier, not a generic runtime enum) → pass reasoning_effort to spawn_agent when the runtime/tool supports it. Omit missing, empty, inherited, or unsupported values; do not invent one-off effort literals in workflow prose.
fork_context: false by default — GSD agents load their own context via <files_to_read> blocks
Task(isolation="worktree") / Agent(isolation="worktree") → no direct Codex mapping. Codex spawn_agent does not create or bind a git worktree automatically. Workflows that require this isolation must fail closed or use an explicit manual worktree protocol before spawning (#3360).

Generic-agent workaround (multi_agent_v1 schema — NO agent_type field): When only the generic multi_agent_v1 schema is available, typed GSD agent dispatch (gsd-planner, gsd-executor, etc.) is NOT possible. This is a known Codex limitation (openai/codex#15250). This workaround is NOT equivalent to typed gsd-planner/gsd-executor execution — GSD agents carry project-aware prompts, audit logging, and workflow context that a generic subagent lacks. Use the following fallback:

Resolve your active Codex config root — the directory that contains your config.toml. This directory is determined in priority order: $CODEX_HOME (if set), the path given by --config-dir (if passed on invocation), a local .codex directory in the current project (if --local was used), or the default global config directory. Read agents/<agent-name>.toml relative to that config root to extract the agent's system instructions.
Inject those instructions as a role-preamble into a generic spawn_agent(message=...) call.
Label results and logs clearly as "generic-agent workaround" so the orchestrator and user know full typed-agent guarantees are not in effect.
Where typed dispatch is mandatory for correctness (e.g. worktree isolation), fail closed and report the schema limitation rather than silently degrading.

Spawn restriction:

Codex restricts spawn_agent to cases where the user has explicitly requested sub-agents. When automatic spawning is not permitted, do the work inline in the current agent rather than attempting to force a spawn.
In some Codex sessions, multi-agent tooling can be deferred. If spawn_agent is not currently visible, discover tools first via tool_search before defaulting to inline execution.

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:

Load prior context (PROJECT.md, REQUIREMENTS.md, STATE.md, prior CONTEXT.md files)
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> Workflow files are loaded on-demand in the section below — not upfront. Do not pre-load any workflow files before reading the mode routing instructions. </execution_context>

<runtime_note> Copilot (VS Code): Use vscode_askquestions wherever this workflow calls AskUserQuestion. They are equivalent — vscode_askquestions is the VS Code Copilot implementation of the same interactive question API. </runtime_note>

Phase number: {{GSD_ARGS}} (required)

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

**Mode routing:** ```bash _GSD_SHIM_NAME="gsd-tools.cjs"; _GSD_RUNTIME_ROOT="${RUNTIME_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}"; GSD_TOOLS="${_GSD_RUNTIME_ROOT}/gsd-core/bin/${_GSD_SHIM_NAME}"; if [ -f "$GSD_TOOLS" ]; then gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${_GSD_RUNTIME_ROOT}/.claude/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${_GSD_RUNTIME_ROOT}/.claude/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif command -v gsd-tools >/dev/null 2>&1; then GSD_TOOLS="$(command -v gsd-tools)"; gsd_run() { "$GSD_TOOLS" "$@"; }; elif [ -f "$HOME/.codex/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="$HOME/.codex/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; else echo "ERROR: gsd-tools.cjs not found at $GSD_TOOLS and gsd-tools is not on PATH. Run: npx -y @opengsd/gsd-core@latest --claude --local" >&2; exit 1; fi DISCUSS_MODE=$(gsd_run query config-get workflow.discuss_mode 2>/dev/null || echo "discuss") ```

If --assumptions is in {{GSD_ARGS}}: Read and execute /home/user/projects/temp/ai-apps/.personal-projects/registry-atlas/.codex/gsd-core/workflows/list-phase-assumptions.md end-to-end. Stop here.

Otherwise, if DISCUSS_MODE is "assumptions": Read and execute /home/user/projects/temp/ai-apps/.personal-projects/registry-atlas/.codex/gsd-core/workflows/discuss-phase-assumptions.md end-to-end.

Otherwise ("discuss" / unset / any other value): Read and execute /home/user/projects/temp/ai-apps/.personal-projects/registry-atlas/.codex/gsd-core/workflows/discuss-phase.md end-to-end.

MANDATORY: Read the appropriate 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.

Lazy loading: templates/context.md is loaded inside the write_context step of the active workflow. discuss-phase-power.md is loaded inside discuss-phase.md when --power is detected. Do not load either here.

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