Your CLAUDE.md doesn't scale. Version your AI standards as code.

Every team using AI coding agents starts the same way: someone drops a CLAUDE.md (or .cursorrules, or a copilot-instructions.md) into a repo. It works. So the next repo gets one too. And the next.

Then you look up and you have 20 repos, 6 teammates, and 3 different AI tools — and no two of those config files are the same. Which one is right? Nobody knows.

I hit this wall running an integration platform with dozens of small repos. This post is the pattern I landed on, and a small open template you can clone to do the same.

Why a single instructions file breaks

A single file is perfect for one repo and one person. At team scale it fails in five predictable ways:

1. 
   It doesn't scale. Every repo gets a slightly different copy. There's no "the standard" — there are 20 forks of it.


2. 
   It drifts. Someone improves the file in one repo. That improvement never reaches the other 19.


3. 
   It's unversioned. No history, no ownership, no review. Your "AI brain" is the one artifact in your stack nobody code-reviews.


4. 
   It's tool-locked. Cursor's format isn't Claude's isn't Copilot's. Switch tools and you start over.


5. 
   It rots. The code changes; the instructions don't. Six months later the agent is confidently working from a map of a city that's been rebuilt.

None of these are exotic. They're just what happens when a copy-pasted file meets a growing team.

What already exists (and what it doesn't fix)

• 
  Curated rule lists (e.g. awesome-cursorrules) are great for inspiration, but they're copy-paste, single-tool, and have no sync or freshness.


• 
  Skill/agent sync tools distribute tools across agents. Useful — but they solve distribution, not your team's standards, versioning-as-review, or the rot problem.


• 
  The Agent Skills standard + AGENTS.md are the right substrate to build on, not competitors.

The gap: nobody treats the standards themselves as code — owned, versioned, reviewed, and automatically distributed.

The pattern: standards-as-code

Three moves:

1. 
   Put your standards in one git repo. Two kinds of artifact:
   
   
   
   
   • 
     Rules — standing behavior ("always validate input", "never log PII").
   
   
   • 
     Skills — task workflows ("here's how to cut a release"), in the portable SKILL.md format.
   
   
   
   


2. 
   Auto-sync them into your editor. A setup script links skills/ and rules/ into your tool's config directory. Git hooks re-run the sync on every pull / checkout / rebase.


3. 
   Change them through pull requests. Improving a standard is now a reviewed diff, not a silent edit in one repo.
   

Git repo (source of truth)          ~/.cursor/

  skills/  ──────────────└            skills/   (junction/symlink)

  rules/   ──────────────┤  setup +   rules/    (synced .mdc)

                         └── git hooks ─────────→ every workspace, every teammate

Because rules sync to the user level, they apply in every workspace automatically. Update the repo, everyone git pulls, and the whole team's standards move together — no per-repo copies.

Why this beats a bare CLAUDE.md

It's the difference between a shared library and a code snippet everyone pastes.

Try it (v0.1)

I packaged the mechanism as an open template: helps more than you'd think.