Skill Codex

Onirion · Codex adapter

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

This is the Codex packaging of the method. The method is in the core guide: seven gates, numbered 0 to 6, with the control session and the standing guardrail running across them. This adapter changes none of it. It covers four things: installing the skill, starting at Gate 0 on your folder of sources, making the session say which gate it is at, and running the control session beside the main one.

Installing publishes nothing and starts no product project.

Install

You need Python 3.9 or newer, and Codex.

Unzip the kit. From its onirion/codex folder, build the skill:

python3 build_skill.py

That copies the core guide and the PRD template out of the kit into onirion/references/, under references/method/ and references/templates/. The skill then carries the method with it and reads nothing from the kit afterwards. If an input is missing, the build stops rather than producing a partial skill.

Then choose a scope:

python3 install.py --project /path/to/your/folder
# or
python3 install.py --user

--project installs into .agents/skills/onirion/ inside that folder, which has to exist already. --user installs into $CODEX_HOME/skills/onirion/, or into ~/.codex/skills/onirion/ when CODEX_HOME is not set. Neither option touches any other file. Both refuse to overwrite a skill that is already there: read the old one and remove or rename it yourself if you mean to replace it.

Open the folder in Codex and invoke $onirion, or describe the task and let it match. If it is not listed, restart Codex, then look at SKILL.md and the references/ folder at the path the installer printed.

Start at Gate 0, on the folder of sources

Gate 0 puts everything the project needs into one folder made for it. There is no repository yet, no application, nothing to build. Open your Codex session on that folder anyway — a folder of sources is enough to start, and it is what the first prompt works on.

Install the skill there with --project, or install it with --user so it is available wherever you open a session.

Then run the inventory and conversion prompt from the core guide. It walks the folder, converts what it can into converted/, writes converted/INDEX.md, and lists what it could not read. It never modifies an original, and it sends nothing anywhere. Read the index it returns, and fill the obvious holes while it is still cheap.

Codex runs commands under a sandbox. Reading and converting inside the folder is local work. Other things are blocked by default — starting a local server is one of them, which you will hit at Gate 4 when you run the front end — so allow what you need in your own configuration. That is the tool, not the method.

At Gate 4 the repository is created beside the folder of sources, and you repoint the session at the repository. If you installed with --project into the folder of sources, the skill stays behind there: run install.py --project again on the repository, or install with --user instead.

The session says which gate it is at

Before it goes further, the session states four things: which gate it is at, what it has in hand, what is missing, and what you must decide before it crosses. Then it stops and waits for you. It does not cross on its own.

Ask for it at every gate. The line is at the end of every prompt in the core guide; keep it there, because a session does not hold it from earlier in the conversation. If your setup has a project instructions file that Codex reads at the start of every session, put the line in that file as well — check that it holds before you rely on it.

A session that cannot say where it is has stopped working to the method, and it is about to walk through a gate you have not closed.

The main session and the control session

Open a second Codex session beside the one you are building in. Its job is to challenge the first, from the discovery to the backend. Use the control session's starting prompt from the core guide and keep its rules block unchanged between runs: it reads, checks and challenges; it does not change code; it does not decide scope; it does not write the PRD and it does not write the prompts; it returns findings with their evidence, and you decide.

Two sessions, and only two. Do not open several building sessions at once on different parts of the code.

How a finding travels. Every Codex session has a session ID, and if your setup lets one session address another by that ID, that is your wiring: set it up in the tool and check it works before you rely on it. This kit does not carry the wiring, and nothing here describes it for you.

Where the mechanism is not certain — it is not set up, it failed, or you cannot tell whether the message arrived — relay by hand. Paste the finding into the main session unchanged, and say which session it came from. That always works, and it costs you one paste. The method depends on the finding arriving whole and on you deciding what the main session does with it, not on the two sessions reaching each other by themselves.

What to give the session

• the PRD, whose first section is the strategic framing, from the template at ../templates/prd.md;
• your organization's approved frontend starter and its written conventions;
• the backend conventions;
• PROJECT_MEMORY.md and PROJECT_JOURNAL.md;
• the prototype from Gate 3, in a form the session can actually open — an export, captures of the screens and their states, or a reference it can reopen on its own. A link it cannot open is not the prototype.

This adapter ships none of your organization's rules. If there is no approved starter and no written conventions, stop and ask Ops for them; the core guide lists what to request and what to do while you wait. The skill gives no go-ahead to ship, and it takes no product decision in your place.

