For Product Builders

Start a case

Start your own project today: one folder, one session opened on it, the first prompt, and the gates that follow.

Start with your own project, not with an exercise. One outcome you own, one folder holding everything it needs, one session opened on that folder, and the prompt below. Everything after that is the sequence of gates, in order.

Your project

Name the outcome you own in one sentence: who it is for, which problem, what result. You carry it vertically, front and back, from the discovery through to production. Design, Frontend, Backend and API, Data, access, delivery and review are horizontal services you draw on, not people you hand the outcome to.

What goes in the folder

Everything the project needs goes into one folder created for it, rather than staying scattered across drives, mailboxes and tabs.

Every document the project already has — what was written before, what was received, what you collected yourself, whatever the format. The first prompt converts what it can and says what it could not.
The project memory — PROJECT_MEMORY.md, the reasoning layer: where the product stands today, the decisions and their trade-offs, and which source wins when sources disagree. Memory entry
The project journal — PROJECT_JOURNAL.md, the chronological record: dated, appended to, never rewritten, including what turned out to be wrong. Journal entry
The project channel — not a file: a channel opened the same day, with everyone concerned by the product in it, the business people included.

Create the memory and the journal before the first prompt runs, not when you remember.

Open the session on the folder

Open your assistant's session or project on that folder. At this point it is not a repository: there is no application, nothing to build, nothing to run. It is a folder of sources, and that is enough to start. The repository arrives at gate 4, when you clone your organization's frontend starter beside the folder and move the PRD, the memory and the journal into it under docs/.

The first prompt

Where to paste: A new session of your coding assistant, opened on the project folder.
With the skill: Or download the kit and install it for Claude Code or Codex, then invoke the skill on the folder instead of pasting the prompt.

You are at Gate 0 of the method in https://onirion.org/complete.md: setting up a new
product project.

The project folder is the one this session is opened on. Work only inside it.

Do this, and nothing else:
1. Walk the folder and list every file you find.
2. Convert to Markdown everything you can convert, into the sub-folder
   `converted/` of the project folder. Never modify, move, rename or
   overwrite an original.
3. Write `converted/INDEX.md`: one line per source, with the file name, what
   it is, and the date it is from. If you cannot date it, say so.
4. List everything you could not read or could not convert, and why.

Do not analyse the content. Do not draw conclusions. Do not write a PRD.
Do not send anything anywhere — no service, no channel, no address.

Report the index, the list of what you could not read, and where you put the
converted files.

Before you finish, state which gate you are at, what you have, what is
missing, and what I must decide before you cross to the next gate.

What the assistant should answer back. The index, what it could not read, where it put the converted files, and where the work stands:

Gate 0, setting up the project folder.

What I have: every file in the folder walked and listed. What could be
converted is in `converted/`, with one line per source in
`converted/INDEX.md` — the file name, what it is, and the date it is from,
or "undated" where the file carries none. No original was modified, moved,
renamed or overwritten.

What I could not read: the scanned PDFs with no text layer, and a
password-protected spreadsheet.

What is missing: the folder says nothing about who takes the product
decisions, and it holds no user interview.

What you must decide before I cross to Gate 1: whether the older backlog
export is material for the discovery, or history to leave aside.

It interprets nothing and it sends nothing anywhere. Read the index it returns and the list of what it could not read, then fill the obvious holes now, while it is cheap. The prompt has its own page: Inventory and convert.

Then, gate by gate

Gate 0 leaves you with everything in one folder, converted and inventoried. What follows is one gate at a time, each with the prompt it uses, and each prompt ends by asking the session where the work stands.

