Skill Claude Code

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.

There is nothing to install

The project folder you download already carries the skill, at .claude/skills/onirion/, with the core guide, the thirteen prompts and the templates inside its own references/ folder. It depends on the kit folder, on another skill and on no machine but yours. Open a Claude Code session on that folder and ask for the method in words — "Apply the Onirion method to this folder" — which works whatever the version. Typing /onirion is a shortcut where the version offers it; a session that answers that the command is unknown has not lost the skill, it just does not expose it that way.

Claude Code discovers project skills under .claude/skills/. 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. Folders that start with a dot are hidden by default: in the Finder, press Command-Shift-Period to see them.

To carry the method into another project — the repository you clone at Gate 4, or a project you started before you met this method — copy the two skill folders across:

cp -R .claude .agents /absolute/path/to/your-project/

That is the whole installation. Nothing else in the target project is touched, and an existing skill of the same name is overwritten, so look before you copy.

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, and save the PRD template beside them as prd-template.md.
4. Open a Claude Code session on the folder and ask it to apply the Onirion method, or type /onirion where that works.
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. Ask for the method there as well, the same way.

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, the design specification before it is sent, what was ported from the design, a backend flow, a backend change against the backend conventions, 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 sessions address each other. Claude Code sessions running on the same machine can list one another and send a message to one another by name, where it arrives as a turn in the target session. So the control session sends its finding to the main session itself, and the instruction in the last bracket of its prompt is the whole of the wiring: name the main session there, the way your Claude Code lists it. You tell the main session where the work stands and to ask the control session for its report and its answer back; both sessions do the carrying.

Naming the other session is the whole of the wiring. Each session carries a name, the one you see in the sidebar, and that name is its address. Put the main session's name in the last bracket of the control session's starting prompt, and its findings arrive there as turns. Nothing else is configured.

Check it once, then rely on it. Ask for a small, harmless finding and watch it arrive in the other session before you trust the channel with something that matters. Then have the main session open the evidence itself rather than act on the summary.

Both sessions stay open. A message sent to a session that has been closed goes nowhere, and nothing tells you so. If the two sessions run in different permission modes, the receiving one may hold the message until you approve it: a finding that looks lost is worth looking for in the other window first.

The fallback, when a message cannot land. Copy the finding out of the control session and paste it into the main session, unchanged, and say where it came from. That costs a paste and depends on nothing. It is what the last bracket falls back to — if it cannot, hand it to me and I will relay it unchanged — and it is a fallback, not the method.

What does not change either way: the control session states what it found and what the evidence is, the finding reaches the main session whole, and you read it and decide. What you do not do is act as a courier between two windows.

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. At Gate 3, on the design specification before it is sent. 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; and before a backend change goes to review, to check it against the backend conventions, point by point. 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.

Your own announcement is not their answer. Saying what you will do next — "I'll write the prompt now", "next I'll port the flow" — is you naming an intention, not them granting it. It is the easiest way to cross a gate without noticing: you said it, so it felt settled. You cross when they answer.

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 the PRD template for the shape — prd-template.md in the project folder when it is there, otherwise references/templates/prd.md. 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. If backend is built ahead while the design is iterated, note in the journal each need from another team that work reveals, for the human to ask for now. 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. When the backend has code but no written conventions, describe the ones it follows with the observed-conventions prompt: a draft the backend owner confirms, and you follow only what they confirm. 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. While the port runs, list with the backend-needs prompt what the backend work will need from other teams — access, permissions, keys, resources, changes that need their rights — as requests in docs/backend-requests.md, for the human to send as tickets now, before any of them blocks the work.

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. Check each change against the backend conventions, point by point, down their checklists, before it goes to review — met, with its evidence; not applicable, with why; or not checked, with why. When a review asks for something the conventions do not say, or do not say clearly, handle it like any other review comment and tell the human: the point goes to the backend owner, who decides whether a convention is added or changed and writes it; you never edit the conventions. Before each flow, re-read docs/backend-requests.md. A need from another team that nobody has asked for yet goes in at once as a request — tell the human. If a flow waits on a request nobody has answered yet, stop and say so: the human moves you to a flow nothing holds up, and you never work around the missing access. 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. What they mark as not used here, on purpose, you do not add; what they say is handled elsewhere, you do not rebuild here.

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, journal and PRD

Keep all three current, and say at the end of each piece of work whether you updated them or why no update was needed. The PRD describes the product as it now is: once it exists, a change that makes one of its sections wrong is a change that edits that section, in the same pass as the code.

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.

Learning does not stop when the code starts

The research runs across every gate, not only Gate 1. When something you read, or something the human reports back from a user, says the product should change, say so at whatever gate the work is at — do not park it. Prefer the finding that corrects what exists to the finding that adds to it, and write what it changed into the PRD and the memory. Ask before reading any channel or mailbox, every time, and keep personal details out of what you write down.

If you are the control session

You read, check and challenge the main session's work against the material. At Gate 3 that includes the design specification before it is sent: every demand traced to the PRD, nothing added the PRD does not support, nothing it requires left out. At Gate 5 it includes a backend change before it goes to review, checked against the backend conventions point by point. 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.
• Never sign in to a platform or use the human's credentials to find out what access they have. Ask.

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.