The spec isthe prompt.

A five-row table contrasts what was authoritative before this inversion against what is authoritative after it. Source of truth: the code in the default branch, versus the signed specification. What a reviewer reads: the diff alone, versus the diff checked against an already-approved spec. What survives a rewrite: nothing, versus the spec, with code regenerated against it. What a new agent session reads first: whatever fits in the prompt, versus the committed spec, plan and constitution. What a stale document costs: an untrusted wiki page, versus a failed build.

Two columns compare a traditional design document against a spec under this discipline, across four rows. Read by: humans, versus humans and agents. Enforcement: advisory, versus executable — tests fail on drift. Lifecycle: goes stale, rarely reopened, versus living and continuously validated. Lives in: a wiki nobody visits, versus the repo, beside the code, in CI.

KEYS← → move between rungs · Enter / Space selects the focused rung · Tab reaches each rung directly

Three ascending rungs of increasing rigor. Spec-first: edit only the initial spec, code is generated once and then drifts unchecked. Spec-anchored, the recommended target: spec and code are edited together, tests enforce alignment, drift is detected and corrected. Spec-as-source: edit only the spec forever, code is regenerated wholesale, drift is eliminated by construction — though this rung demands tooling maturity most teams lack. Selecting a rung expands what you edit, what enforces alignment, and what breaks if you are wrong.

KEYSArrow keys move focus between phases · Enter or click opens that phase's inspector · S toggles the skip-the-plan-gate simulation · hovering or focusing Plan dims every other phase

The loop runs Constitution, Specify, Clarify, Plan, Tasks, Implement and Analyze in sequence, with two feedback edges: Clarify returns open questions to Specify, and Analyze returns detected inconsistencies to Specify. Six of seven phases end in a human sign-off gate; only Clarify is a dialogue rather than a gate. Simulating a skip of the Plan gate rewires Specify directly to Implement and the reviewable diff swells from four files and 180 lines to thirty-one files and 2,400 lines for the same ticket.

1# Constitution — <project-name>2①Version: 1.0 · Ratified: <date> · Owner: <name>3 4> Governing principles for this repository. Every spec, plan and task is5> subordinate to this document. Where a client agreement is stricter, the6> client agreement wins.7② 8## 1 · Stack (non-negotiable without an ADR)9- Language: <e.g. TypeScript 5.x, strict mode>10- Runtime: <e.g. Node 22>11- Framework: <e.g. Next.js 15 App Router>12- Data: <e.g. PostgreSQL 16 via Drizzle>13- Package manager: <e.g. pnpm — never mix with npm/yarn>14③ 15## 2 · Commands (run these; do not invent variants)16- Lint:  `<make lint>`17- Test:  `<make test>`     single: `<make test T=path::name>`18- Build: `<make build>`19- All three must pass before any commit is proposed.20 21④## 3 · Principles (ubiquitous EARS form)22- THE system SHALL have unit tests for all domain logic.23⑤- THE system SHALL NOT log personally identifying data at any level.24- THE system SHALL NOT gain a new runtime dependency without a human25  decision recorded in the plan.26- THE system SHALL keep HTTP handlers free of business logic.27- THE system SHALL return structured errors from `<errors module>`;28  never bare exceptions, never silent fallback values.29 30## 4 · Specification standard31- One feature = one directory: `specs/NNN-slug/{spec.md,plan.md,tasks.md}`.32- Acceptance criteria SHALL use EARS syntax and carry `AC-NN` identifiers.33- Every task SHALL cite the criteria it satisfies.34- Every spec SHALL contain an explicit "Out of scope" section.35- A spec SHALL be updated in the same pull request as the behaviour it describes.36 37## 5 · Autonomy tiers38| Tier | Work | Agent may | Gate |39|------|------|-----------|------|40| 1 | Tests, docs, lint, dependency bumps | Work autonomously | PR review |41| 2 | Feature work, refactors, bug fixes | Propose a plan, then implement | Approved plan |42| 3 | Auth, crypto, data models, migrations, IaC, public contracts | Analyse and propose only | Line-by-line acceptance + architect sign-off |43⑧ 44**Escalation rule:** when the tier is unclear, treat it as the higher one.45⑥ 46## 6 · No-go paths (propose only, never modify)47- `migrations/` · `infra/` · `src/generated/` · `vendor/`48- `.env*` except `.env.example`, and anything matching `*secret*`49⑦ 50## 7 · Security posture51- Production data SHALL NOT appear in any prompt. Use synthetic fixtures.52- Every agent-suggested dependency SHALL pass composition and licence scanning.53- Secret scanning SHALL run in pre-commit hooks.54 55## 8 · Definition of done56- Lint, tests and build pass via the commands in §2.57- New behaviour has tests a human has read and approved.58- The diff touches only files named in the approved plan.59- The spec reflects the behaviour that shipped.60⑨ 61## 9 · Sharp edges (append every hard-won surprise here)62- <e.g. the ORM session is request-scoped; holding it across awaits deadlocks>63- <e.g. `make test` requires Docker for the Postgres fixture>

