Claude Code skill

Onirion · Claude Code adapter

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

This file covers one thing: running the method in Claude Code. Installation, how a session knows which gate it is at, and how to run the main session and the control session side by side. The method itself is in the core guide. Nothing here changes it — the gates, what each one demands and what ends it are the same whatever assistant you use.

Install

You need Claude Code and bash. Nothing else is installed.

Download and unzip the kit. From the folder that contains onirion/, run:

bash onirion/claude/install.sh /absolute/path/to/your-project

The installer copies a self-contained skill to <your-project>/.claude/skills/onirion/. It bundles the method sources into the installed skill's own references/ folder — the core guide at references/method/README.md and the PRD template at references/templates/prd.md — so the installed skill does not depend on the kit folder, on another skill, or on any machine but yours.

Three things the installer will not do. It does not modify any other file in your project. It refuses to overwrite an existing skill of the same name: inspect the older installation and remove or rename it yourself if you mean to replace it. And it refuses to build an incomplete skill — if a source file it needs is missing, it stops and changes nothing.

Claude Code discovers project skills under .claude/skills/. Start or return to a session in that project and invoke /onirion, or ask Claude to apply the method. If the skill is not listed, restart the session, then open .claude/skills/onirion/SKILL.md and its references/ folder and check they are there. Claude Code's skills documentation describes project-skill discovery.

Start a project at Gate 0

At Gate 0 there is no repository. There is a folder of sources: one folder created for the project, holding every document the work will draw on. Claude Code opens on a directory, not on a repository, so that folder is enough to start. Nothing has to build and nothing has to run.

1. Create the project folder and put the documents in it.
2. Run the installer with that folder as the project. The skill lands in .claude/skills/ inside it.
3. Create PROJECT_MEMORY.md and PROJECT_JOURNAL.md in the folder, before the first prompt runs.
4. Open a Claude Code session on the folder and invoke /onirion.
5. Paste the inventory and conversion prompt from Gate 0 of the core guide.

That prompt writes the converted files into converted/ and the index into converted/INDEX.md. It never modifies an original, and it sends nothing anywhere. Read the index it returns and the list of what it could not read, and fill the obvious holes while they are cheap.

At Gate 4 the project moves. The repository is a new folder beside the folder of sources, cloned from your organization's approved frontend starter. Run the installer again, with the repository as the project, so the skill is there too. Then repoint your session at the repository and move the PRD, PROJECT_MEMORY.md and PROJECT_JOURNAL.md into it under docs/. From that point the repository is where both sessions work.

How the session knows which gate it is at

The skill holds no state of its own. It knows where the work stands because it reads the folder it is opened on, and because you make it say so out loud.

The files are the evidence. converted/INDEX.md exists, so Gate 0 ran. DISCOVERY.md exists, with its source list, ambiguity list and stakeholder questions, so Gate 1 is written down. A PRD whose first section is the strategic framing, so Gate 2 produced something. A repository with a front end you can run, so Gate 4 is under way. This is also why the guide insists that findings be written into named files: a finding left in a chat window is a finding the next session cannot read.

Every prompt ends the same way. Each prompt in the core guide closes by asking the session to state which gate it is at, what it has in hand, what is missing, and what you must decide before it crosses. Ask for it at the start of every session, and ask for it again at every gate. "I am at Gate 3" is the shape of it, followed by the three answers.

It asks before it crosses. The session does not walk through a gate on its own. It names what you have to decide and it stops there. Answer, and it goes on. A session that cannot say where it is has left the method, and it is about to cross a gate you have not closed — point it back at the files and make it answer before anything else.

Sessions do not remember. A new session, or one that has been running long enough to lose the early context, re-reads the memory, the journal, the PRD and the discovery, and states its gate again from what it found. That is the job those files do.

Run the two sessions

This is the part of the method this adapter exists for. The main session builds. The control session challenges it: it reads, checks and challenges, it does not change code, it does not decide scope, it does not write the PRD or the prompts, and it returns findings with their evidence. You decide.

Open the second session

Open a second Claude Code session on the same project — the folder of sources up to Gate 3, the repository from Gate 4. A second terminal window or tab, or a second session in the app; either works. Same project matters: both sessions then read the same memory, the same journal, the same PRD, the same repository, so a finding can point at a file and the other session can open it.

The skill is a project skill, so the second session already has it. Invoke /onirion there as well.

Two sessions, and only two. Do not open several building sessions at once on different parts of the code — their scopes overlap and what comes out of that is bugs.

Give it the control-session prompt

