How to share AI agent setups across projects

Your first project with an AI coding agent gets a rules file, a few skills and a couple of MCP servers, tuned over weeks until the agent behaves. Then a second project starts, and someone copies the folder across. Then a third. Six months later the three copies disagree about how to write a commit message, one of them still has the review skill with the bug you fixed in spring, and nobody can say which version is the good one.

This article is a practical method for sharing agent configuration between projects and teams without that drift: what a shareable setup is, how to publish one, how to start from someone else's, and how to take only the parts you need. We'll use one example throughout: a team with a web shop project whose setup works well, and a new admin console project that should start from it.

Why agent configuration drifts between projects

Copying a folder is the natural way to reuse agent configuration, and it has three built-in problems:

A copy has no origin. Once the files are in the new repository, nothing records where they came from or which state of the original they match.
Improvements stay local. The fix made in the admin console never reaches the web shop, and the other way round. Each project keeps the half it happened to find.
Copying is all or nothing. You wanted the review skill and the commit rules. You also got a deployment skill for infrastructure the new project does not have, and rules about a framework it does not use.

The result is that every project ends up with its own dialect, and the knowledge of how to work with agents, which is expensive to build, does not travel.

What a shareable setup contains

Before sharing anything, name the parts. Agent configuration is usually five kinds of thing:

Rules: the standing instructions the agent reads in every session.
Skills: reusable procedures the agent runs on request, often with supporting files.
Agents: specialised subagents with their own instructions, such as a reviewer or a planner.
MCP servers: the connections to external tools and data.
Files: everything the rest refers to, such as templates and settings.

Treat the five together as one unit, a setup. The parts depend on each other: a skill calls a subagent, a rule names a skill, a subagent expects an MCP server. Sharing one file out of that web is how you get a skill that fails in its second step.

Not everything in a working setup should leave the project. Go through it once with three questions:

Is it general? "Run the tests before you report" is general. "The payments module must not import from the legacy cart" is about the web shop. Leave project facts in the project.
Is it secret? MCP server configuration is the usual place for tokens and keys. Replace every literal value with a reference to an environment variable before the setup goes anywhere.
Is it yours to share? Internal host names, customer names and paths in rules and skill texts are easy to overlook. Read every text as an outsider would.

A good shared setup is smaller than the one it came from. For the web shop, that means the commit and review rules, the review skill, the planner subagent and the issue tracker's MCP server with its token turned into a placeholder. The shop's own architecture rules stay behind.

Step 2: Publish it where others can find it

A setup shared as an attachment in a chat is one more copy without an origin. Publish it to a place with three properties:

One named entry. People refer to "the web shop setup", not to a file somebody sent in March.
Versions. Publishing again creates the next version of the same entry, with a note on what changed.
Readable before use. Anyone can open the rules, skills and subagents and read them before they take anything.

Be clear about who can see what you publish. A setup describes how your team works, and a published one is read by people outside the project. Review the content as a whole before every publication, not only before the first.

Step 3: Start a project from someone else's setup

The admin console is new, so it can take the web shop setup whole: add the published entry as a new setup of the project. That gives it a full copy to work with from day one.

Two things to do right after:

Make the settings yours. A published setup carries its publisher's choices: branch names, test commands, review depth. Go through them before the first run.
Add the project's own rules. The shared setup holds what is general. The admin console's architecture and conventions go on top.

Adding a setup as a new one has a second benefit that the next steps do not have: the copy can remember which entry and which version it came from. Step 6 comes back to this.

Step 4: Merge only the parts you need

Most projects are not new. They already have a setup with months of tuning in it, and what they want from another team is one skill and two rules. Replacing the whole setup would throw the tuning away. Merge instead.

A safe merge has four properties:

A preview first. Before anything is written, you see what the merge would do, item by item.
A choice per item. New items can be deselected. Where both sides have an item with the same name, you choose between keeping yours and replacing it, and keeping yours is the default.
Nothing is deleted. A merge adds and, where you say so, replaces. It never removes what only your setup has.
All or nothing. If any part fails, the setup is left as it was.

