gsd-orchestrator

<mental_model> GSD headless is a subprocess you launch and monitor. Think of it like a junior developer you hand a spec to:

You write the spec (what to build)
You launch the build (gsd headless ... new-milestone --context spec.md --auto)
You wait for it to finish (exit code tells you the outcome)
You check the result (query state, inspect files, verify deliverables)
If blocked, you intervene (steer, supply answers, or escalate)

The subprocess handles all planning, coding, testing, and git commits internally. You never write application code yourself — GSD does that. </mental_model>

<critical_rules>

Flags before command. gsd headless [--flags] [command] [args]. Flags after the command are ignored.
Redirect stderr. JSON output goes to stdout. Progress goes to stderr. Always 2>/dev/null when parsing JSON.
Check exit codes. 0=success, 1=error, 10=blocked (needs you), 11=cancelled.
Use query to poll. Instant (~50ms), no LLM cost. Use it between steps, not auto for status.
Budget awareness. Track cost.total from query results. Set limits before launching long runs.
One project directory per build. Each GSD project needs its own directory with a .gsd/ folder. </critical_rules>

Build something from scratch: Read workflows/build-from-spec.md — write spec, init directory, launch, monitor, verify.

Check on a running or completed build: Read workflows/monitor-and-poll.md — query state, interpret phases, handle blockers.

Execute with fine-grained control: Read workflows/step-by-step.md — run one unit at a time with decision points.

Understand the JSON output: Read references/json-result.md — field reference for HeadlessJsonResult.

Pre-supply answers or secrets: Read references/answer-injection.md — answer file schema and injection mechanism.

Look up a specific command: Read references/commands.md — full command reference with flags and examples.

<quick_reference>

Launch a full build (spec to working code):

mkdir -p /tmp/my-project && cd /tmp/my-project && git init
cat > spec.md << 'EOF'
# Your Product Spec Here
Build a ...
EOF
gsd headless --output-format json --context spec.md new-milestone --auto 2>/dev/null

Check project state (instant, free):

cd /path/to/project
gsd headless query | jq '{phase: .state.phase, progress: .state.progress, cost: .cost.total}'

Resume work on an existing project:

cd /path/to/project
gsd headless --output-format json auto 2>/dev/null

Run one step at a time:

RESULT=$(gsd headless --output-format json next 2>/dev/null)
echo "$RESULT" | jq '{status: .status, phase: .phase, cost: .cost.total}'

</quick_reference>

<exit_codes>

Code	Meaning	Your action
`0`	Success	Check deliverables, verify output, report completion
`1`	Error or timeout	Inspect stderr, check `gsd headless query`, retry or escalate
`10`	Blocked	Query state for blocker details, steer around it or escalate to human
`11`	Cancelled	Process was interrupted — resume with `--resume <sessionId>` or restart
</exit_codes>

<project_structure> GSD keeps all state in its database (.gsd/gsd.db) and renders these files from it in .gsd/:

.gsd/
  PROJECT.md          # What this project is
  REQUIREMENTS.md     # Capability contract
  DECISIONS.md        # Architectural decisions
  KNOWLEDGE.md        # Persistent project knowledge (rules, patterns and lessons rendered from the database)
  STATE.md            # Current phase and next action
  milestones/
    M001-xxxxx/
      M001-xxxxx-CONTEXT.md    # Scope, constraints, assumptions
      M001-xxxxx-ROADMAP.md    # Slices with checkboxes
      M001-xxxxx-SUMMARY.md    # Completion summary
      slices/S01/
        S01-PLAN.md            # Tasks
        S01-SUMMARY.md         # Slice summary
        tasks/
          T01-PLAN.md          # Individual task spec
          T01-SUMMARY.md       # Task completion summary

The database is the source of truth. These files are renders: read them to understand progress, but never edit them — an edit does not change state and the next render discards it. For current state use gsd headless query. </project_structure>

<answer_injection> Pre-supply answers and secrets for fully autonomous runs:

gsd headless --answers answers.json --output-format json auto 2>/dev/null

{
  "questions": { "question_id": "selected_option" },
  "secrets": { "API_KEY": "sk-..." },
  "defaults": { "strategy": "first_option" }
}

questions — question ID to answer (string for single-select, string[] for multi-select)
secrets — env var to value, injected into child process environment
defaults.strategy — "first_option" (default) or "cancel" for unmatched questions

See references/answer-injection.md for the full mechanism. </answer_injection>

<event_streaming> For real-time monitoring, use JSONL event streaming:

gsd headless --json auto 2>/dev/null | while read -r line; do
  TYPE=$(echo "$line" | jq -r '.type')
  case "$TYPE" in
    tool_execution_start) echo "Tool: $(echo "$line" | jq -r '.toolName')" ;;
    extension_ui_request) echo "GSD: $(echo "$line" | jq -r '.message // .title // empty')" ;;
    agent_end) echo "Session ended" ;;
  esac
done

Filter to specific events: --events agent_end,execution_complete,extension_ui_request

Available types: agent_start, agent_end, tool_execution_start, tool_execution_end, tool_execution_update, extension_ui_request, message_start, message_end, message_update, turn_start, turn_end, cost_update, execution_complete. </event_streaming>

<all_commands>

Command	Purpose
`auto`	Run all queued units until milestone complete or blocked (default)
`next`	Run exactly one unit, then exit
`query`	Instant JSON snapshot — state, next dispatch, costs (no LLM, ~50ms)
`new-milestone`	Create milestone from spec file
`dispatch <phase>`	Force specific phase (research, plan, execute, complete, reassess, uat, replan)
`stop` / `pause`	Control auto-mode
`steer <desc>`	Hard-steer plan mid-execution
`skip` / `undo`	Unit control
`queue`	Queue/reorder milestones
`history`	View execution history
`doctor`	Health check + auto-fix
`knowledge <rule\|pattern\|lesson>`	Add persistent project knowledge
`explore` / `spike` / `sketch`	Prompt-driven ideation and experiment workflows
`map-codebase` / `docs-update` / `graphify`	Codebase documentation and knowledge workflows
`code-review` / `review` / `audit-*` / `verify-work`	Review, audit, and UAT workflows

See references/commands.md for the complete reference. </all_commands>

About this skill