メニュー
Orchestrate a monitored implementation loop where a worker implements the plan and fresh code reviewers gate the exit. Use when the user asks to run a supervised implementation or build loop on Codex threads or Claude Code background agents.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Orchestrate the build loop with split engines - Codex CLI sessions implement and take every first-pass review round while a high-taste Claude design model holds the final exit gate. Use when the user asks for a hybrid, split-model, or cross-model build loop, such as codex implementing with fable as the closer or final reviewer. Claude Code only.
Orchestrate the plan loop with split engines - a high-taste Claude design model drafts and revises the plan while Codex CLI sessions gate it as fresh plan reviewers. Use when the user asks for a hybrid, split-model, or cross-model planning loop, such as fable planning with codex reviewing. Claude Code only.
Review implementation against the plan and contract. Distinguish code bugs from contract gaps. Bounded convergence.
Orchestrate a monitored implementation loop where a worker implements the plan and fresh code reviewers gate the exit. Use when the user asks to run a supervised implementation or build loop on Codex threads or Claude Code background agents.
Orchestrate a monitored planning loop where a planner drafts the plan and fresh plan reviewers gate the exit. Use when the user asks to create or revise a plan through supervised specialist sessions on Codex threads or Claude Code background agents.
Review a plan against the actual codebase. Verify slices are sufficient, surfaces are complete, and invariants are correct.
| name | cvg-build-loop |
| description | Orchestrate a monitored implementation loop where a worker implements the plan and fresh code reviewers gate the exit. 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] |
Use this skill for implementation work that should be executed by a monitored specialist worker and reviewed by monitored specialist reviewers.
Before doing anything, open and read references/cvg-multi-session-protocol.md, then apply the protocol gates from cvg-multi-session:
Record:
git rev-parse HEAD,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.
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:
cvg-work or another user-specified implementation skill,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.
(Codex) After verifying the worker thread with read_thread, send the worker
its verified thread id before creating the heartbeat.
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.
After the worker callback is visible, spawn a fresh reviewer specialist session. Verify it per Gate 1.
Reviewer prompt must include:
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,cvg-code-review,git diff <base>..HEAD,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.
(Codex) After verifying the reviewer thread with read_thread, send the
reviewer its verified thread id before creating the heartbeat.
Complete the waiting handoff per Gate 3 and end the active turn while waiting.
Reviewer should report blocking findings only:
Non-blocking quality notes belong in a separate quality review unless the orchestrator requested them here.
After the reviewer callback is visible, send the reviewer feedback to the same verified worker session with the continue operation (Gate 0).
Do not classify findings, choose repair strategy, filter reviewer output, or turn the review into a patch list in the orchestrator.
Feedback prompt must include:
cvg-code-review-feedback,Code Review Feedback Input section,Do not restate the feedback skill's intake, classification, or repair rules.
The exact findings under Code Review Feedback Input plus the required skill
are the worker's authority.
Worker feedback callback template:
I am the worker. My specialist id is <worker-id>. Code review feedback handling is complete. Base commit: <base>. Previous review head: <old>. New head commit: <new>. Code-review-feedback result: <repaired / plan gap / contract gap / systemic design gap / escalation / clarification needed>. Fixed findings: <brief or none>. Verification: <commands/results>. Known gaps: <none or list>. Please arrange the next review step.
Complete the waiting handoff per Gate 3 and end the active turn.
If the worker reports a plan or contract gap, escalation, or clarification need, route that callback to the appropriate planner, reviewer, or user decision before requesting re-review.
After the worker feedback callback is visible and a reviewable implementation repair exists, send focused re-review to the same verified reviewer session with the continue operation.
If the worker reported a plan gap, contract gap, systemic design gap, escalation, or clarification need, do not request code re-review yet. Route that blocker to the planner, reviewer, or user decision path first, then return to the worker only after the plan or contract is resolved.
Focused scope:
Focused re-review prompt must include:
Review mode: focused-re-review,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.Focused re-review does not require auxiliary reviewers. Do not ask the focused reviewer to dispatch auxiliary reviewers or synthesize inline auxiliary coverage.
Complete the waiting handoff per Gate 3 and end the active turn.
After same reviewer passes, spawn a new fresh code reviewer specialist session for a complete first review. Verify it per Gate 1.
Use the same minimal reviewer prompt shape from Phase 2. The new fresh reviewer
prompt must include Review mode: final-fresh-exit. It must deliver its
callback to the orchestrator per Gate 2; do not accept a result left only
inside the specialist session when the platform requires an explicit callback
send. Do not include previous reviewer verdicts, blocker text, focused re-review results, or worker repair summaries; include only independent risk-area labels if needed.
Final implementation exit condition:
agent_id; inline auxiliary coverage cannot satisfy the final implementation exit condition.A "ready with fixes" verdict (only non-blocking P2 findings remain) satisfies the exit condition; carry the P2 list into the completion summary.
If the new fresh reviewer finds blockers, repeat from Phase 3. Each Phase 3-5 cycle is one round; after 3 rounds without a clean exit, stop and escalate to the user with all open findings and their adjudications (Gate 5 round cap). Apply the Gate 5 adjudication ratchet: findings previously adjudicated invalid or out of scope cannot re-block without new evidence.
If the plan requires integration, staging, deployment, end-to-end, or smoke checks, run them through a QA or ops worker after code review is clean, unless the plan explicitly orders them earlier.
QA worker prompt must include:
Classify QA failures before routing:
Real QA failures can reopen the build loop.
Optionally run a separate quality reviewer for:
Quality findings are not automatically release blockers. The orchestrator decides whether to run cleanup based on risk and timing.
Report:
cvg-code-review-feedback results,