build-verify-loop

Build-Verify Loop

A standalone Claude Code skill. Drop this directory into ~/.claude/skills/build-verify-loop/ and trigger with /build-verify-loop <task>. No additional configuration required.

What this is

An orchestration pattern for autonomous work. The main agent does not do the work itself — it spawns two isolated subagents per round:

• Implementor — produces / revises the artifact, addressing prior findings
• Critic — adversarial audit against acceptance criteria

The loop continues until the Critic finds nothing material for two consecutive rounds, or an exit condition forces escalation. The main agent never judges the content of individual findings, never paraphrases between subagents, and never injects its own framing — this is the discipline that makes the loop work.

When to use

Trigger phrases:

• /build-verify-loop <task> or /bvl <task>
• "Run a build-verify loop on X" / "Use bvl on X" / "Run bvl for Y"
• "Autonomously complete X with self-verification"
• "Self-iterate Y until done"
• 「自主完成 X」「閉環跑 Y」「自己跑迴圈做 Z」「用 bvl 跑 X」「啟動 bvl 做 Y」「使用 bvl skill 做 X」

Good fits:

• Producing or revising a non-trivial artifact (code module, document section, design doc, plan, proposal, spec)
• The user has acceptance criteria they can articulate up front
• The user wants the work done without per-round confirmation, but with rigor preserved

When NOT to use

• Single-shot tasks (no iteration needed)
• Open-ended exploration where AC cannot be defined
• Real-time conversational tasks
• Tasks where the user wants to be involved in every round
• Tasks requiring external side effects (deploy, send email, post to chat) — this skill is for artifact production only

Required inputs

When triggered, ensure the following are provided. If any are missing, ask in one batched message before starting the loop:

1. TASK — one-line goal statement
2. ARTIFACT — file path(s) the Implementor will read and write each round
3. ACCEPTANCE CRITERIA (AC) — bullet list defining "done". Examples by domain:
   • Code: tests must pass, no hardcoded credentials, function signature matches foo(x: int) -> str
   • Document: covers sections A/B/C, audience is non-technical executives, under 800 words, tone formal
   • Plan: includes pre-conditions, rollback, owner per phase, risk register
4. DOMAIN CONTEXT (optional but recommended) — short paragraph orienting subagents to the work
5. ITERATION_CAP (optional, default 5) — max rounds before forced escalation