Evidence-Gated Handoff for AI Agent Workflows

Stop trusting "done"

Multi-agent coding pipelines break at the handoff. One agent writes the code, another "verifies" it, and the evidence is whatever the first agent says it did. Tests pass because the agent wrote tests that pass. A ticket reaches DONE with every acceptance criterion written in prose and nothing checking any of them.

Evidence-Gated Handoff is an instruction skill that makes a stage-to-stage handoff believable. It gives your agent six rules and a step-by-step procedure for building and reviewing gates that do not rely on an agent's self-report.

The six rules

1. Judge on mutation, never on sign-off. Run the gates when the tree changed, not when an agent announces it is finished. A no-diff run is a no-op, not a pass.
2. Evidence is runner-owned. Only the gate runner writes the evidence record. An agent never types its own proof.
3. Every gate must fail first. Run each new gate against the pre-change tree in a disposable git worktree. If it passes there, it is vacuous. If it fails for the wrong reason (a crash, a missing import), it did not discriminate either.
4. Report the negative space. For every transition, list each acceptance criterion with the gates that name it, and print the criteria no gate names.
5. Witness accepted gates. Record each gate's path, file hash and a marker line. Re-check cheaply on any transition so a gate that was quietly defanged after acceptance blocks the handoff.
6. Ratchet legacy debt. Freeze old violations in an explicit list, forbid regression, and force the baseline to tighten when a metric improves.

What you get

• SKILL.md: the rules, an eight-step handoff procedure, a failure-pattern table (symptom, cause, fix) and a review checklist.
• references/gate-patterns.md: copy-ready templates for gate metadata, the negative-control command sequence and decision table, the witness manifest, the coverage block, and the ratchet baseline with freeze list.

Use it when

• You are wiring BUILD, TEST, REVIEW and DONE stages across several agents and want each move to mean something.
• An agent reports success and you cannot tell whether anything was actually checked.
• Your tests are green and you suspect they would be green on broken code too.
• You are reviewing someone else's agent pipeline for self-attestation.

Good to know

• Plain markdown. No scripts, no network access, no environment variables.
• The negative-control procedure assumes your project is a git repository.
• It is a method, not a framework: it works with whatever test runner and CI you already have.