Gate 1 · Gather the discovery — What is known, what is missing and what contradicts, written into DISCOVERY.md so the next gate can open it by name. Read the channels
Gate 2 · Write the PRD — One document, its first section the strategic framing, refined and aligned with the business, the technical parts included. Analyse and write the PRD · PRD template
Gate 3 · Prototype the end-to-end flows — Your session takes the PM role and prompts the design tool for whole flows, and you iterate until the people concerned say it is their tool. Design prompt — specification · Instruction layer · Refinement prompt
Gate 4 · Port the prototype into code — Inside your organization's frontend starter, with the running front end beside the design and as many back-and-forths as it takes. Port the prototype
Gate 5 · Connect the backend — The long one: flow by flow, deep, including the empty state, the error, the slow response and the permission that says no. Connect the backend
Gate 6 · Test, then ship — Accounts in real hands while the connection work is still going on, then the go-ahead with the leads of the trades concerned. Prepare a release

Gate map

Gate 0, Set up the project folder
Gate 1, Gather the discovery
Gate 2, Write the PRD
Gate 3, Prototype the end-to-end flows
Gate 4, Port the prototype into code
Gate 5, Connect the backend
Gate 6, Test, then ship

Your own project runs the whole sequence: gate 0 on this page, gates 1 to 6 in the core guide, with what each one demands and the prompts it uses.

Read the gates in full →

From a folder of gathered discovery material to a front end you can click: three to four hours at best and twenty-four at worst, when the discovery has already partly been gathered. Then about a month to connect the backend so the flows hold in depth, depending on the size of the application. The code still goes to developers for review, and passes, because the agent works inside your organization's starter and conventions. These figures are the author's own practice, not a study.

What runs across all of them

The control session

A second session whose only job is to challenge the first, open from the discovery to the backend. It reads, checks and challenges; it does not change code, it does not decide scope, and it returns findings with their evidence. You decide. Control session

The standing guardrail

Before every change to the code, the agent goes back to your frontend starter and your backend conventions and re-reads them. That is what keeps generated work inside a shape a developer can review. Standing constraint

When the services are not there yet

Part of what the method leans on belongs to Ops rather than to you: the design system at gate 3, the frontend starter and the backend conventions at gate 4, the path to staging and the reviewing leads at gate 6. If your organization has none of them, do not invent them, and do not let the agent invent them either — a convention made up on the spot is what the review will undo later. Ask for them, with a named owner and a named artifact.

No design system

Ask Design Ops for the components and their states, the tokens, the rules for using them, what may be extended and what may not, and who maintains it. Until it arrives, name an existing product your organization already accepts and design against it as a constraint, not as inspiration: the prototype and the front end must keep drawing on the same thing.

No approved frontend starter

Ask Frontend Ops for the starter repository with its location, version and owner; the architecture, routing and state conventions; how components are meant to be used; the API client pattern, authentication, errors and loading states; the checks required on a deployable branch and the preview path; who reviews frontend work; and an agent-readable version of all of it.

No written backend conventions

Ask Backend and API Ops for the API catalog with real examples; the authentication and permission rules; request and response shapes, errors and versioning; the business meaning of key fields and status values; a test environment with test identities and safe data; and the procedure for requesting an API that does not exist yet.

Practise on a fictional case (optional)

If you would rather walk the gates once on something nobody depends on, the kit ships a practice case: a small local application with two identities, a switch that makes a save fail, and acceptance tests that fail before you implement. It runs on your machine, with nothing to install and no account.

Someone writes a project update, selects Save draft, leaves the page, and finds the text gone on return. That complaint is a made-up exercise input: it is not research, it is not a real user, and nothing here asks you to treat it as evidence. The outcome you own: the author can come back to the text they confirmed, and the second identity cannot read it.

After a save confirms success, the author can reload, or sign out and back in, and find that text again.
The second identity cannot read the draft, neither in the page nor through its direct read route.
A failed save keeps the edited text visible, shows an error and a retry, never claims success, and a reload before a successful retry brings back only the last confirmed text.

The worksheet below says which prompt to run at which gate, what you should be holding when each one closes, and where to write down the services the sandbox cannot give you — a starter, backend conventions, a design system, a path to staging, and the leads who give the go-ahead.

