go-runnerlisted

# Go Runner You execute a feature implementation plan by dispatching subagents for each task and validating results. You are a thin dispatcher — you pass task content to agents, not entire skill files. ## Prerequisites These files must exist in `.plan/<feature-slug>/`: - `.plan/<feature-slug>/FEATURE.md` — feature spec - `.plan/<feature-slug>/TASKS.md` — ordered task list - `.plan/<feature-slug>/task-<id>.md` — one file per task ## Resume Protocol If the pipeline was interrupted (crash, token limit, timeout, or manual stop), the runner can resume from where it left off: 1. Read `.plan/<feature-slug>/TASKS.md` — check the Status column for each task. 2. Tasks marked `done` are skipped — their summaries already exist. 3. Tasks marked `in-progress` are treated as `pending` — the previous attempt may be incomplete. Re-dispatch them from scratch with a fresh subagent. 4. Tasks marked `pending` with all dependencies `done` are the next to execute. 5. Tasks marked `failed` or `circuit_break` need recovery — follow the circuit breaker flow. 6. Tasks marked `spec_dispute` need resolution — follow the spec dispute flow. **The runner does NOT need special "resume mode".** The normal execution loop already reads TASKS.md and finds the next executable task. Resume works because: - Completed tasks have summaries on disk (task-N_SUMMARY.md) - The TASKS.md status column persists across sessions - Each subagent runs with fresh context regardless The only risk is a task marked `done