cd /news/developer-tools/stop-copying-your-claude-md-between-… · home topics developer-tools article
[ARTICLE · art-111907] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=· neutral

Stop Copying Your CLAUDE.md Between Projects

A developer built Loadout, an adaptive context engine for AI coding agents that lets users create reusable 'loadouts' for different work situations, so context follows them across projects and agents. The tool detects the current project, selects the appropriate loadout, and injects it into the agent without modifying shared project files. It also includes workflow stages to maintain consistent engineering processes across different coding agents.

read5 min views1 publishedAug 26, 2026

I kept running into the same dumb problem with AI coding agents.

Every project needs context. How I like code structured. Which tools I prefer. How I want the agent to communicate. What commands it should run. How I want it to plan before touching anything.

So you put that stuff in CLAUDE.md. Or AGENTS.md. Or Cursor rules. Or Copilot instructions.

Then you open another repo and do it again.

Then you SSH into a server and none of it is there.

Then you switch from Claude to Codex and apparently you have a second configuration system to maintain now.

I didn't want a better CLAUDE.md.

I wanted the context to follow me.

So I built Loadout.

Loadout is an adaptive context engine for AI coding agents.

You create reusable loadouts for the situations you work in:

Then instead of launching:

claude

you launch:

load claude

Loadout detects what you're working on, picks the right loadout, renders the context, wires it into the agent, and gets out of the way.

So in a Rust repo, maybe the agent gets:

Result

/?

over unwrap()

.In a Next.js repo, it gets something completely different.

On a bare Linux server, it can get your sysadmin conventions instead.

The selection is deterministic and inspectable. There's no LLM sitting in the middle deciding which prompt you probably meant.

load explain

might give you something like:

Detected targets: [rust]

Loadout selection → rust

Active fragments
  • rust-conventions
  • terse-comms

That's basically the whole premise:

different work needs different context. Stop handing your agent the same one every time.

This distinction ended up being pretty important.

Your project's AGENTS.md

should describe the project.

Architecture. Build commands. Weird repository conventions. Things everyone working on that codebase needs to know.

Loadout is for what you bring to the project.

Your preferred workflow. Your coding conventions. Your tooling. How you want an agent to communicate. Things you've learned after using coding agents for six months and don't want to explain for the 400th time.

And Loadout deliberately doesn't rewrite the project's shared files.

It writes local, gitignored overlays using whatever mechanism each agent supports.

Your team's CLAUDE.md

, AGENTS.md

, or Copilot instructions stay alone.

I didn't want loadouts to turn into giant prompt blobs either.

So they're composed from fragments.

A fragment is just a reusable unit of context:

[[fragments]]
id = "rust-conventions"
guidance = "Build with cargo, lint with clippy; prefer ?/Result over unwrap()."

[[fragments]]
id = "terse-comms"
guidance = "Be terse. Lead with the result. Skip the preamble."

Then a loadout combines them:

[[loadouts]]
name = "rust"
targets = ["rust"]
fragments = ["rust-conventions", "terse-comms"]

Fragments can also be dynamic and pull context from shell commands, so not everything has to be static text.

The nice part is that terse-comms

isn't a Rust thing.

I can use the same fragment in my Rust, Next.js, Python, and server loadouts without copying it four times.

Context was only half the problem.

I switch between coding agents, but I don't necessarily want to switch engineering processes every time I do.

So Loadout has six common workflow stages:

/loadout:explore

/loadout:brainstorm

/loadout:plan

/loadout:implement

/loadout:verify

/loadout:ship

A workflow defines what those stages actually mean.

Loadout ships with workflows based on:

Or you can build your own.

That means I can use Claude today and Codex tomorrow without teaching both of them my preferred explore → plan → implement → verify loop separately.

The agent changes.

The process doesn't.

This one grew out of another annoyance.

Agents are getting pretty good at writing implementation plans.

But reviewing a 100-line plan inside a terminal transcript sucks.

So Loadout can turn an agent-written plan into a self-contained HTML page:

load plan render

You get the plan broken into phases, tasks, risks, and open questions.

More importantly, you can comment directly on individual elements.

So instead of telling an agent:

"The third thing you mentioned under the authentication section — not the first bullet, the other one — change that..."

you leave the comment on the actual task.

Loadout then assembles the feedback so you can hand it back to the agent.

It's still the agent doing the planning. Loadout just gives you a better review surface.

This was another requirement from the beginning.

Right now Loadout works with:

Both CLI agents and VS Code-based workflows are supported.

Each agent expects context in a different place, so Loadout handles the ugly part of delivering the same generated overlay the way that particular agent expects it.

I don't want my personal AI workflow coupled to whichever coding agent happens to be best this month.

I like config files.

I also don't particularly want to manually edit them every time I remember some tiny preference.

Run:

load studio

and Loadout opens a localhost web UI where you can create fragments, compose loadouts, assign targets, choose workflows, preview the generated context, and review the diff before writing anything.

There are starter packs too, so you don't have to build everything from an empty config on day one.

If you already have a giant CLAUDE.md

or AGENTS.md

, there's a migration skill for that:

load skill install

Then tell your agent:

"Import my CLAUDE.md into Loadout."

It turns the existing instructions into reusable fragments instead of making you manually pull the thing apart.

Your loadouts are global rather than living inside individual projects, so Loadout can sync the configuration through git:

load sync init git@github.com:you/loadout-config.git

Then on another machine:

load sync clone https://github.com/you/loadout-config.git

Now the same context can follow you from your laptop to another workstation or server.

Machine-specific/private values stay local.

Install the binary directly — no Rust toolchain, no Node required:

curl -LsSf https://github.com/elleryfamilia/loadout/releases/latest/download/loadout-installer.sh | sh

Then:

load studio
load claude

That's it.

Loadout is open source and MIT licensed:

github.com/elleryfamilia/loadout

If you're currently maintaining some combination of CLAUDE.md, AGENTS.md, Cursor rules, random prompt snippets, and things you keep telling agents to "remember from now on," this is pretty much the problem I built it to solve.

Give it a try. And if it earns a permanent spot in front of your coding agent, give the repo a star.

── more in #developer-tools 4 stories · sorted by recency
── more on @loadout 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/stop-copying-your-cl…] indexed:0 read:5min 2026-08-26 ·