Bring the Team, Not the Prompt

Part 1 open-sourced our scaffold — the disciplined folder shape we start every agent-built project from. Inside it is a small crew of named agents. This post is about the part people ask about most: how that same crew shows up, unchanged, whether you open the project in Claude Code, Codex, Cursor, Gemini, or Devin.

Every tool wants its own rulebook

There's a snag waiting for anyone who uses more than one AI coding tool, and you hit it fast.

Each tool reads its instructions from a different place. Claude Code looks in a CLAUDE.md file and a .claude/ folder. Gemini wants a GEMINI.md. Cursor keeps optional rules in .cursor/rules/. Codex, Devin, and a growing list of others read AGENTS.md. Some of these overlap — but describe your "reviewer" role once and you've told one corner of your toolkit, not the rest of it.

So the same role ends up written down in four places. You improve the wording in one of them. The other three keep the old wording. Nobody meant for them to disagree, but now they do — they've drifted.

That would be a filing annoyance if a person were reading. It's a live hazard when an agent is. The agent opens whichever copy its tool happens to read, takes it as gospel, and acts — fast, across a dozen files, sure of itself. The rule it followed was the stale one, and you find out in the diff.

One brain, not five copies

The scaffold's answer is to stop keeping copies. One folder is declared the single source of truth: .claude/. That's the canonical brain — the roles, the doctrine, the step-by-step procedures, all in one place. When you want to change how an agent behaves, you change it there, once.

Every other tool's file stops being a copy and becomes a thin adapter: a pointer that says the real rules live over there, plus a line or two of local wiring — never the rules themselves. AGENTS.md, CLAUDE.md, GEMINI.md, the Cursor rules: each one points back to the same brain. Edit the brain, and every tool is already reading the new version.

And you don't have to trust that it stayed in sync. A script ships in the repo — scripts/check_adapters.py — and it runs in the project's CI on every push. It checks that each named agent still points at a real role, that every pointer resolves to a file that exists, that each tool's list of agents names the same crew, and that no adapter has quietly fattened up with a pasted-in copy of the rules. Any one of those failing fails the build. The consistency is a test that runs, not a promise you make.

Class, persona, and a name

Now the crew itself. It's built from two layers, and the order between them is the whole trick.

A class is the job. It's a binding contract — the mission, what's in scope, the lines it will not cross, and what has to be true before the work counts as done. The class is the part with teeth.

A persona is that class wearing a name. It adds a voice and a few personal instructions, and nothing more — it can't soften a verdict, skip the evidence, or quietly widen its own scope. One rule settles every conflict: class always wins. ARIA and "the design lead" can never disagree, because ARIA is the design lead with a name on. Each agent also answers to its class and an alias or two, so you can call it however comes to mind; every name resolves to the same contract.

The scaffold ships three of these, worked all the way through.

JANUS runs the cpto class. JANUS turns a fuzzy idea into requirements you can actually test, reviews the work when it comes back, and holds the release gate — the one who says ship or don't ship.

ARIA runs ux-design. ARIA owns how the thing looks: the direction, the design kit the front end is built from, accessibility, and the final call on whether the result matches the drawing.

CORE runs dev. CORE builds the feature across the stack — checking for something to reuse before writing anything new, writing tests, and verifying its own work before handing it back.

They pass work to each other by what the work needs, not by who feels like doing it. JANUS turns the idea into testable requirements. CORE implements them, with tests. JANUS reviews the result and decides whether it ships. ARIA owns the design; CORE builds it as drawn. Every handoff is a named step, not a vibe.

The same team, wherever you open the project

Here's the part that pays for the discipline.

That same crew — same names, same contracts, same boundaries — shows up in every one of those tools. You don't rewrite a prompt when you switch apps. You call the agent, and it loads the same contract wherever you are:

Tool	Call JANUS	Call ARIA
Claude Code	/janus	/aria (also /uiux, /aria-uiux)
Codex	act as JANUS (or $janus)	act as ARIA (or $aria)
Gemini CLI	/janus	/aria (or /uiux)
Devin	@skills:janus (or auto)	@skills:aria
Cursor	act as JANUS …	act as ARIA …

If the embed doesn't show in your reader: the same interactive, standalone — same crew, same contract.

We've run this for real, not just drawn it. JANUS scoped and planned work inside Devin; ARIA reviewed the same design in Codex and again in Claude Code — the same role, the same rulebook, no rewrite in between.

One honest caveat: these tools run on different underlying models, so the exact words an agent chooses will shift from one to the next. What doesn't shift is the job — the same mission, the same boundaries, the same bar for done. You're carrying a governed team between tools, not babysitting a brittle prompt you re-tune for each one.

And because AGENTS.md is an open standard rather than one vendor's format, the crew reaches past those five. Any tool that reads it — Windsurf, Amp, Aider, and Zed among them — picks up the same team with no new adapter to maintain.

The scaffold is open source

Everything you've just read is public, and has been since Part 1. The scaffold — the canonical brain, the named crew, the adapters that carry it into each tool, the test that keeps the copies honest — lives at github.com/SynaptixLabs/scaffold, MIT-licensed. Clone it and the team comes with the repo: open the project in Claude Code, Codex, Cursor, Gemini, or Devin, and the same crew answers on the first try. Star it if that's how you keep bookmarks; issues and pull requests are read by the same people who wrote the roles.

What's next

So the team travels. The rules travel with it, and a test keeps them honest.

In Part 3 we stop describing and start building. We hand this crew a real, small product and let it plan, build, and judge the thing end to end — so you can watch the whole loop run instead of taking our word for it. Swap the agent, keep the project; next, we build in the open.

---

Previously: Part 1 — Your Repo Is the Prompt Now — we open-sourced the scaffold this crew lives in.

Up next, this week: Part 3 — Speed Was Never the Hard Part — what the crew does once it's in the repo: run the product itself.

---

Part 2 of 3. Grounded in the public github.com/SynaptixLabs/scaffold repo (v1.0, MIT).