Edison SinaniAI implementation architectBook a call

AI Team Playbook / Rule 1 of 12

Write the constitution first

Before anyone starts, the lead writes down the technology stack, the rules that never change, and the things the system deliberately does not do.

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 lead writes it once and changes it only by pull request with an ADR.
In the kit
docs/constitution.mddocs/adr/
Enforced by
Every gate review checks against it. The reviewer agent and the automated review flag any change that breaks a non-negotiable.

Why

An agent starts every session with no memory. The first thing it needs is the basic context: what the stack is, what must never change, and what is missing on purpose. Without that, it proposes rewrites and adds features that are not in the spec.

The most useful part of the document is the rationale next to each stack choice. Here is one from a document-processing product:

Extraction engine: hosted document-intelligence API for the MVP, custom models later. Rationale: high accuracy on day one with no training data; corrections collected in production feed the custom models. The hosted API is temporary.

The second most useful part is the list of deliberate limits. “English-language documents only. Other languages are flagged and skipped. Decided in ADR-0003.” A line like that keeps an agent from building support for other languages.

How

The file has five sections and should stay on one page. If a rule needs a paragraph, it is a decision and belongs in an ADR instead.

  1. Purpose. One paragraph. What the system is for and who uses it.
  2. Stack. A table, one row per layer, with the choice, the version and one sentence of rationale.
  3. Non-negotiables. Numbered rules the agent must never break and the reviewer must always check.
  4. Conventions. Only what differs from the language defaults.
  5. Deliberate limits. What the system does not do.

The kit ships with seven non-negotiables. Keep them unless you have a written reason not to.

  1. No secrets in the repository.
  2. Every change to a boundary between components updates the contract and the tests on both sides. Rule 7.
  3. Every schema change ships with its migration in the same pull request.
  4. Tests run on every pull request, and a red check blocks the merge.
  5. One task, one branch, one pull request, under 400 changed lines. Rule 6.
  6. The agent does not deploy or run destructive commands, and commits or pushes only with the developer’s confirmation each time. .claude/settings.json and the block-destructive.sh hook enforce this. Rule 3.
  7. Anything with a screen has an approved walkable demo before code. Rule 5.

Record each decision that changes the constitution as an ADR: the context, the decision in one sentence, the options rejected and why, and the trigger for revisiting. Keep the rejected options. They keep the team from reopening the same debate later, and they keep an agent from proposing one of them as an improvement.