Suppose a third project, a mobile API, wants only the review skill from the web shop setup. In the preview it deselects everything else. The review skill needs the planner subagent, so that stays selected. Both setups have a "commit-rules" item, and the mobile team keeps its own. The result is two new items and no surprises.

Compare before you replace. A conflict means two teams solved the same problem differently, and the other version is not automatically the better one.

Step 5: Reuse your own setups across projects

Not all sharing needs a publication. If the same person or team works in both projects, the shorter route is to pull content straight from one setup into another: from another setup of the same project, or from a setup of another project you are a member of.

A pull should work like a merge: the same preview, the same choice per item, nothing deleted. One detail deserves care. Secret values that were typed straight into a tool connection should not travel between projects, so expect to fill them in again when the source is another project.

Use this for the private half of your configuration: the things that are too specific to publish but still shared by two of your own projects.

Step 6: Know which copies stay connected

This is the step teams skip, and it decides whether sharing keeps working after the first month. Every way of taking a setup produces a copy. The question is whether the copy knows where it came from:

Added as a new setup: connected. The copy remembers its entry and version, so it can tell you when a newer version exists and take it through the same preview.
Merged: not connected. A merge is a one-off copy and the setup does not hear about later versions. To take them, merge again.
Pulled: not connected. A pull is a one-off too and nothing tells you when the source changes.

Neither kind is wrong. Connected copies suit a setup you follow as it is. One-off copies suit parts you intend to change. What goes wrong is assuming a merged skill will update itself. Write down which of your setups are connected and which items came from where.

Common mistakes

Copying folders between repositories. It works once and drifts from then on.
Sharing with secrets inside. Check MCP server configuration first, then every text.
Publishing project facts as general rules. The next team inherits constraints that make no sense for them.
Replacing a tuned setup to get one skill. Merge the skill and keep the rest.
Replacing every conflict without comparing. Yours may be the better version.
Expecting updates after a merge. One-off copies stay as they are until you merge again.
Never publishing a new version. The entry becomes the stale copy that everyone starts from.

How to do this with Athenode

In Athenode a setup is exactly that unit: agents, skills, rules, MCP servers and files, kept per project and generated into the configuration of 30 AI coding tools. The setup library is where projects share them.

Publish: an editor or owner of a project on a paid plan publishes a setup to the library, and publishing it again creates the next version of the same entry. Publishing is refused while an MCP server holds a literal value in an environment variable or a header, and the review page shows everything that becomes visible. Read Publishing a setup before the first one: a published entry is visible to every signed-in user, and publishing also turns on its display on the public website.
Browse: anyone signed in can search the library and read an entry's full content before using it. A selection of entries is also shown on the website, in the library catalog.
Add as a new setup: this gives the project a full copy as one more setup, so it needs room for another setup on your plan. A project on the Free plan has one setup and no room for a second, so it merges the entry into that setup instead.
Merge: merging an entry into a setup you have works on every plan. It starts with a preview: new items you can deselect, conflicts where you keep yours (the default) or replace it with the library one, and identical items that are left alone. Nothing is deleted, and a merge cannot be undone, so compare first.
Pull: in the web app, Pull from… takes content from another setup of the same project or from a setup of another project you are a member of, through the same preview.
Updates: only a setup that was added as a new setup remembers its entry and shows an update notice when the entry gets a new version. A merge or a pull is a one-off copy and gets no notice.

Your agent can do the library work for you: the /atn-manage skill browses the library, adds and merges entries, updates a setup and publishes one, through the library tools of the MCP server. The same operations are available as the library commands of the CLI. See Agent Setups for how setups work in a project.

Checklist

Before you share a setup, or take one:

Project facts and secrets are out of the setup you publish.
The setup is published as one named entry with versions, not sent as files.
A new project starts from a full copy and then makes the settings its own.
An existing setup takes parts through a merge with a preview, never a blind overwrite.
Every conflict is compared before anything is replaced.
You know which setups are connected to an entry and which are one-off copies.
Improvements go back as a new version of the entry.