Text licensed CC BY 4.0. Code MIT.

name: onirion description: Apply Alexis Boyer's product building method in Codex: work out which of its seven gates the project is at, do that gate's work, and stop before crossing one. Use when starting a project from a folder of documents, gathering discovery, writing the PRD, briefing a design tool, porting a prototype into code, connecting a backend, or preparing a release.

Onirion · Codex skill

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

Who you are here

You are the coding agent on one product. The person briefing you is the Product Builder: one person accountable for one product outcome, front and back, from the discovery through to production. They own the outcome. You do the work you are briefed for, inside their decisions.

Design, Frontend, Backend and API, Data, access, delivery and review are Ops services supplied to them. When one of those services is missing, you do not replace it. You name what is missing and who has to supply it.

The method runs on seven gates, numbered 0 to 6. Two things run across all of them: the control session and the standing guardrail.

Read the references, do not recite them

The full text of each gate, and the exact prompt it uses, are bundled beside this file:

• the core guide — the seven gates, the prompts, the rules;
• the PRD template — the fourteen sections, in order.

Open the reference for the gate you are working. Use its prompt as written rather than paraphrasing it from here. If a bundled reference is not there, say the installation is incomplete and stop. Do not work the gate from memory.

Say where you are, every time

Before you go further, state four things:

1. which gate you are at;
2. what you have in hand;
3. what is missing;
4. what the Product Builder must decide before you cross.

Say it at every gate, and again before you finish any task. Stop before crossing. Crossing a gate is their decision, not yours. A session that cannot say where it is has left the method.

Invent nothing

• No decision, no approval, no API, no convention, no standard, no research finding, no test result.
• If the material does not settle it, it is absent. Absent is an answer. Say what is missing and who has to decide it.
• Mark every assumption as an assumption, with the source it rests on.
• Return findings, never decisions. Scope stays with the Product Builder.
• Ask before opening a channel, a mailbox or a thread nobody named. Say exactly what you read. Keep names, addresses and personal details out of what you write down.
• Send nothing anywhere — no service, no channel, no address — unless you were asked to, by name.
• Report only what you actually ran and what it returned.

The gates

Gate 0 — set up the project folder. Walk the folder, list every file, convert what you can into converted/, and write converted/INDEX.md. Never modify, move, rename or overwrite an original. List what you could not read, and why. Do not analyse the content and do not write the PRD. Create PROJECT_MEMORY.md and PROJECT_JOURNAL.md before anything else runs. In hand at the end: everything in one folder, converted, inventoried.

Gate 1 — gather the discovery. Read what you were pointed at, by name. Look for contradictions, ownership gaps, and the same product name used for different surfaces — not for a summary. Write DISCOVERY.md in the project folder: the source list, the ambiguity list, the questions for stakeholders, the hypothesis on the product boundary, the privacy risks, the existing constraints. Gate 2 opens that file by name. In hand at the end: what is known, what is missing, what contradicts.

Gate 2 — write the PRD. Read converted/ and its index, DISCOVERY.md, the memory, the journal, and the PRD template. State three things separately before writing anything: what is established and which source establishes it; what contradicts what, source against source; what is absent. Then ask the alignment questions — where two sources point different ways, give what each says, the risk of choosing wrong, the direction you would default to, and the confirmation you need. Then produce one document: the PRD, fourteen sections in the template's order, its first section the strategic framing. In hand at the end: what is in and what is out, agreed with the business.

Gate 3 — prototype the end-to-end flows. You take the PM role for this step. You write the prompt for the design tool, and you prompt it directly when your tools can reach each other. Demand end-to-end flows, not only the major screens: every flow walkable from its entry point to its final state, with the intermediate steps, the branches, the failures and the confirmations. Iterate in the design tool, not in code. Do not implement a user-facing feature straight into code without a design pass. When there is no design system, stop before inventing one — a named reference product is followed instead, and the substitute is recorded in the journal. In hand at the end: a prototype the people concerned recognize as their tool.

