You have an idea. At the end it runs. In between: you.

01 Brief

You say what you want to build. The questions come one at a time. What problem does this solve? Who has it? What does the product do, and what will it not do? How will you know it worked? Nothing goes on the page that you did not say.

It is one page, and it is the only step that needs nothing before it. The most useful part is the one nobody writes down by themselves: what this product will not do. Every later step reads that line.

02 Personas and journeys

The personas come from the audience groups in the brief. Each one stands for a real group of users. Later, when a decision can go two ways, you have somebody to decide it for.

Everything later rests on the journeys. One per flow, told as a story from the persona's side and not as a spec: the moment it starts, what they really do, what annoys them about it today, and what changes once your product exists. Not a table of steps, and not a wish list. Together they have to cover everything the brief promised, and the backlog later follows them. If a journey is wrong, every story under it is wrong in the same way.

03 Domain model

The things your product deals with, what they are called, how they relate to each other, and the states they move through. Taken from the nouns the personas really handle, in business language. No tables, no foreign keys, no database yet.

It is a reference, not a build order. Nothing gets built just because it stands on this page. The schema grows story by story, and it fits together because every story reads the same page. The names are decided here too, in English by default. The build takes them over unchanged, and every story that invents its own word costs you later.

04 Design brief

How it should feel, the principles behind it, and the screens that matter. Enough for a design system and a prototype to come out of it, instead of somebody guessing at both.

What you get back is a prompt. Give it to Claude Design or to Figma, and you get a real prototype, not a mood board. Its URL goes onto the stories in step 06. Whoever builds a screen then has the design itself, not a description of it.

05 Technical frame

Backend, frontend, auth, storage, the services you talk to. You make each decision while it is still cheap to make, and it is written down with its reason, so nobody reopens it in the middle of a story.

It also settles the things that run through everything and hurt to change later: how identifiers are built, what an error looks like, how validation works, migrations instead of a setup script. Storage comes late on purpose. What you have to store decides which database you need, not the other way round.

At the end it hands you the command that turns those decisions into a working environment, already filled in.

› monoceros init acme \
    --with-languages=node \
    --with-services=postgres \
    --with-features=claude,claude-code-roles,github,atlassian/twg

06 Backlog

Epics and stories, cut from the journeys. One story promises one function and holds everything someone needs to build it: schema, endpoint, view, migration, configuration. Nothing that only a later story needs.

That rules out most of what a backlog usually starts with. No scaffolding story, no schema story, no design-system story. You build the scaffolding when the first function needs it. That makes the early stories big, and that is fine. Anything you build before a function needs it is a guess, and you pay for it twice.

One test before a story is written down. If this were the last story built before a demo, what could the persona do afterwards that they could not do before? If there is no answer, it is not a story.

07 Project files

The README for people, and the agent instructions for whoever reads them next: the stack, the conventions, the words your domain uses, and where decisions are recorded. Written once here instead of repeated in every story, because an agent reads this file before every task.

It asks what is public and what is not, and then it splits the files along that line. What describes the code is committed. What names your customer, your Confluence space or your board is not, and nothing you commit points at it.

The development flow is the part with an opinion in it, so you get a proposal instead of a finished text: branch, draft pull request, board status, commit, comment, merge. Twelve steps, and two places where it stops and asks you. Nothing goes into the file before you have seen it.

the project directory

  README.md      for people
  CLAUDE.md      for Claude Code
  AGENTS.md      for OpenCode

08 The workbench comes up

You run the command from step 05, and Monoceros builds the workbench: a container with the stack you decided on, the services running next to it, and the roles installed. One command, and nobody sets any of it up by hand.

The agent works in there and cannot reach the rest of your machine. Not your keys, not your browser, not the directories next door. That is the reason you can let it work instead of watching it.

Monoceros builds the container from that one file, so you can throw it away. Tear it down, build it again, and you get the same thing back.

› monoceros apply acme

  ▸ pulling image, installing features...
  ✓ workbench ready

09 Plan

The planner reads the story, then it reads what belongs to it: the epic above it, and the discovery pages behind that. It also looks at what is really in the workbench, so the plan fits the stack you have and not one it assumed. Then it clears up the rest with you, while being wrong is still cheap.

It writes a plan that a fresh agent can carry out without ever seeing the conversation. It writes no source code at all, and a hook makes sure of that. At the end it names the command that carries on, with the plan filled in.

› /monoceros-plan ACME-126

  ✓ plan written
  › Continue with /monoceros-ship guestbook/reminder-emails

10 Implement

You hand over the plan, not the ticket, and the implementer follows it and may not change it. Every changed line goes back to a step in that plan. The code next door stays as it is, and nobody gets improvements they did not ask for. When the work is done, it tells you what to test and waits.

Then it runs the acceptance command from the plan, and the real output decides. It commits, and there it stops. Pushing, merging and everything else that leaves your machine is not its job.

› /monoceros-ship guestbook/reminder-emails

11 Review

The reviewer knows nothing about the change, and that is the whole point. It never saw the conversation and never watched the work, so it cannot carry a misunderstanding over from either one.

It only reads, and it gets evidence before it forms an opinion. It runs the acceptance command itself instead of believing the implementer. Then it compares the result with the plan, step by step. The answer is PASS, or CHANGES_REQUIRED with a numbered list under it.