Build

Execute an implementation plan lane by lane: mechanical lanes inline, real logic with one builder per lane, independent lanes side by side.

Announce: "Using build to execute this plan."

The Iron Law

NO TASK COMPLETE WITHOUT ITS TEST PASSING
NO BUILD COMPLETE WITHOUT THE FULL SUITE GREEN AT THE JOIN

Step 1: Load and Review Plan

1. Read the plan file at $ARGUMENTS
2. Review critically — identify concerns or questions
3. If concerns: raise them before starting
4. Read the plan's Lanes table (| Lane | Owns files | Tasks | After | Executor | Effort |). No Lanes table (a legacy plan) → treat the whole plan as one sequential lane and route it in Step 2 like any other.
5. Parse flags from $ARGUMENTS: --inline / --delegate (Step 2), --reviewed (Step 6), --checkpoint (human wait after each lane; off by default). Legacy forms: --checkpoint=N means --checkpoint; --checkpoint=0 and --no-checkpoint mean no pauses, the default.

Step 2: Route Lanes

Each lane runs one of two ways:

Start from the plan's Executor hint, then override:

• → builder when the lane holds real application logic (functions, classes, control flow) or a design question the plan left open.
• → inline when the lane is only a few exact-text edits. A builder spawn costs ~25k tokens and 30–90 s before it writes a line.
• --inline runs every lane inline; --delegate gives every lane a builder.
• If a lane's route isn't obvious, ask the user.

Overlap: lanes with no After path between them run at the same time — builder lanes in the background while the main session works the inline lanes. A lane with After starts only when every lane it names has finished (Step 5).

No overlap with stashing commit hooks: if the project's commit hooks stash unstaged changes, run lanes one at a time. Check for the pre-commit framework (.pre-commit-config.yaml) and lint-staged — .lintstagedrc*, lint-staged.config.*, a lint-staged key in package.json, or a .husky/ hook that runs it. A pathspec commit leaves every other lane's in-flight edits unstaged, and the hook would stash them out from under that lane.

Announce the routing before executing:

lanes: 4 (inline 3 · builder 1)
  plan-format   inline            tasks 1–2
  hook-cleanup  builder (medium)  tasks 6–8   ← background
  ...

Step 3: Spawn Builder Lanes

For each builder lane that is ready (its After lanes are done), spawn one builder — subagent type turbocharge:builder — with:

