- plan-phase.md: dependency-first planning, vertical slices default - phase-prompt.md: autonomous field, wave structure, frontmatter table - scope-estimation.md: parallel default, removed "parallel-aware" framing - plan-format.md: frontmatter docs with depends_on, files_modified, autonomous - execute-phase.md: checkpoint-resume flow using Task resume parameter Plans now declare explicit dependencies via frontmatter. Wave assignment is automatic based on depends_on + files_modified. Checkpoints pause subagent, return to orchestrator, user responds, orchestrator resumes. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
9.5 KiB
<core_principle> The orchestrator's job is coordination, not execution. Each subagent loads the full execute-plan context itself. Orchestrator discovers plans, analyzes dependencies, groups into waves, spawns agents, handles checkpoints, collects results. </core_principle>
Confirm phase exists and has plans:PHASE_DIR=$(ls -d .planning/phases/${PHASE_ARG}* 2>/dev/null | head -1)
if [ -z "$PHASE_DIR" ]; then
echo "ERROR: No phase directory matching '${PHASE_ARG}'"
exit 1
fi
PLAN_COUNT=$(ls -1 "$PHASE_DIR"/*-PLAN.md 2>/dev/null | wc -l | tr -d ' ')
if [ "$PLAN_COUNT" -eq 0 ]; then
echo "ERROR: No plans found in $PHASE_DIR"
exit 1
fi
Report: "Found {N} plans in {phase_dir}"
List all plans and extract metadata:# Get all plans
ls -1 "$PHASE_DIR"/*-PLAN.md 2>/dev/null | sort
# Get completed plans (have SUMMARY.md)
ls -1 "$PHASE_DIR"/*-SUMMARY.md 2>/dev/null | sort
For each plan, read frontmatter to extract:
depends_on: []- Plan IDs this plan requiresfiles_modified: []- Files this plan touchesautonomous: true/false- Whether plan has checkpoints
Build plan inventory:
- Plan path
- Plan ID (e.g., "03-01")
- Dependencies
- Files modified
- Autonomous flag
- Completion status (SUMMARY exists = complete)
Skip completed plans. If all complete, report "Phase already executed" and exit.
Build dependency graph from frontmatter:Direct dependencies:
depends_on: ["03-01"]→ this plan depends on 03-01
File conflict dependencies:
- If two plans modify same file, later plan (by number) depends on earlier
Build graph:
plan-01: {deps: [], files: [src/user.ts], autonomous: true}
plan-02: {deps: [], files: [src/product.ts], autonomous: true}
plan-03: {deps: ["plan-01"], files: [src/dashboard.tsx], autonomous: false}
plan-04: {deps: ["plan-02"], files: [src/cart.ts], autonomous: true}
plan-05: {deps: ["plan-03", "plan-04"], files: [src/checkout.ts], autonomous: true}
Wave assignment algorithm:
- Wave 1: All plans with no dependencies AND autonomous=true
- Non-autonomous plans with no dependencies: execute after Wave 1, before Wave 2
- Wave N: Plans whose dependencies are all in earlier waves
Separate checkpoint plans:
Plans with autonomous: false execute in main context (not parallel subagent) to handle user interaction.
Example:
Wave 1 (parallel): [plan-01, plan-02]
Checkpoint: [plan-03] - has human-verify, runs in main context
Wave 2 (parallel): [plan-04]
Wave 3: [plan-05]
Report wave structure to user:
Execution Plan:
Wave 1 (parallel): 03-01, 03-02
Checkpoint: 03-03 (requires user verification)
Wave 2 (parallel): 03-04
Wave 3: 03-05
Total: 5 plans in 3 waves + 1 checkpoint
For each wave:
-
Spawn all autonomous agents in wave simultaneously:
Use Task tool with multiple parallel calls. Each agent gets prompt from subagent-task-prompt template:
<objective> Execute plan {plan_number} of phase {phase_number}-{phase_name}. Commit each task atomically. Create SUMMARY.md. Update STATE.md. </objective> <execution_context> @~/.claude/get-shit-done/workflows/execute-plan.md @~/.claude/get-shit-done/templates/summary.md @~/.claude/get-shit-done/references/checkpoints.md @~/.claude/get-shit-done/references/tdd.md </execution_context> <context> Plan: @{plan_path} Project state: @.planning/STATE.md Config: @.planning/config.json (if exists) </context> <success_criteria> - [ ] All tasks executed - [ ] Each task committed individually - [ ] SUMMARY.md created in plan directory - [ ] STATE.md updated with position and decisions </success_criteria> -
Wait for all agents in wave to complete:
Task tool blocks until each agent finishes. All parallel agents return together.
-
Collect results from wave:
For each completed agent:
- Verify SUMMARY.md exists at expected path
- Note any issues reported
- Record completion
-
Handle failures:
If any agent in wave fails:
- Report which plan failed and why
- Ask user: "Continue with remaining waves?" or "Stop execution?"
- If continue: proceed to next wave (dependent plans may also fail)
- If stop: exit with partial completion report
-
Execute checkpoint plans between waves:
See
<checkpoint_handling>for details. -
Proceed to next wave
Detection: Check autonomous field in frontmatter.
Execution flow for checkpoint plans:
-
Spawn agent for checkpoint plan:
Task(prompt="{subagent-task-prompt}", subagent_type="general-purpose") -
Agent runs until checkpoint:
- Executes auto tasks normally
- Reaches checkpoint task (e.g.,
type="checkpoint:human-verify") - Agent returns with checkpoint details in its response
-
Agent return includes:
- Checkpoint type (human-verify, decision, human-action)
- Checkpoint details (what-built, options, instructions)
- Agent ID for resumption
- Progress so far (tasks completed)
-
Orchestrator presents checkpoint to user:
## Checkpoint: Visual Verification Required **Plan:** 03-03 Dashboard Layout **Progress:** 2/3 tasks complete **What was built:** Responsive dashboard with sidebar navigation **Please verify:** 1. Run: npm run dev 2. Visit: http://localhost:3000/dashboard 3. Desktop (>1024px): Verify sidebar left, content right 4. Mobile (375px): Verify single column layout Type "approved" to continue, or describe issues to fix. -
User responds:
- "approved" → resume agent
- Description of issues → resume agent with feedback
-
Resume agent:
Task(resume="{agent_id}", prompt="User response: {user_input}") -
Agent continues from checkpoint:
- If approved: proceed to next task
- If issues: fix and re-present checkpoint, or ask for clarification
-
Repeat until plan completes or user stops
Checkpoint in parallel context: If a plan in a parallel wave has a checkpoint:
- Spawn as normal
- Agent pauses at checkpoint and returns
- Other parallel agents may complete while waiting
- Handle checkpoint, resume agent
- Wait for all agents to finish before next wave
## Phase {X}: {Name} Execution Complete
**Waves executed:** {N}
**Plans completed:** {M} of {total}
### Wave Summary
| Wave | Plans | Status |
|------|-------|--------|
| 1 | plan-01, plan-02 | ✓ Complete |
| CP | plan-03 | ✓ Verified |
| 2 | plan-04 | ✓ Complete |
| 3 | plan-05 | ✓ Complete |
### Plan Details
1. **03-01**: [one-liner from SUMMARY.md]
2. **03-02**: [one-liner from SUMMARY.md]
...
### Issues Encountered
[Aggregate from all SUMMARYs, or "None"]
# Mark phase complete
# Update completion date
# Update status
Commit roadmap update:
git add .planning/ROADMAP.md
git commit -m "docs(phase-{X}): complete phase execution"
If more phases remain:
## Next Up
**Phase {X+1}: {Name}** — {Goal}
`/gsd:plan-phase {X+1}`
<sub>`/clear` first for fresh context</sub>
If milestone complete:
MILESTONE COMPLETE!
All {N} phases executed.
`/gsd:complete-milestone`
<context_efficiency> Why this works:
Orchestrator context usage: ~10-15%
- Read plan frontmatter (small)
- Analyze dependencies (logic, no heavy reads)
- Fill template strings
- Spawn Task calls
- Collect results
Each subagent: Fresh 200k context
- Loads full execute-plan workflow
- Loads templates, references
- Executes plan with full capacity
- Creates SUMMARY, commits
No polling. Task tool blocks until completion. No TaskOutput loops.
No context bleed. Orchestrator never reads workflow internals. Just paths and results. </context_efficiency>
<failure_handling> Subagent fails mid-plan:
- SUMMARY.md won't exist
- Orchestrator detects missing SUMMARY
- Reports failure, asks user how to proceed
Dependency chain breaks:
- Wave 1 plan fails
- Wave 2 plans depending on it will likely fail
- Orchestrator can still attempt them (user choice)
- Or skip dependent plans entirely
All agents in wave fail:
- Something systemic (git issues, permissions, etc.)
- Stop execution
- Report for manual investigation
Checkpoint fails to resolve:
- User can't approve or provides repeated issues
- Ask: "Skip this plan?" or "Abort phase execution?"
- Record partial progress in STATE.md </failure_handling>
If phase execution was interrupted (context limit, user exit, error):
- Run
/gsd:execute-phase {phase}again - discover_plans finds completed SUMMARYs
- Skips completed plans
- Resumes from first incomplete plan
- Continues wave-based execution
STATE.md tracks:
- Last completed plan
- Current wave
- Any pending checkpoints