build

name	build
description	Run the inner agentic loop on one task. The implementer builds, a fresh-context reviewer judges, and findings cycle back until approval (max 3 rounds). Use when the user says "build X", "implement issue

/build: the inner loop (evaluator-optimizer)

Input ($ARGUMENTS): an issue number, a task description, or empty (meaning the next ready backlog item).

You are the loop controller. You do not implement or review yourself; you dispatch the implementer and reviewer subagents, own the command-contract gate, route the verdict, and own git state.

1. Resolve the spec

• Issue number → gh issue view <n> (body + comments).
• Description or empty → if it already has acceptance criteria, use it; otherwise spawn the pm agent to shape it into a spec (for empty input, PM also picks the item).
• No acceptance criteria obtainable → stop and ask the user; never build without a spec.

2. Prepare isolation

If not already on a task branch/worktree: create branch agent/<short-slug> (worktree if the session supports it). Never build on main.

If the task is an issue, label it in-progress now; remove the label when the loop ends (PR opened, or escalation).

3. Loop (max 3 rounds)

Round N:

1. Implement: spawn the implementer agent with the full spec text. On round 2+, message the same implementer (it has the context) with the reviewer's blocking findings verbatim.
2. Sanity-check its report: if STATUS: BLOCKED, stop and surface it to the user.
3. Gate: run check/test/build yourself on the finished diff. You own this run: the implementer checks only what it touched, and the reviewer takes your result as given. Red goes back to the implementer without consuming a round, at most twice in a row; a third red gate ends the loop the way STATUS: BLOCKED does, with the failing output surfaced.
4. Review: spawn a fresh reviewer agent each round (never reuse; fresh context is the point). Give it only the spec, the branch/diff reference, the round number, and the gate result. Never forward the implementer's report or reasoning.
5. Route the verdict:
   • APPROVE → exit loop to step 4.
   • REQUEST_CHANGES → next round with the blocking findings.
   • No-progress exit: if the round produced the same blocking findings as the previous one, or the diff didn't change, stop early and escalate; more rounds provably won't help.
   • Disputed finding: when the implementer disputed a finding with evidence and a reviewer restates it, surface the disagreement to the user if interactive. If headless, spawn a fresh judge agent (general-purpose) with only the spec, the finding, and both sides' evidence; its ruling on that finding is final. Never let the implementer and reviewer negotiate to consensus.
   • After round 3 still not approved → stop and escalate: present the spec, what was built, and the unresolved findings. Do not keep looping; do not merge anything.

4. On approval

Your gate already ran green on the approved diff, and CI runs it again on the PR.

1. Commit on the task branch following the commit skill: small modular commits, referencing the source issue.
2. Interactive session → present a summary and ask whether to push + open a PR. Headless/CI session → push and open a PR, Closes #<n> in the body, and comment the PR link on the issue.
3. The summary/PR body must make the human gate an informed check, not a rubber stamp:
   • what was built, mapped to the acceptance criteria
   • review-round history: findings by severity, fixed vs disputed
   • verification evidence: the gate result, and what the reviewer exercised on the running app
4. Never merge. The merge gate is human.