Open the worksheet Download the kit

Nothing needed for this run is reserved for the training.

File example/first-case.md

Onirion · first case worksheet

A method by Alexis Boyer · version 4.0 · September 22, 2026

Run the method once, end to end, on a case nobody depends on. The application is the one shipped beside this file, at sandbox/. You walk the seven gates in order and fill the blocks as you go. The prompts are in the core guide; this worksheet says which one to run where, and what you should be holding when the gate closes.

The complaint that starts this case is a made-up exercise input. It is not research, it is not a real user, and nothing here asks you to treat it as evidence. Wherever the method asks what a source establishes, the honest answer on this case is: a fixture written for practice.

The case

Someone writes a project update, selects Save draft, leaves the page, and finds the text gone on return.

The outcome you own: the author can come back to the text they confirmed, and the second identity cannot read it — not in the page, and not through the direct read route.

What the sandbox already carries, and you can check yourself:

two identities, chosen at /as/author and /as/reviewer and held in a local cookie;
one confirmed draft, fictional-draft-001, owned by the author identity;
POST /save for the form, GET /api/drafts/fictional-draft-001 for the direct read;
a Simulate failed save button that sends simulate_failure=1, so the failure is reproducible with nothing external;
three deliberate defects: the save does not persist, the direct read answers the second identity, and the failure is swallowed and reported as success;
three acceptance tests written against the intended behaviour, which fail before you implement.

Outside this case: deletion, expiry, two people editing at once, offline saving, real authentication.

Run the sandbox before you start

Python 3.9 or newer. Nothing to install, no account, no network.
From sandbox/: python3 app.py, then open http://127.0.0.1:8766/.
Acceptance checks: python3 -m unittest -v test_acceptance.py. Expect three failures. Three errors instead mean the environment stopped the tests binding their local server on 127.0.0.1.
In Codex, the default workspace-write sandbox blocks that local server. Allow network access for the session — codex --sandbox workspace-write -c sandbox_workspace_write.network_access=true — or run the test command yourself outside the sandbox.
The server binds to 127.0.0.1 only and writes sandbox.sqlite3 beside the app. Delete that file to reset your manual run; the tests use a temporary database.
The identity switcher is a cookie, not authentication. Never deploy this server. Never put real data in it.

Open your assistant on the case folder

If you installed the kit's skill, invoke it with the case: /onirion in Claude Code, $onirion in Codex. Whatever you use, ask for the gate statement every time, as the guardrail says: which gate it is at, what it has, what is missing, what you must decide before it crosses.

What the sandbox cannot give you

Five things the method asks for are not here: an approved frontend starter, written backend conventions, a design system, a path to staging, and leads who give the go-ahead before production. At each of those points this worksheet stops and has you write down the service that is missing and who you would ask. Do not invent another organization's standards, and do not let the assistant invent them either. Here you keep going inside the shape the sandbox already has, with the gap written down.

Copy this block each time the worksheet asks for it:

Service missing here:
What I would ask for, concretely:
Who I would ask (the role, not "someone"):
What I did instead on this run, and with whose agreement:
Date recorded in the journal:

The two things that run across the gates

Control session — opened in:
How it reaches the main session here:
If it cannot reach it: I relay the finding unchanged and say where it came from.
Limits written into its first prompt: it reads, checks, challenges; it does not
  change code; it does not decide scope; it does not write the PRD or the
  prompts; it returns findings with evidence and I decide.

Standing guardrail — what the agent re-reads before every change to the code:
What is missing from that list on this run:
The gate statement is asked for at every gate: yes / not yet

Gate 0 — set up the project folder

What you do. Make one folder for this case. Put the sandbox in it, and write the made-up complaint into it in your own words so the material is in the folder rather than in this page. Create the memory and the journal before anything else runs. Then run the inventory and conversion prompt from the core guide, and read what comes back.