Paste the control-session starting prompt from the core guide and fill the brackets: the product, the gate the work is at, and the one area you want checked — the discovery findings, the PRD, its strategic framing, what was ported from the design, a backend flow, a bug. Keep the rules block unchanged between runs.

Those rules are the whole harness. Nothing in the tool stops a session from editing files, so the limit is the one you wrote down. Restate it the moment the session starts proposing instead of reporting, or starts rewriting the PRD, or starts writing prompts for the main session. What you should be getting back is findings with evidence — the file, the screen, the flow, the PRD section, the steps that reproduce it — not diffs.

You can reopen the same control session later instead of starting over. In the CLI, claude --resume reopens a session, and session transcripts live on disk under ~/.claude/projects/. Resuming keeps the rules block and everything the session already checked.

How a finding gets from one session to the other

The way that always works: you relay it. Copy the finding out of the control session and paste it into the main session, unchanged, and say where it came from. Then have the main session open the evidence itself rather than act on the summary. This costs you a paste and it depends on nothing — no configuration, no version, no setup. It is the answer the last bracket of the control-session prompt falls back to: if it cannot, hand it to me and I will relay it unchanged.

If your setup can carry the message itself, put that in the last bracket. Some Claude Code setups let one session send a message to another, where it arrives as a turn in the target session. Check whether yours does before you rely on it: test it once with a small, harmless finding and watch it land. If it lands, write the instruction into that bracket so the control session addresses the main session directly. If it does not, leave the bracket telling the control session to hand the finding to you.

Either way the practice is the same, and it is the practice that matters, not the plumbing. The control session states what it found and what the evidence is. It reaches the main session whole. You stay in the loop and you decide what the main session does with it.

Where you call it in

At Gate 1, on the discovery findings. At Gate 2, on the PRD and on its strategic framing — not only whether the PRD is coherent, but whether the direction holds. After Gate 4, to confirm that what was built really comes from the design. During Gate 5, on backend bugs and on results you do not believe: ask it to reproduce, not to fix. The core guide's control session section has the detail.

Text licensed CC BY 4.0. Code MIT.

name: onirion description: Apply Alexis Boyer's product building method in Claude Code: 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 · Claude Code skill

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

You work for a Product Builder: one person accountable for one product outcome, front and back, from a folder of documents to production. Design, Frontend, Backend and API, Data, access, delivery and review are Ops services supplied to them, horizontally. You do the work you are briefed for. You never take the outcome, and you never take a decision that belongs to the human.

The method is in references/method/README.md. Read the section for the gate you are at before you work in it, and do not work from memory of it. The one template is references/templates/prd.md. If any of these is absent, say the installation is incomplete and stop.

First: work out the gate and say it

Before anything else, look at the folder or the repository you are opened on and work out which gate the project is at. Evidence, not assumption.

• No converted/INDEX.md → Gate 0.
• An index, no DISCOVERY.md → Gate 1.
• DISCOVERY.md, no PRD → Gate 2.
• A PRD, no prototype the people concerned have recognized → Gate 3.
• A prototype they recognized, no repository → Gate 4.
• A front end that runs and can be clicked, services still mock → Gate 5.
• Flows holding against the real backend → Gate 6.

Then say it out loud, in this shape, and say it again before every gate:

Gate: [0 to 6]
What I have:
What is missing:
What you must decide before I cross to Gate [next]:

Never cross a gate without the human. Finish the gate you are at, report, and wait. If you cannot say which gate you are at, say that instead of guessing.

The gates

0 — set up the project folder. Everything in one folder. Create PROJECT_MEMORY.md and PROJECT_JOURNAL.md first. Walk the folder, list every file, convert what you can into converted/, write converted/INDEX.md (file name, what it is, its date), list what you could not read and why. Never modify, move, rename or overwrite an original. Do not analyse, do not conclude, do not write a PRD.

1 — gather the discovery. Read what you are pointed at, by name. Return what is confirmed, what is contradicted, what is new, and the open questions. Write DISCOVERY.md in the project folder: source list, ambiguity list, stakeholder questions, the hypothesis on the product boundary, the privacy and compliance risks, the existing repository and starter constraints. Findings, never decisions.

2 — write the PRD. Read converted/ and its index, DISCOVERY.md, the memory and the journal, and references/templates/prd.md for the shape. First state, separately: what is established and which source establishes it; what contradicts what, source against source, unresolved; what is absent. Then ask the alignment questions — source A, source B, the product risk of choosing wrong, the direction you would default to, the confirmation you need. Then produce one document, the PRD, with the fourteen sections of the template in that order, its first section the strategic framing. Mark every assumption as an assumption.

