How we build

AI writes most of the code. It does not decide what to build, and it does not ship.

The build loop: record, grill, plan, plan grill, bites, gates, landSeven steps left to right, with a human at every step.Decision recordthe design, writtenGrillfour seats challenge itPlanbites and scenariosPlan grillpressed againBitesfailing test firstGatesbuild · unit · integrationLandfull suite greenA human at every step
Every change walks this row. Nothing skips a step.
  1. Every change starts as a decision recordContext, the decision, the consequences, the standard it touches. The record is the specification and it stays in the repository. Its number is a GitHub issue, opened first so two people can never mint the same one, and every record has a card on the project board: a skill pushes status, labels and a summary from the record, so the board reads from the repository and never the other way round.
  2. The grillBefore anything is built, the design is challenged from four seats: the clerk under time pressure, the auditor months later, the financial director accountable for the numbers, and the salesperson in a demo. What survives is built.
  3. A plan of bites, with scenariosThe plan names every file each bite touches and states its acceptance criteria. For correctness work the criteria are written as scenarios, given, when, then, and the plan declares the commands, events and queries the scenarios reach through, so a test can compile against them before any code exists.
  4. The plan grillThe plan is pressed the moment it is written, the same way the design was: for a bite a lane cannot build and prove, a file the plan forgot, a screen the change repoints that nobody swept. What it changes is recorded on the plan.
  5. The failing test comes firstAn independent test author, given only the scenarios and the declared contracts and never the implementation, writes the acceptance tests. They fail. A bite cannot be committed while its test is red, and it cannot be committed by changing the test.
  6. Guarded developmentArchitecture tests fail the build on a cross-feature reference, a missing permission, an unreached handler, an untyped identifier. The rules are code, not a wiki page.
  7. Gates and landEvery change runs the full suite before it lands. A land never weakens its gate because another land is running.
The skills

Thirty-one skills and six agents, one job each. They ship with the source.

A skill is a written procedure the assistant follows to do one job the way this codebase does it. An agent is a skill dispatched with its own context, so it cannot see what it must not see. This is the set that works for us. The skills are text files that ship with the source, so you are free to change them, drop the ones you do not want, add your own, or adapt the whole loop to your own environment.

Design

Create a decision record, opening its GitHub issue · grill it · write and grill its plan · model a contested concept · keep the status map, the issue and the project board in step

Build

Implement an ADR bite by bite · scaffold a command slice · author an account type from a template · write tests the suite's way · write the help article · sync settings YAML with the database · regenerate API types · draw a diagram

Prove

Run the full suite on the build box · run the pre-push probes · bring up the UAT desk · audit shipped claims against the code · audit event-to-projection coverage · read the coverage report · read a CI failure

Land and run

Merge to main behind the full gate · push and watch the deploy · partition work into lanes · coordinate the lanes · the weekly retrospective · seed and reset an environment

The agents

The acceptance-test author, who never sees the implementation · the cross-feature guard · the bootstrapper auditor · the seeding-impact analyser · the UI-to-API sync checker · the CI-failure analyser

What this means for you: the same loop ships with the source. Your team runs it with the same skills, the same gates and the same records, or with its own version of them.