Land only the agent branches a fresh verifier passed

Version 1.16.0 of the workflow orchestration plugin adds two Workflow templates for the most common multi-agent job. You change code on several branches at once, and you trust it only after an agent that didn't write it has checked it. They're called implement-verify and repair-round, and they ship in a new skill, workflow-implement-verify.

You give implement-verify two to five units of work, such as issues or tasks. Each one gets an implementer in its own git worktree, writing the test first. As soon as it returns, a fresh verifier takes the branch, reruns every gate, and reverts the fix to prove each new test fails without it. A fix-needed verdict gets one repair and one re-verify. Then a single finalise agent pushes the branches and opens the pull requests, in order.

The templates come from 51 implement runs and 12 repair runs, written on the fly across 14 projects. 44 of the 51 already added a fresh verifier for each unit. 20 opened pull requests from inside the parallel agents. And three repair runs reported a unit as approved when its verifier had died.

In those three runs, this check skipped the repair and approved the unit whenever the verifier died. In both templates, an empty verdict is UNVERIFIED, and it never lands. A reject verdict means the approach is wrong, so it goes to a person instead of an automatic repair.

// A null verdict is a dead verifier, never an approval.
…
if (!verdict) return 'UNVERIFIED'
if (verdict.verdict === 'reject') return 'REJECTED'
if (verdict.verdict === 'fix-needed') return 'FIX_NEEDED'
return repaired ? 'REPAIRED_PASS' : 'PASS'

Every unit comes back as a row, with the author's report and every verdict attached. PASS and repaired pass are the two that land. The rest are held back. And fix needed, still failing after its round, is exactly what repair-round takes as input.

repair-round starts from existing branches and the findings a verifier or a review listed. The fixer checks each finding against the code, rejects a wrong one with evidence, and pins each real fix with a test. Then come the same fresh verifier, one repair round, and a push to those branches. A fix needed row from implement-verify becomes a repair-round unit, so a second round is simply a second run. The verify and repair code is identical in both files, and a test fails if the two copies drift.

{ id, branch,
  findings: verdict.new_defects }

scripts/tests/
test-templates.sh

Each file is a template to read and then rewrite, with your own prompts, gates and setup. As shipped, a run takes at most five units, and a sixth aborts it before any agent starts. At five units, the worst case is 21 agents. And neither template merges. That stays with git-merge-hazards in git-plugin.

This release only adds, and your existing skills work as before. workflow-wave-dispatch now says a wave with known units is one implement-verify run, with base set to the branch the last wave landed on. And in git-plugin, git-issue's parallel mode points here too. Skip the harness for a single unit or a docs-only edit. For two to five branches, a fresh verifier now checks every one before it lands.

Slide text

1.16.0 implement-verify repair-round using it

1.16.0 adds one skill, and your existing ones work as before

workflow-wave-dispatch

a wave with known units is one implement-verify run, base set to the last landing

git-issue --parallel

in git-plugin

pass the partition as units to have each group verified

github.com/laurigates/claude-plugins

One unit, or a docs-only edit? Skip the harness.