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. 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 who will build the feature writes all three. The lead approves within one working day, and on a larger team may delegate the tasks gate. 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.

The gates do two things. They give the agent a precise target to build toward. And they make the developer the person who writes down what the feature is. Writing the spec also makes the developer read the parts of the system the feature touches.

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 need extra care. “Out of scope” stops an agent from adding what the feature excludes. “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 asks the same question of every criterion: how would a tester know?

Design. One paragraph on the approach, the decisions the lead has already made, so the team does not reopen 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.

The lead answers a gate within one working day. A gate that waits longer is the lead’s blocker to raise at the weekly checkpoint. With five or six developers, the lead may delegate the tasks gate to the milestone’s reviewer of record and keep the requirements and design gates.

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/