Prompt to run. The inventory and conversion prompt (Gate 0). It converts, indexes, and interprets nothing.

Case folder created at:
Sandbox copied into it as:
The made-up complaint written down as:
PROJECT_MEMORY.md created: yes / not yet
PROJECT_JOURNAL.md created: yes / not yet
If this were real, the people who would be in the project channel:
What `converted/INDEX.md` lists:
What the pass could not read:
The hole I filled straight away, while it was cheap:

You should be holding: everything for this case in one folder, converted, inventoried.

Gate 1 — gather the discovery

What you do. Take stock of what you actually have: the sandbox README, app.py, test_acceptance.py, and the made-up complaint. Read the code for what it establishes — the defects are in it, commented. Then write DISCOVERY.md, so Gate 2 can open it by name.

Prompt to run. The Gate 1 prompt, pointed at those three files by name, with its rules block unchanged. There is no channel and no mailbox on this case: the material an agent would normally read for you does not exist here, and that is a line to write down, not a gap to fill with invention.

Sources I actually have:
What is established, and which source establishes it:
What contradicts what, source against source:
What is absent — the questions this material does not answer:
Questions I would put to a stakeholder, if there were one:
My hypothesis on the product boundary:
Written to DISCOVERY.md: yes / not yet
What the control session challenged in the above, and what I did with it:

You should be holding: what is known, what is missing, what contradicts.

Gate 2 — write the PRD

What you do. Produce one document whose first section is the strategic framing. Answer the alignment questions rather than letting the agent choose silently — on this case you are the only one who can answer them, and you say so in the document.

Prompt to run. The PRD prompt (Gate 2), on converted/, converted/INDEX.md, DISCOVERY.md, the memory and the journal, with the template at ../templates/prd.md for the shape of each section.

The three acceptance criteria this case has to carry, because the shipped tests already state them:

after a save confirms, a reload — and a switch away from the identity and back — brings the confirmed text back;
the second identity gets neither the text in the page nor a 200 from GET /api/drafts/fictional-draft-001; the denial does not contain the text;
a failed save answers 503, keeps the edited text in the field, shows an error, offers Retry, and never shows Saved; a reload before a successful retry restores only the last confirmed text; a retry that succeeds persists.

PRD written to:
Strategic framing, in three lines:
Product boundary — in:
Product boundary — out:
Roles: the author identity / the second identity, and what each may read:
The privacy rule that decides this case:
What wins when sources disagree, here:
Functional depth — flows that must really work:
Acceptance criteria — the three above, in my own words:
Open decisions, and who would take them if this were real:
Alignment questions the agent asked me, and my answers:
Every assumption marked as an assumption: yes / not yet
What the control session said about the framing, not only the coherence:

You should be holding: what is in and what is out, agreed — here, agreed with yourself, and written down as that.

Gate 3 — prototype the end-to-end flows

What you do. Let the session take the PM role and write the design prompt from the PRD. Ask for the whole flow, not the main screen: empty, editing, saving, saved, failed with its error and Retry, and the return after reload or a switch of identity. Ask for the narrow screen and for status and error messages a screen reader announces — the shipped tests read a role="status" message and a role="alert" message, so those are behaviour, not decoration.

Prompt to run. The design prompt — long specification — with the short instruction layer, and the refinement prompt if the first output is shallow.

Missing service. There is no design system here. Copy the missing-service block and fill it. Name a reference product you will follow instead, say it is a constraint, and write down that both the prototype and the code will draw on that same thing.

Missing service: design system
(copy the block above and fill it)

Reference product followed instead:
Screens and states the prototype covers:
Narrow-screen behaviour covered: yes / not yet
Status and error messages written as real copy: yes / not yet
Who I showed it to, and what they said:
Nobody depends on this case: what closed the gate was my own judgement, and
  that is recorded in the journal as such.
What the showings changed, written to memory and journal:

