Edison SinaniAI implementation architectBook a call

AI Team Playbook / Rule 4 of 12

Three gates before any code

A feature passes three gates before code is written: the developer writes requirements, then a design, then a task list, and the lead approves each one.

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 who will build the feature writes all three. The lead approves. The spec-checker agent finds gaps before the lead sees them.
In the kit
docs/specs/_template/docs/specs/example-document-title/.claude/skills/spec/.claude/skills/tasks/.claude/agents/spec-checker.md
Enforced by
The /tasks skill refuses to run on a design that is not approved. The tracker entry cannot be written without a requirement number to cite.

Why

The industry now calls this shape spec-driven development. GitHub’s Spec Kit, which reached version 1.0 in August 2026, and AWS Kiro both use the same three-document sequence [18, 19]. I use Kiro’s words for the documents, requirements, design and tasks, because they are the words most teams already say.

The gates do two things. They give the agent a precise target, so it builds the right thing once. And they make the developer, not the lead, the person who writes down what the feature is. Writing the spec is how a developer learns the system faster than reading it.

How

Requirements. A user story, then numbered acceptance criteria in EARS form, so a task can cite one by number and a test can be named after it. EARS has five patterns: THE SYSTEM SHALL, WHEN, WHILE, WHERE, and IF THEN.

1.2 WHEN the document type is Invoice THE SYSTEM SHALL derive the title as
    "Invoice <number>, <shipper>".
1.5 IF processing fails or no title can be derived THEN THE SYSTEM SHALL leave
    `displayTitle` empty.

Two sections matter more than they look. “Out of scope” stops an agent adding the thing anyway. “Open questions” must be empty before approval, with the answered ones kept in the file. The /spec skill interviews the developer section by section and pushes on every criterion with the same question: how would a tester know?

Design. One paragraph on the approach, the decisions the lead has already made so nobody reopens them, the changes per component with the contract each touches and the tests that prove it, phases that can each merge on their own, and verification written as questions a tester answers. Those questions become the definition of done for the feature. For anything with a screen, the design needs the prototype from rule 5.

Tasks. Each task is one pull request under 400 lines, done by one person in under a day. Each cites the requirements it satisfies, lists the files it touches and the files it must not, names its contract if any, and carries a risk tier. Tasks that touch different files are marked [P] and can run at the same time. A task that changes a contract runs first, alone. The /tasks skill produces the table and a tracker entry per task, ready to paste.

Each gate review is fifteen minutes. Requirements can be reviewed over chat. The design walkthrough is better live.

References

  1. 18GitHub, Spec Kit release 1.0.0, 21 August 2026. github.com/github/spec-kit/releases
  2. 19AWS Kiro documentation, "Specs": requirements, design and tasks with approval gates. kiro.dev/docs/specs/