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.

1. Tasks marked pending with all dependencies done are the next to execute.
2. Tasks marked failed or circuit_break need recovery — follow the circuit breaker flow.
3. 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 in TASKS.md but whose summary file is missing. On resume, before skipping a done task, verify its summary file exists:

• If .plan/<feature-slug>/task-<id>_SUMMARY.md exists → skip, it's truly done
• If the summary is missing → re-dispatch the task (the status was written prematurely)

Execution Loop

Step 1: Read the Plan

Read .plan/<feature-slug>/TASKS.md. Parse task ID, title, skill, phase, dependencies, status.

Step 2: Find Next Executable Task

A task is executable when status is pending and all dependencies are done.

Run independent tasks in parallel when they touch different files and are the same phase type.

Step 2b: Pre-Green Guardrail (green tasks only)

Before dispatching any green task, run a fast consistency check using a Haiku subagent. Read the Pre-Green Guardrail Prompt in prompts.md for the dispatch template.

• If PASS → proceed to dispatch
• If MISMATCH → flag as potential SPEC_DISPUTE before spending tokens on go-dev. Write the mismatch to the task summary and dispatch go-pm for early arbitration.

This guardrail catches spec inconsistencies BEFORE burning tokens on implementation. It costs ~1% of a go-dev invocation.

Step 3: Dispatch Subagent

For each executable task:

1. Read .plan/<feature-slug>/task-<id>.md for the task details
2. Read each dependency's .plan/<feature-slug>/task-<dep>_SUMMARY.md for context

Read the Subagent Dispatch Prompt in prompts.md for the dispatch template.

Use `subagent_type` to dispatch. The agent framework loads the skill automatically — no need to read and inline SKILL.md files.

Skill mapping from task files:

• go-scaffolder → subagent_type: go-scaffolder
• go-test-writer → subagent_type: go-test-writer
• go-dev → subagent_type: go-dev
• go-migrator → subagent_type: go-migrator
• go-reviewer → subagent_type: go-reviewer
• go-fixer → subagent_type: go-fixer (circuit breaker recovery)
• go-debugger → subagent_type: go-debugger (escalation from fixer)
• go-pm → subagent_type: go-pm (spec dispute arbitration)
• go-finish → subagent_type: go-finish (after all tasks complete)

Step 4: Write Summary

Write the subagent's summary to .plan/<feature-slug>/task-<id>_SUMMARY.md.

Step 5: Validate

Green tasks: Run go test ./... -count=1 -v -run <TestPattern> and go build ./.... If tests still fail, mark as blocked.

Scaffold tasks: go build ./... passes, go test ./... -count=1 shows SKIP/PASS.

Red tasks: go build ./... passes, specific tests DO fail.

Advisor/review tasks: Re-read .plan/<feature-slug>/TASKS.md to pick up new tasks.

Step 6: Update Status

Set task to done in .plan/<feature-slug>/TASKS.md. Loop back to Step 2.

Step 7: Completion

When all tasks are done, dispatch go-finish with:

• The feature slug
• A one-line summary of tasks completed

Do NOT run final verification or present integration options yourself. go-finish handles verification, acceptance criteria, cleanup, and integration choice.

Verification Protocol (runner double-check)

Each subagent is responsible for running go-verify checks and reporting evidence. The runner acts as a safety net — it re-runs verification independently to catch cases where a subagent claims success without proper evidence.

After each GREEN task, the runner MUST:

1. Run go build ./... — report exit code
2. Run go test ./... -count=1 -race — report full output
3. Only mark task complete if BOTH pass with evidence

Do NOT mark a task as done based on:

• The subagent's verbal claim ("tests pass")
• A previous test run (stale)
• Partial test execution (only the specific package)

The full suite with -race and -count=1 is the minimum. Report actual output in the task summary.

Post-Green Quick Eval (after each green task)

After verification passes, run a fast Haiku eval to catch obvious issues early. Read the Post-Green Eval Prompt in prompts.md for the dispatch template.

• If CLEAN → mark task as done, proceed
• If ISSUE → log the issue in the task summary. Create a note for go-reviewer to prioritize this area. Do NOT block — the full review will address it, but the early signal helps.

This eval costs ~2% of a go-dev invocation and catches the most common security/architecture bugs immediately rather than waiting for the full review pass.

After ALL tasks complete, invoke go-finish to handle feature closure. Do NOT present integration options yourself — go-finish handles verification, acceptance criteria, cleanup, and integration choice.

Spec Dispute Handling

When go-dev returns SPEC_DISPUTE::

1. Write to .plan/<feature-slug>/task-<id>_SUMMARY.md with status spec_dispute
2. Pause all dependent tasks — do not proceed past a disputed task's dependents
3. Dispatch go-pm with subagent_type: go-pm. Read the Spec Dispute Escalation Prompt in prompts.md for the dispatch template.
4. After go-pm + go-architect produce corrective tasks, re-read .plan/<feature-slug>/TASKS.md to pick up the new/modified tasks
5. Resume execution from the corrective tasks

Do NOT dispatch go-fixer for spec disputes. go-fixer is for implementation bugs, not spec disagreements. Spec disputes require a product decision.

Circuit Breaker Handling

When a subagent returns CIRCUIT_BREAK::

1. Write to .plan/<feature-slug>/task-<id>_SUMMARY.md with status circuit_break
2. Dispatch go-fixer with the error context, original task, and feature context
3. The fixer can modify both tests and implementation
4. If fixer also fails → escalate to go-debugger (see below)

Debugging Escalation

If a subagent reports CIRCUIT_BREAK and go-fixer also fails (returns NEEDS_INVESTIGATION:):

1. Do NOT retry with another go-fixer
2. Dispatch go-debugger with the full error context:

• Original task description
• All error messages from both the original agent and go-fixer
• List of files involved
• What was already tried (from go-fixer summary)

1. go-debugger will perform systematic root cause investigation
2. If go-debugger escalates to user, stop the pipeline and relay the debug report

Status Reporting

One line per task:

[task-3/12] DONE (green) — Implemented XxxRepository, all tests passing
[task-4/12] BLOCKED (green) — Tests still failing after fix attempt
[task-5/12] SPEC_DISPUTE (green) — Escalating to go-pm

Parallel Execution & Isolation

When dispatching multiple tasks in parallel (e.g., red tasks after scaffold), check whether they touch overlapping files. If tasks modify the same files, run them sequentially. If they are independent:

• Red tasks writing to different `_test.go` files: safe to parallelize directly.
• Green tasks modifying shared files (init.go, config.go): run sequentially to avoid write conflicts.
• Tasks that might conflict: use isolation: "worktree" when dispatching the Agent to give each task an isolated copy of the repo. The worktree is cleaned up automatically if no changes are made.

The go-architect's task files include a "Files to Create/Modify" section — use this to determine overlap before deciding parallel vs sequential.

Guidelines

• Read each file at most once.
• Never read SKILL.md files. The subagent framework handles skill loading.
• Validate every green task by running tests. You are the safety net.
• Do not proceed past a blocked task's dependents.
• Do not modify code yourself. Dispatch and validate only.
• Write summary files for every completed task.
• Re-read TASKS.md after review tasks (they may add new tasks).