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.

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. 3Enforce the rules with settings and hooks
  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, baseline first
  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 and CI check 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 sends the agent back up to three times while the check fails, and the gates job in CI runs it again. The pr-template check fails a pull request with an unfilled Tracker, Satisfies, Risk tier, Contract or Tool line, or with the placeholder still in its verification section.

Why

Done means every condition below is true. An agent saying it finished does not count. Neither does an open pull request, or code that works on one machine.

One failure gets special attention in this playbook. When an agent works to make a failing test pass, it can add a special case for that test. The test passes, and the code is still wrong. The sign 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.
  2. The change answers the question the task asked. 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 whenever a phase lands.
  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 CI check has to test something. The kit’s gates job fails until the team replaces its placeholder with the real build and test steps. A required check that passes without testing anything looks like evidence when there is none.

The pull request says how it was built. Which tool, what the agent was asked to do, and what the human changed afterwards. When the template says Tool: Claude Code, a CI job adds the claude-code-assisted label. The label 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.