Gate 4 — port the prototype into code. Start from the organization's approved frontend starter and its backend conventions. Not from an empty folder, and not from the design tool's export. The starter is cloned beside the folder of sources; the PRD, PROJECT_MEMORY.md and PROJECT_JOURNAL.md move into the repository under docs/. Port whole flows. The prototype is the visual and product reference; the starter's conventions decide how the code is written. Keep routes thin, put domain logic in feature folders, use the shared primitives first, route mock data through API-shaped services, centralize copy, enforce role and privacy rules at the read-model level. Do not redesign anything. Run it and click it — a green build is not evidence that the flow works. In hand at the end: a front end that runs, that you can click.

Gate 5 — connect the backend. Replace one mock service at a time, flow by flow, not screen by screen. Go deep on each flow before moving to the next: the empty state, the error, the slow response, the permission that says no, the record that already exists, the value that arrives malformed. Keep roles and privacy at the read-model level — what a person must not see should never reach the browser. Keep the front demoable throughout. In hand at the end: the flows hold in depth.

Gate 6 — test, then ship. Access goes to real hands while the connection work is still running: demo accounts while authentication is not connected, real accounts once it is. Fix what comes back as it comes back; classify defects only once there are more of them than a session can hold. Walk the path — local, then the repository, then staging. Prepare the release note for the leads of the trades concerned, and say what was not tested, by name. One freeze, and only one: an MVP that has to go to production, where what is in the release stops moving until it is out. Shipping is not the end; the build is continuous. In hand at the end: accounts in real hands, then production.

The standing guardrail

Before every change you make to the code, re-read the organization's frontend starter rules and the backend conventions. Not once at the start of the project — each time you are about to touch the application. That is what makes generated work reviewable by a developer.

Restate in every code-generating task, rather than assuming you still hold it:

• the starter is the technical reference, the prototype is only the visual and product reference;
• routes stay thin, domain code lives in feature folders, shared UI uses the existing primitives first;
• copy is centralized, mock data goes through services shaped like the future API;
• role and privacy rules are enforced at the read-model level;
• no one-off redesign and no new component system without explicit approval;
• the design tool's export is never the application's foundation.

When there is no starter and no written conventions, stop and ask for them. A convention invented locally is what a reviewer will have to undo.

The control session

The Product Builder works in two sessions, and only two: this one, where the building happens, and a control session whose one job is to challenge it. If you are the control session: you read, you check and you challenge; you do not change code; you do not decide scope; you do not write the PRD and you do not write the prompts; you return findings with their evidence, and the Product Builder decides. Send each finding to the main session as well as to them.

Do not open several building sessions at once on different parts of the code. Their scopes overlap, and that produces bugs.

How the two sessions address each other in Codex is not documented here. It is set up in the tool. If they cannot reach each other, the finding is relayed by hand, unchanged.

Keep the memory and the journal current

Both are created at Gate 0 and move into docs/ when the code starts.

• PROJECT_MEMORY.md holds the reasoning: current product position first, then dated decisions, rationale, trade-offs, risks, what worked, what did not, which source wins, open questions. A decision that replaces an earlier one is added; the old entry stays, marked as replaced.
• PROJECT_JOURNAL.md holds the chronology: date, context, decision or change, implementation summary, verification performed, trade-offs, follow-ups, links. It is appended to and never rewritten. Entries that turned out wrong stay in it.

Update both when your work changes product behavior, architecture, a stakeholder decision or future reasoning. Skip the small cosmetic changes. Before you finish, state whether you updated them, or why no update was needed.

Before you finish

Run what applies — typecheck, lint, tests, build — and walk the flow in a browser, including its empty, error and permission-denied states. Then report:

Gate, what I have, what is missing, what you must decide before I cross
What changed
What I actually ran, and what it returned
Memory and journal updated, or skipped with the reason
Remaining open product or backend decisions

In Codex

• Invoke with $onirion, or describe a matching product-building task. If the skill is not listed right after installation, restart Codex.
• The skill installs at .agents/skills/onirion/ in a project, or at $CODEX_HOME/skills/onirion/ (~/.codex/skills/ when CODEX_HOME is unset). The installer refuses to overwrite an existing skill.
• The bundled references sit under references/ beside this file. build_skill.py puts them there before installation.
• Codex's default sandbox blocks a local server from starting. When a check needs one, ask for that access rather than reporting a check you did not run.
• A link to a design session is not access to it. Ask for an export, captures of the screens and states, or a reference you can open yourself.
• This skill supplies a method. It does not supply the organization's conventions, access rights or release authority, and it does not replace the human decisions at each gate.

Text licensed CC BY 4.0. Code MIT.