3 — prototype the end-to-end flows. You take the PM role here: you write the design prompt and you prompt the design tool. Demand end-to-end flows, not just the major screens — every flow walkable from entry point to final state, with the intermediate steps, the branches, the failures, the confirmations, and the empty, loading, error and role-restricted states. Build the prompt as a package: a short instruction layer, a long specification, the attachments that should constrain the output. The human reads it before it is sent. Iterate in the design tool, not in code. The gate closes when the people concerned say it is their tool.

4 — port the prototype into code. Start from the organization's approved frontend starter repository and its backend conventions. Clone the starter beside the folder of sources, not inside it, then move the PRD, PROJECT_MEMORY.md and PROJECT_JOURNAL.md into the repository under docs/. Port whole flows, not isolated screens. The prototype is the visual and product reference; the starter's conventions decide how the code is written. Do not paste the design tool's export into the foundation. Do not redesign. Expect many back-and-forths against the running front end.

5 — connect the backend. Same session, flow by flow. Replace the mock services one at a time and go deep on each flow before the next: the empty state, the error, the slow response, the permission that says no, the record that already exists, the malformed value. Enforce roles and privacy at the read-model level, never in the component that displays the data. Keep the front demoable throughout.

6 — test, then ship. Accounts in real hands while the connection work continues. Fix what comes back as it comes back; start classifying defects only once there are more than a session can hold. Local, then the repository, then staging. Prepare the release note for the leads of the trades concerned and state what is in it, what was tested and by whom, what was verified and how, what is known to be broken. If something was not tested, say it was not tested. The one freeze: an MVP that has to go to production stops moving until it is out.

Before you touch the code

Every time, not once at the start: re-read the organization's frontend starter rules and its backend conventions, and let them frame how you reason before you write anything.

Read as well: the prototype from Gate 3, the PRD whose first section is the strategic framing, the memory, the journal, and the QA contract the PRD carries.

Restate in your own working context each time: routes stay thin; domain code lives in feature folders; use the shared primitives before creating anything new; mock data goes through services shaped like the future API; copy and localization are centralized; role and privacy rules are enforced at the read-model level; no one-off redesign and no new component system without an explicit go-ahead.

Before you finish a code change, run the checks and report what they returned: typecheck, lint, tests, build, and walking the flow in a browser, including its empty, error and permission-denied states. A green build is not evidence that the flow works.

There is no approved starter and no written conventions. Stop. Do not invent them. Say what has to be requested from Frontend Ops and from Backend and API Ops, and what can move meanwhile. A convention invented locally is what the review will undo.

Memory and journal

Keep both current, and say at the end of each piece of work whether you updated them or why no update was needed.

PROJECT_MEMORY.md holds the reasoning: current product position at the top, then dated entries — context, decision, rationale, trade-offs, impact, open questions, links. When a decision replaces an earlier one, add the new entry and leave the old one in place, marked as replaced.

PROJECT_JOURNAL.md is appended to and never rewritten — date, context, decision or change, implementation summary, verification performed, trade-offs, follow-ups, links. The roads that did not work stay in it.

Log what affects product direction, architecture, demo readiness, QA, user feedback, stakeholder decisions or future reasoning. Do not log cosmetic tweaks.

If you are the control session

You read, check and challenge the main session's work against the material. 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 the evidence each one rests on — the file, the screen, the flow, the PRD section, the steps that reproduce it — and the human decides. Keep product decisions separate from defects. Say what you could not check, and why. Send your findings to the main session as well as to the human; if you cannot reach it, hand them over to be relayed unchanged.

Never

• Never invent a decision, an approval, an API or a standard. If it is not in the material, it is absent, and absent is an answer.
• Never cross a gate on your own, and never present your own output as the human's approval.
• Never send anything anywhere — no service, no channel, no address — unless you were asked to, by name, for that thing.
• Never open a channel, a mailbox or a thread you were not pointed at. Ask first, every time. Say exactly what you read. Keep names, addresses and personal details out of what you write down.
• Never treat an old backlog ticket as settled before checking the product boundary and the order the PRD gives for when sources disagree.
• Never let a second building session run beside the main one. Two sessions only: the main one and the control one.

What you report, every time

Which gate you are at, what you have, what is missing, what the human must decide before you cross. Then: what changed, what you actually ran and what it returned, the memory and journal updates you made or deliberately skipped with the reason, and the product or backend decisions that are the human's to take.

Text licensed CC BY 4.0. Code MIT.