KEYSTab through gutter pins, or hover

An annotated constitution.md template with nine gutter markers, each explaining that section's significance on hover or tab. The most consequential are the stack declaration and the dependency policy.

KEYSLeft / Right arrow keys, or the REWRITE button, step through four examples; the current example is announced for screen readers

Four rewrites of vague requirements into EARS-precise criteria, each with an ambiguity/testability readout. 'Users should log in easily' becomes a WHEN/THE-system-SHALL sentence naming a 15-minute link expiry; three more examples cover error handling, performance, and security in the same shape. In every case ambiguity drops from high to low and testability flips from no to yes.

KEYSTab through pattern tiles and slot fields · type to see the assembled criterion and meters update (debounced ~400ms) · Wall of Shame switch shows 4 failing examples with zero typing required

An interactive EARS composer: choose one of five sentence shapes, fill its slots, and the tool assembles the criterion live while scoring it against four meters — testable, atomic, measurable, bounded — with fuzzwords struck through automatically. A Wall of Shame mode shows four pre-written bad criteria failing all four meters with no typing required.

KEYSTab or hover any node to trace its thread · BREAK A TEST button demonstrates the failure trace · RESET returns to the neutral state

Four columns — criteria, tasks, commits, tests — share one magic-link example, five items each, linked one-to-one. Hovering any node highlights its connected thread; a 'break a test' button turns a test node red and traces the failure backward to its task and acceptance criterion, printing which specified intent failed.

KEYSDrag the range slider, or focus it and press Left / Right, to scrub week by week · the current week and both tracks' status are announced for screen readers

A twelve-week simulated timeline comparing two tracks. Track A, no enforcement: alignment starts at 96 percent and decays through three unfixed events to 34 percent. Track B, CI coverage check enabled: the same three events each fail a build immediately and get corrected the same week, so alignment saw-tooths back near 96-98 percent every time. This is a demonstration of the mechanism, not a measured statistic.

KEYSTab through the pills to filter · hover or focus a mark for its detail

A scatter plot with ceremony on the horizontal axis and enforcement on the vertical. Claude Code, cc-sdd, OpenSpec and no-tool sit low-ceremony; GitHub Spec Kit sits centrally; Cursor and BMAD-METHOD cluster near it; Kiro and Antigravity sit higher on both axes; Tessl sits at high-ceremony, high-enforcement. A dashed region marks the low-ceremony, high-enforcement sweet spot. Filtering by agent, context, or risk tolerance dims non-matching tools and prints a one-line verdict.

package.json
src/
  (400,000 lines you did not write)
AGENTS.md  ← new

KEYS← → or click STEP buttons · MONTH 3 toggles the fast-forwarded state

A five-step on-ramp shown as a repo tree gaining one file per step: AGENTS.md, a spec directory, a characterization-tests directory, then a CI workflow file. A month-three toggle fast-forwards to twelve accumulated feature spec directories, with no separate documentation project ever scheduled.

KEYSTab through the five toggles · Enter/Space to flip one

A decision widget with five yes/no questions: will agents write a meaningful share of this code, will more than one person maintain it, are requirements complex or contested, is it integration-heavy, regulated, or safety-relevant, and will it outlive this quarter. A verdict bar fills as yes answers accumulate: four or five recommend full spec-anchored SDD; three recommend a light spec-first approach; one or two recommend skipping specs and keeping only a plan-approval gate; zero recommends skipping the methodology and just building it.

KEYS← → moves between segments · each segment has its own COPY THE PROMPT button

A timeline in five weighted segments spanning ninety minutes: twenty minutes to write a constitution, thirty to write one spec, ten to clarify ambiguities, twenty to review a plan, ten to decompose tasks and implement the first one. Each segment names its artifact and offers a prompt to paste into an agent.

KEYS← → walks all twelve steps across both phases · Enter or click selects one

A two-phase, twelve-step sequence: Phase A is human-led and document-first — repository and constitution setup; Phase B turns those decisions into a running environment — Jira, CI, and permission wiring. Selecting a step shows what it produces and why it precedes ticket work.

KEYSTab through the six edge buttons · hover or focus for detail

A triangle of three systems — Jira, Git, Claude Code — connected by six directional integrations, each keyed on the ticket's Jira identifier. Selecting an edge shows what configuration wires it and what it keeps in sync.

KEYS← → moves between stations, wrapping · Enter or click opens the detail panel

Six stations — Person, The Board, Claude Reads and Drafts, Commit and Update, Human Reviews, Claude Initiates — with three marked SPEC where the specification is written or amended. Selecting a station opens its detail: what it does, what it produces, and which of three backward paths reopen the spec, hold at the board, or loop automatically for Tier 1 work.

KEYS← → moves between tiers · Enter / Space selects the focused tier

Three ascending tiers — agent-autonomous, to-plan, proposal-only — each stating who decides, what Claude Code may do unasked, who it escalates to, and what forces the ticket up a tier regardless of its label. Selecting a tier shows all four fields.