/cvg-build-loop

name: cvg-build-loop
description: Orchestrate a monitored implementation loop where a worker implements the plan and independent code review with focused rechecks gates completion. Use when the user asks to run a supervised implementation or build loop on Codex threads or Claude Code background agents.
argument-hint: "[plan path, base commit, or implementation goal]"

Build Loop

Use this skill for implementation work that should be executed by a monitored specialist worker and reviewed by monitored specialist reviewers.

Read `references/cvg-multi-session-protocol.md` once when entering the loop, then apply the protocol gates from `cvg-multi-session`:

• transport binding gate,
• real specialist session gate,
• orchestrator callback transport gate,
• waiting handoff gate,
• cvg-code-review-feedback gate,
• independent-review exit gate.

Phase 0: Orchestrator Setup

Record:

• current orchestrator session id (Codex thread id; on Claude Code the harness tracks it),
• implementation base commit with `git rev-parse HEAD`,
• worktree status,
• task-owned and unrelated dirty files,
• source artifact or implementation goal,
• allowed external side effects, if any,
• the loop ledger path, created per the Gate 5 loop-ledger rule.

Pass unrelated dirty state to the worker and tell it not to overwrite those files.

If the plan's slices or invariant matrix span multiple repos, declare the repo split and build order to the user before spawning the worker, and scope this loop to one repo's slices: the loop's base/head and diff bookkeeping covers one repo, so changes outside it escape review entirely. Instruct the worker not to modify other repos. Run one loop per repo, and carry every repo this loop does not cover into the completion summary as a blocking known gap — a single-repo exit is never plan completion.

Phase 1: Worker Handoff

Spawn the worker as a real specialist session (Gate 0 spawn operation) and record the id returned by the tool. Verify it per Gate 1; if it is not verifiable, do not continue.

Worker prompt must include:

• role: implementation worker,
• original user outcome, non-goals, authorized changes and applicable constraints,
• callback destination per Gate 2,
• required work skill, such as `cvg-work` or another user-specified implementation skill,
• base commit,
• worktree path,
• dirty-state warning when present,
• plan path or implementation goal,
• implementation notes path only when the plan or repo convention requires one,
• task-specific external side-effect boundary,
• callback transport block,
• callback templates.

Do not restate `cvg-work` execution rules in the worker prompt. Do not paste likely files, broad surface checklists, previous reviewer risk hints, old commits, or repo policy summaries unless the user supplied them as task authority and they are not linked from the plan.

Worker completion callback template:

I am the worker. My specialist id is <worker-id>. This implementation round is complete. Base commit: <base>. Head commit: <head>. Key changes: <brief>. Verification: <commands/results>. Known gaps: <none or list>. Please arrange a fresh code reviewer.

Worker blocker callback template:

I am the worker. My specialist id is <worker-id>. I found a blocking contract gap. Gap: <id/summary>. Evidence: <files/tests>. Recommendation: <repair/escalation>. Please decide the next step.

Complete the waiting handoff per Gate 3 and end the active turn.

Phase 2: Fresh Code Review

After the worker callback is visible, spawn a fresh reviewer specialist session. Verify it per Gate 1.

Reviewer prompt must include:

• role: independent code reviewer,
• original user outcome, non-goals and authorized changes,
• the line `Do not consult project memory, prior sessions, rollout summaries, or external history. The repository's own git history (log, blame, commit messages) is repo evidence, not external history.` before the required skill line,
• callback destination per Gate 2,
• required cvg-code-review skill, such as `cvg-code-review`,
• required independent reviewer signatures, if the user specified any,
• base commit and head commit,
• plan path and implementation notes path when present,
• `git diff <base>..HEAD`,
• read-only boundary,
• blocker-only reporting rule,
• task-specific external-side-effect boundary,
• callback transport block,
• callback template.

Do not paste changed files in full when the reviewer can read the worktree. Provide changed file names or a diff stat only when useful for orientation. Fresh reviewer prompts must not include a `Relevant review history` narrative, prior reviewer verdicts, prior findings, worker repair summaries, or same-reviewer pass/fail conclusions. If history matters, compress it into `Risk areas to inspect independently:` with filenames or behaviors only, after stating the review must be independent.

Reviewer callback template:

I am the fresh code reviewer. My specialist id is <reviewer-id>. This first-pass full code review is complete. Verdict: <ready to merge / ready with fixes / not ready>. Findings: <none or numbered blocker list>. Non-blocking P2 notes: <none or brief list>. Please decide the next step.

Complete the waiting handoff per Gate 3 and end the active turn while waiting.

Reviewer should prioritize blocking findings grounded in the original outcome or applicable constraints, not merely a draft-plan requirement:

• P0/P1 code bug,
• unmet plan criterion,
• missing real surface,
• contract gap preventing required behavior or critical verification,
• unsafe side-effect path,
• missing required migration, rollback, deletion, privacy, or verification gate,
• test/build/deploy gate missing where the plan requires it.

Report relevant non-blocking notes once in the existing result; do not create a separate review merely because optional improvements remain.

Phase 3: Return Review Feedback to Worker

After the reviewer callback is visible, send the revi