The missing layer between
business, engineering and AI.
For the first time, product owners, business analysts, architects, developers, QA engineers and AI agents can contribute through the same workflow and the same source of truth. Instead of knowledge being scattered across Jira, Confluence, Miro and forgotten documents, everything lives in the repository, evolves with the code, and stays continuously validated. Repository Standards turns your repository into the operating system for AI-native software development.
You are not shipping too slowly.
You are forgetting too fast.
None of them show up in a sprint review. They surface eighteen months later, when the person who knew has left and a two-line change becomes a two-week dig. Teams survived that, because the damage accrued at human speed. Agents do not work at human speed.
Why it works this way lives in one person's head and a thread from March. They leave, and the decision gets made again, differently.
The wiki was true the day it was written. Now nobody opens it, and nobody can say which half of it still holds.
An agent writes in a minute what takes an afternoon to review. Reading code nobody on the team wrote is slower than writing it was.
Code and intent part ways without one failing test. You find out in an incident, an audit, or a handover - never in a review.
The PO writes it.
The dev sharpens it.
AI Agents maintain it!
One living spec, three pairs of hands, on a loop that never dead-ends. Everyone keeps the job they are good at, and nobody has to reconstruct last quarter from memory.
Write it in words. Not in YAML.
You describe the behaviour you want, and the loop asks exactly the questions that make it buildable - one round, in plain language.
The technical ones you can defer on the record, so nothing gets guessed and nothing quietly goes missing.
no story reaches a developer half-bakedPick up a spec, not a mystery.
Every spec you receive is buildable: the contracts written down, the decision recorded where the next person will actually look.
Move a capability's code without its spec and the guard stops the pull request, long before a reviewer has to notice.
no re-litigating what was decided last springReads the repo. Not your mind.
One entry point, honest indexes, and gates it can actually obey. It plans, asks until nothing is open, then builds against the spec.
It never invents behaviour, and it never invents a decision that nobody recorded.
a fresh session starts where the last one left offStart a project clean, or start from
the mess you already have.
Most tooling assumes a repository that does not exist yet. This one also takes the repo you actually have: four years deep, three abandoned conventions, a test suite nobody trusts. You do not clean it up first. It gets measured as it is, and nothing moves until you say so.
Day one, already in order.
Scaffold from the current standard and start building. The specs, decision records, guards and the agent guide are wired in from the first commit, so there is no "we will document it later" to come back to.
- The eight foundation decisions come with a paved-road default each
- CI gates compliance from the first push
- You choose whether the technology layer comes along on day one
Say yes and repository-standards/node comes with it: Next.js and Fastify, running before you write a line. Say no and the method still stands on its own.
Rescue the mess, in waves.
A years-old repo is a first-class citizen here, not a lost cause. It gets assessed, then aligned in prioritized waves - never a big-bang rewrite, never a branch that stays open for a month. You re-enter the loop whenever you have the appetite.
- The decisions living in chat get written down where they belong
- Money paths get specs first, the rest queues in the backlog
- Nobody asks you what you are running - the assessment works it out
Your technology is detected during the assessment. If a layer exists for it - node today - you are asked whether to bring it in. Decline it and add it in a later wave.
Not just how the code looks.
How the work runs.
Three phases, one living spec, and a hand-off that never loses anything on the way. Everything below is a file in your repo and a page in the docs.
Seventeen things a project forgets.
All seventeen get a home.
The short version. Every one of these is a real file or folder that lands in your repository.
who you are building for
PRODUCT.mdthe vision, and the metric each capability moves
journeys/how a real person moves through it
specs/behaviour by capability, buildable
ideas/undecided, and labelled as such
decision-records/adr/the why, and what it cost
decision-records/bdr/the business calls, same shape
PRINCIPLES.mdwhat wins when two documents disagree
discovery/meetings, with their provenance
backlog.mdintents, each with a definition of done
.claude/skills/the loop, as procedures the agent runs
conventions.mdcommits, branches, working language
SECURITY.mdwhere a report goes, and what happens next
runbooks/incidents, and the postmortem after
standard.manifest.jsonwhat compliant means, as data
scripts/drift scoring and the guards
SPEC.mdthe numbered rules, all of them
A product tracking tool comes with it.
The pool, the sprint and the timeline are files in your repository - so you can ask for the state of the work and get it back rendered, not as a file dump. Keep your board and bridge it, or run without one.
The missing layer between business, engineering and AI: one repository every role contributes to, and a standard that proves it still holds.
Open source, MIT, no build step. Version 1.0.1, the first stable line - and no public adopter to point at, because the mechanics have been run on the author's own repositories. Every guard here is dependency-free and runs in a clone, so test the mechanism before you trust it.