Skip to content
Development
Skill

/cvg-build-loop

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.

From plugin
convergo
711 skills
Install
$ npx -y skills add gomilesf/convergo --skill cvg-build-loop --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/cvg-build-loop

Context preview

The summary Claude sees to decide when to auto-load this skill.

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.

SKILL.md

cvg-build-loop.SKILL.md
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

Read more
Ships withconvergo

Plan → review → build loops for coding agents — that actually terminate. Agent-written code needs review, and agent review needs a loop: find issues, fix them, review again.

Get the whole plugin
Stats
7
Stars
2
Forks
Active
Maintenance
TypeScript
Language
MIT
License
6d ago
Last commit
2mo ago
Created

Repo: gomilesf/convergo

Other skills on convergo.