• effort set on the Agent call from the lane's Effort column (default medium). The per-spawn value overrides the agent definition.
• Plan file path, lane name, and its task line ranges — do NOT paste plan content; the builder reads the file directly
• Working directory
• Prefix: @CLAUDE.md (conventions) — or @AGENTS.md if the project has no CLAUDE.md. .claude/CLAUDE.md counts as a CLAUDE.md: if the project keeps it there, use @.claude/CLAUDE.md. Do NOT inject @ATLAS.md — builders read the spec and diff, not the navigation index.
• Lane rules, stated in the prompt:
  • Touch only the lane's files. Never stage, stash, reset, or check out anything else.
  • Per task: RED → GREEN on that task's own test. Do NOT run the full suite — other lanes are mid-edit, so it would see their half-written files.
  • Commit per task, scoped to the task: git add <new files> (a pathspec commit can't take untracked files), then git commit -m "<message>" -- <this task's files> — the paths the task created, changed, deleted, or renamed. Don't pass the whole lane: a lane path that doesn't exist yet makes the commit fail. Never git commit -a or git add -A.
  • If git reports index.lock, wait a moment and retry once.
  • Report per task: commit SHA and test result.

Dispatch each builder without a name parameter. A named Agent spawn joins the session's implicit team as a teammate when Agent Teams are enabled; lane builders must stay plain subagents. Note each builder's agent ID against its lane — with no name, SendMessage fix rounds (Steps 5c and 6) address it by agent ID.

With --reviewed, record the lane's BEFORE_SHA first (Step 6), before spawning its builder.

Builders run in the background (Claude Code 2.1.198+): the Agent call returns as soon as the builder starts. Do not wait here — go to Step 4.

Builder isolation (design decision): the builder agent intentionally does NOT set isolation: worktree. A worktree branches from the default branch, not the parent session's HEAD, and is auto-cleaned only when no changes are made — which would break the $BEFORE_SHA..HEAD diff model in Step 6 (the reviewer would diff the wrong base) and leave a populated worktree for ship/cleanup to manage. Lanes share one tree and stay apart by owning disjoint files and committing by pathspec.

If a builder blocks on unclear context, dispatch the researcher with @ATLAS.md @CLAUDE.md prefixed — or @ATLAS.md @AGENTS.md if the project has no CLAUDE.md. .claude/CLAUDE.md counts as a CLAUDE.md: if the project keeps it there, use @.claude/CLAUDE.md. Subagents do not inherit parent history — @ATLAS.md must ride on the dispatch prompt itself.

Step 4: Run Inline Lanes

While builder lanes run, the main session works through the inline lanes, task by task. With --reviewed, record the lane's BEFORE_SHA first (Step 6), before its first task.

1. Read the task's Decision and Test assertions from the plan. Its line ranges are plan-time hints: if an earlier task in the lane shifted the code, find it by content.
2. Write the test from the assertions and run it — it must fail for the reason the task names (RED).
3. Implement the Decision. Run the test — GREEN.
4. Commit by pathspec: git add <new files>, then git commit -m "<message>" -- <this task's files>.

Inline lanes follow the same lane rules: only the lane's files, no full suite while builder lanes are in flight.

Step 5: Join

After every lane finishes — an inline lane's last commit, or a builder lane's completion notification:

1. Report one line: lane <name> ✓ · tasks a–b · commits N.
2. With --checkpoint, stop and wait for human approval before starting anything new.
3. Start every lane whose After lanes have all finished — Step 3 for a builder lane, Step 4 for an inline lane.

5a. Wait for the Completion Notifications

Every builder lane ends with a completion notification — the Agent call returning only meant the builder started. Until a lane's notification arrives, do NOT:

• run the full gate,
• start a lane that lists it in After,
• dispatch a task-reviewer for it (Step 6), or
• mark the build complete.

The same holds for every researcher, task-reviewer, and SendMessage resume: act on a subagent's result only after its completion notification arrives.

5b. Full Gate, once

When every lane has finished — with --reviewed, once every lane's review has passed (Step 6) — run the project's full test suite plus its validators (lint, type-check, project validation scripts) once, on the joined tree.

5c. Fix Rounds

Route each failure to the lane that owns the failing file:

• Inline lane: fix it in the main session, commit by pathspec.
• Builder lane: resume that lane's builder with SendMessage — send only the failing output. Its context and prompt cache are intact, so it skips the cold start a new spawn would pay. Wait for its completion notification.

Then rerun the full gate. Max 2 rounds per lane — then stop and escalate, or switch to /turbocharge:debug when the cause isn't obvious.

Step 6: Reviewed Mode (--reviewed)

For security-sensitive code, unfamiliar codebases, or complex integrations. Reviews run per lane, not per task:

1. Before the lane starts — before spawning its builder or starting its first inline task — record BEFORE_SHA=$(git rev-parse HEAD) for that lane.
2. After the lane finishes and its builder's completion notification has arrived, dispatch one task-reviewer (Sonnet) with:
   • Plan file path + the lane's task line ranges (the reviewer reads the plan directly — do NOT paste requirements)
   • The lane's diff: git diff $BEFORE_SHA..HEAD -- <lane paths>. Lanes own disjoint files, so the pathspec isolates this lane even though other lanes' commits interleave in the range.
   • Working directory. Do NOT send the builder's narrative report — the reviewer reads the diff, not claims.
3. Then wait for its completion notification and apply the disposition.

The reviewer returns two verdicts: Spec: ✅ / ❌ and Quality: Approved / Issues found / N/A (N/A when Spec is ❌ — quality isn't assessed on code that will be rewritten).

Disposition:

• Spec ❌, or Quality has any 🔴 Critical: fix only those items — builder lane: SendMessage the lane's builder; inline lane: fix in the main session. Then SendMessage the same task-reviewer to re-review the new diff. Max 2 cycles — escalate to the user if still failing.
• 🟡 Important / 🟢 Minor only: do NOT loop. Carry them into the completion report (Step 7) so the user decides.

A reviewed lane is complete only after Spec ✅ with no unresolved 🔴 Critical.

Step 7: Complete

After the full gate is green:

• Report a completion summary, including any carried 🟡/🟢 review findings
• Print the final visibility line: lanes: L (inline I · builder B) · spawns: S · tasks: Y/Y
• Offer: "Ready for holistic code review?" → chains to /turbocharge:review

Visibility note: the orchestrator cannot read exact token counts. This line is the lane/spawn/task summary (the measurable proxy), NOT a fabricated token number.

Red Flags — STOP

Process Violations

Rationalizations That Mean You're Wrong

If you catch yourself thinking any of these, STOP:

Workflow Position

plan → build → review → ship