Edison SinaniAI implementation architectBook a call

AI Team Playbook / Rule 10 of 12

Done means the evidence is in the pull request

A task is done when the project check passes and the pull request contains the evidence that the task's verification line is true. Not when the agent says so.

September 16, 2026 · About 2 minutes

Contents

The playbook

  1. Overview

Before code

  1. 1Write the constitution first
  2. 2One instruction file, under 200 lines
  3. 3Prose is advice, hooks are enforcement
  4. 4Three gates before any code
  5. 5A walkable demo before any screen

Building

  1. 6One task, one worktree, one pull request
  2. 7Every contract has a file and two tests

Reviewing

  1. 8AI review first, and filtered
  2. 9Human review by risk tier
  3. 10Done means the evidence is in the pull request

Over time

  1. 11Measure five numbers from day one
  2. 12Protect the people who are still learning

Appendix

  1. AInstall checklist
  2. BOther tools, limits and sources
  3. CTightening the process
  4. DRun the agent with no entitlements

Get the kit

Who owns it
The developer. The Stop hook enforces the first line; the reviewer checks the rest.
In the kit
docs/definition-of-done.md.github/PULL_REQUEST_TEMPLATE.md.claude/hooks/stop-gate.sh
Enforced by
The Stop hook will not let the agent finish while the check fails. The pr-template check fails a pull request whose verification section still holds the placeholder.

Why

Done is not “the agent said it was done”. Done is not “the pull request is open”. Done is not “it works on my machine”. Each of those has cost a team a week.

There is one failure I have seen more than any other. An agent under pressure to make a red test green adds a special case. The test passes, and the code is wrong. The tell is a condition that mentions a value from a test fixture. The instruction file, the reviewer agent and the automated review all look for it.

How

The pull request template repeats these as checkboxes. A task is done when every line is true.

  1. The project check passes, locally and in CI, and the agent showed the output rather than asserting success.
  2. The change answers the question the task asked. Not “the code runs” but “the verification line is true”, with the evidence in the pull request: a test that asserts it, a command and its output, or a screenshot.
  3. The pull request is under 400 changed lines, or carries the override label with a reason.
  4. One task, one branch, one pull request. Unrelated fixes found on the way became tracker entries.
  5. Any contract touched is listed, and both of its tests changed with it. If none, the pull request says “Contract: none”.
  6. Any schema change ships with its migration.
  7. Nothing was added just to make one specific failing test pass.
  8. The documents the change made wrong were fixed in the same pull request: the instruction file if a command changed, the system design if the shape changed, the feature design’s status log every time.
  9. The automated first pass ran, and every Important finding was fixed or answered.
  10. A human reviewed the change according to its risk tier.

The pull request says how it was built. Which tool, what the agent was asked to do, and what the human changed afterwards. This is not surveillance. It is what makes the weekly numbers in rule 11 possible, and it lets the reviewer read the diff knowing the question the agent was answering.

For the last task of a feature, three more lines. The verification questions from the design were answered with evidence. The design’s status is Implemented and every task shows Done. Anything dropped along the way is written in the design’s deviations section, never dropped silently.