The Orchestrator Pattern
GSD’s architecture follows a consistent pattern: thin orchestrators spawn specialized agents. The orchestrator never does heavy lifting. It:- Spawns agents with fresh 200K context windows
- Waits for results
- Integrates outputs
- Routes to next step
Key insight: Your main session stays lean because it’s just coordination. The actual work happens in fresh subagent contexts.
Agent Roles
GSD includes 12 specialized agents:Planning Agents
gsd-roadmapper
gsd-roadmapper
Role: Creates milestone roadmaps from requirementsSpawned by:
/gsd:new-project, /gsd:new-milestoneInput: PROJECT.md, REQUIREMENTS.md, research findingsOutput: ROADMAP.md with phases, must-haves, traceabilityModel (balanced profile): Sonnetgsd-phase-researcher
gsd-phase-researcher
Role: Investigates how to implement a phaseSpawned by:
/gsd:plan-phase (4 parallel instances)Input: Phase description, CONTEXT.md, existing codebaseOutput: RESEARCH.md (stack, features, architecture, pitfalls)Model (balanced profile): Sonnetgsd-planner
gsd-planner
Role: Creates executable phase plans with task breakdownSpawned by:
/gsd:plan-phaseInput: PROJECT.md, REQUIREMENTS.md, CONTEXT.md, RESEARCH.mdOutput: PLAN.md files with XML structureModel (balanced profile): Opus (where architectural decisions happen)gsd-plan-checker
gsd-plan-checker
Role: Verifies plans achieve phase goals before executionSpawned by:
/gsd:plan-phase (iterative loop)Input: PLAN.md files, REQUIREMENTS.md, must_havesOutput: Validation results, revision suggestionsModel (balanced profile): SonnetExecution Agents
gsd-executor
gsd-executor
Role: Executes PLAN.md files atomically with per-task commitsSpawned by:
/gsd:execute-phase (multiple in parallel)Input: PLAN.md, PROJECT.md, STATE.md, @-referenced filesOutput: Code changes, atomic commits, SUMMARY.mdModel (balanced profile): SonnetSpecial behaviors:- Auto-fixes bugs (Rule 1)
- Auto-adds missing critical functionality (Rule 2)
- Auto-fixes blocking issues (Rule 3)
- Asks about architectural changes (Rule 4)
- Handles authentication gates
- Pauses at checkpoints
gsd-verifier
gsd-verifier
Role: Confirms must-haves were delivered after executionSpawned by:
/gsd:execute-phase (after all plans complete)Input: REQUIREMENTS.md, PLAN frontmatter (must_haves), codebaseOutput: VERIFICATION.md with pass/fail per must-haveModel (balanced profile): Sonnetgsd-debugger
gsd-debugger
Role: Systematic debugging with persistent stateSpawned by:
/gsd:debug, /gsd:verify-work (when issues found)Input: Issue description, relevant code, logsOutput: Root cause analysis, fix plansModel (balanced profile): SonnetAnalysis Agents
gsd-codebase-mapper
gsd-codebase-mapper
Role: Analyzes existing codebase before new-projectSpawned by:
/gsd:map-codebase (4 parallel instances)Input: Existing codebaseOutput: STACK.md, ARCHITECTURE.md, CONVENTIONS.md, CONCERNS.mdModel (balanced profile): Haiku (read-only analysis)gsd-project-researcher
gsd-project-researcher
Role: Investigates domain during new-projectSpawned by:
/gsd:new-project --researchInput: Project idea, tech stack preferencesOutput: Research findings for requirements extractionModel (balanced profile): Haikugsd-research-synthesizer
gsd-research-synthesizer
Role: Combines parallel research findingsSpawned by: Various orchestrators after parallel researchInput: Multiple research outputsOutput: Synthesized RESEARCH.mdModel (balanced profile): Sonnet
gsd-integration-checker
gsd-integration-checker
Role: Validates integration between completed phasesSpawned by:
/gsd:audit-milestoneInput: All phase SUMMARYs, codebaseOutput: Integration issues, gap analysisModel (balanced profile): Sonnetgsd-nyquist-auditor
gsd-nyquist-auditor
Role: Retroactively audits and fills test coverage gapsSpawned by:
/gsd:validate-phaseInput: Implementation code, existing tests, requirementsOutput: Test files, updated VALIDATION.mdModel (balanced profile): SonnetCoordination Mechanisms
1. Context Isolation
Each agent gets its own context assembly:2. File-Based Communication
Agents communicate through structured markdown files:Benefit: No context leakage. Each agent has exactly what it needs, nothing more.
3. Wave-Based Parallelization
Executors run in waves based on dependencies:Real Execution Flow
Here’s what happens when you run/gsd:plan-phase 1:
Context Budget Tracking
| Stage | Agents Spawned | Orchestrator Context | Total Agent Context |
|---|---|---|---|
| new-project | 4 researchers, 1 synthesizer, 1 roadmapper | 10% | 6 × 200K |
| plan-phase | 4 researchers, 1 synthesizer, 1 planner, 1-3 checkers | 15% | 7-9 × 200K |
| execute-phase (3 plans, 2 waves) | 3 executors, 1 verifier | 20% | 4 × 200K |
| verify-work | 1-5 debuggers | 10% | 1-5 × 200K |
Failure Handling
What happens when an agent fails?Planner fails to create valid plans
Planner fails to create valid plans
- Checker catches issues
- Orchestrator spawns planner in revision mode
- Planner gets: original PLAN.md + checker feedback
- Makes surgical fixes, not full rewrite
- Loop up to 3x
Executor hits blocker mid-plan
Executor hits blocker mid-plan
- Executor documents blocker in STATE.md
- Creates checkpoint with exact state
- Returns to orchestrator
- User resolves blocker
- Orchestrator spawns continuation agent
- Continuation agent resumes from checkpoint
Verifier finds gaps
Verifier finds gaps
- Writes VERIFICATION.md with gaps
- Orchestrator offers:
/gsd:plan-phase 1 --gaps - Planner in gap closure mode
- Creates targeted fix plans
- Execute-phase runs gap plans only
Agent classification bug
Agent classification bug
GSD includes a workaround for Claude Code’s classification bug:
- Orchestrator spot-checks actual output
- If commits exist but agent reported failure → treat as success
- Log warning but proceed
Model Profiles
Different agents use different models based on their role:Balanced Profile (Default)
| Agent | Model | Why |
|---|---|---|
| gsd-planner | Opus | Architectural decisions happen here |
| gsd-executor | Sonnet | Most code writing, good quality/cost |
| gsd-verifier | Sonnet | Read-only verification |
| gsd-phase-researcher | Sonnet | Investigation work |
| gsd-plan-checker | Sonnet | Validation logic |
| gsd-codebase-mapper | Haiku | Read-only analysis |
Quality Profile
- Opus for all decision-making agents
- Sonnet for read-only verification
- Use when quota available, work is critical
Budget Profile
- Sonnet for anything that writes code
- Haiku for research and verification
- Use for high-volume work, less critical phases
Switch profiles:
/gsd:set-profile budget or /gsd:settingsBest Practices
Let parallelization happen
GSD automatically runs independent plans in parallel. Prefer “vertical slices” (Plan 01: User feature end-to-end) over “horizontal layers” (Plan 01: All models).
Trust the orchestrator
Don’t manually spawn agents or chain commands. Use
/gsd:plan-phase then /gsd:execute-phase — orchestration is automatic.Use /clear liberally
Between major commands (
/gsd:plan-phase, /gsd:execute-phase), run /clear. Orchestrator will spawn fresh agents anyway.Monitor with /gsd:progress
See where you are, what’s running, what’s complete. The orchestrator tracks everything.
Next Steps
XML Prompting
See how GSD structures prompts for Claude
Workflow Stages
Understand the 5-stage development cycle