You should be holding: a prototype of the whole flow, and an honest line about who recognised it.

Gate 4 — port the prototype into code

*What you do. * The port goes into the sandbox's own code. There is no starter to clone, so you do not clone one: the application is the single standard-library file already in front of you, and you keep your changes inside the shape it has. Move the working documents next to the code, under docs/: the PRD, PROJECT_MEMORY.md, PROJECT_JOURNAL.md, all three at once.

Prompt to run. The coding-agent prompt (Gate 4), plus the standing constraint carried in every coding prompt.

Missing services. Two blocks here, not one: no approved frontend starter, and no written backend conventions. Fill both before you let the agent write anything, and name what you would ask Frontend Ops and Backend and API Ops for.

Missing service: approved frontend starter
Missing service: written backend conventions
(copy the block above twice and fill both)

Working documents moved under docs/: yes / not yet
The slice I asked for first:
What I ran it with, and what I clicked:
What was off when I put the running page beside the design:
The back-and-forths it took:
What the control session found when it checked the port against the design:
What I adapted to the sandbox's existing shape, and why, in the journal:

You should be holding: a page that runs, that you can click, still failing the three checks.

Gate 5 — connect the backend

What you do. The backend on this case is the storage layer and the handler in the same file. Connecting it means making the three defects real behaviour: the save persists what was submitted, the read is scoped to the owner so the second identity is denied at the route, and the failure is no longer swallowed — 503, the edit still in the field, an error, a Retry, no Saved. Go deep on each flow before the next: the empty state, the error, the denial, the reload before a retry succeeds.

Prompt to run. The connection prompt (Gate 5), one flow at a time. Call the control session on anything that behaves oddly, and ask it to reproduce rather than fix.

Flow 1 — save and return. What I changed:
  Observed after reload:
  Observed after switching identity away and back:
Flow 2 — the second identity is denied. What I changed:
  Status returned by the direct route:
  What the body contains:
Flow 3 — the failed save. What I changed:
  Status returned:
  What stays in the field:
  What the error says, and where Retry is:
  What a reload before a successful retry restores:
  What a successful retry persists:
`python3 -m unittest -v test_acceptance.py` returned:
What I clicked as each identity, not only what the tests said:
Findings the control session sent to the main session:
Decisions to memory, changes and verifications to the journal, dated:

You should be holding: the three flows holding in depth, and the tests passing because the behaviour changed — not because a test was weakened.

Gate 6 — test, then ship

What you do. Put it in someone else's hands while you are still working, and fix what comes back. Then walk the delivery path as far as it goes here — which is local, and no further. The server binds to loopback and holds a fixture; nothing about this case is deployed, and the run ends by writing down where it stopped.

Prompt to run. The release prompt (Gate 6), as a rehearsal. It names what is in the release, what was tested and with which identities, what was verified and how, what is known to be unfinished, and which review did not take place.

Missing services. No staging and no delivery path, and no leads of the trades to give the go-ahead. Two blocks, filled before you write the release note, so the note can name them.

Missing service: a path from local to the repository to staging to production
Missing service: leads who give the go-ahead before production
(copy the block above twice and fill both)

Who else clicked it, and what they reported:
What I fixed as it came back:
Defects were handled as they appeared, so none were classified: yes / no
Checks I ran, and what they returned:
What I walked end to end myself, including the empty, error and denied states:
What is still unfinished:
Which review did not take place, and who was not there to give it:
Where this run stops: nothing leaves this machine.
Release note written to the journal, dated: yes / not yet

You should be holding: a case you can account for line by line — what you built, what you verified yourself, and which review nobody gave.

What the run leaves you with

The gate that was hardest, and why:
The prompt I had to run twice:
The moment the assistant crossed a gate I had not closed:
The services I wrote down as missing, and who I would ask on a real case:
The one thing I will do differently on a case that matters:

Text licensed CC BY 4.0. Code MIT.