| name | gsd-spec-phase |
| description | Socratic spec refinement — clarify WHAT a phase delivers with ambiguity scoring before discuss-phase. Produces a SPEC.md with falsifiable requirements locked before implementation decisions begin. |
| metadata | {"short-description":"Socratic spec refinement — clarify WHAT a phase delivers with ambiguity scoring before discuss-phase. Produces a SPEC.md with falsifiable requirements locked before implementati..."} |
<codex_skill_adapter>
A. Skill Invocation
- This skill is invoked by mentioning
$gsd-spec-phase.
- Treat all user text after
$gsd-spec-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>
Clarify phase requirements through structured Socratic questioning with quantitative ambiguity scoring.
Position in workflow: spec-phase → discuss-phase → plan-phase → execute-phase → verify
How it works:
- Load phase context (PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md)
- Scout the codebase — understand current state before asking questions
- Run Socratic interview loop (up to 6 rounds, rotating perspectives)
- Score ambiguity across 4 weighted dimensions after each round
- Gate: ambiguity ≤ 0.20 AND all dimensions meet minimums → write SPEC.md
- Commit SPEC.md — discuss-phase picks it up automatically on next run
Output: {phase_dir}/{padded_phase}-SPEC.md — falsifiable requirements that lock "what/why" before discuss-phase handles "how"
<execution_context>
@/home/delorenj/code/bhappy/.codex/get-shit-done/workflows/spec-phase.md
@/home/delorenj/code/bhappy/.codex/get-shit-done/templates/spec.md
</execution_context>
<runtime_note>
Copilot (VS Code): Use vscode_askquestions wherever this workflow calls AskUserQuestion. They are equivalent.
</runtime_note>
Phase number: {{GSD_ARGS}} (required)
Flags:
--auto — Skip interactive questions; the agent selects recommended defaults and writes SPEC.md
--text — Use plain-text numbered lists instead of TUI menus (required for /rc remote sessions)
Context files are resolved in-workflow using init phase-op.
Execute the spec-phase workflow from @/home/delorenj/code/bhappy/.codex/get-shit-done/workflows/spec-phase.md end-to-end.
MANDATORY: Read the workflow file BEFORE taking any action. The workflow contains the complete step-by-step process including the Socratic interview loop, ambiguity scoring gate, and SPEC.md generation. Do not improvise from the objective summary above.
<success_criteria>
- Codebase scouted for current state before questioning begins
- All 4 ambiguity dimensions scored after each interview round
- Gate passed: ambiguity ≤ 0.20 AND all dimension minimums met
- SPEC.md written with falsifiable requirements, explicit boundaries, and acceptance criteria
- SPEC.md committed atomically
- User knows they can now run $gsd-discuss-phase which will load SPEC.md automatically
</success_criteria>