Managing agent config across multiple repositories without losing your mind

One repo with an AGENTS.md is a curiosity. Six repos is an
organizational problem, and twenty is a maintenance tax you pay every
week. The rules multiply by format too: the same conventions now live
in AGENTS.md, CLAUDE.md, .cursor/rules/*.mdc, and
copilot-instructions.md, so one standards change is potentially
four edits per repository.

The three strategies

1: The shared snippet (symlink, include, or script)

Keep canonical content in one place, a dev-config repo, an internal
registry, and generate or symlink per-repo files.

• Pros: single source of truth; a standards change is one edit.
• Cons: symlinks break across checkouts and confuse some tools; include-mechanisms vary per tool (only Claude Code supports @import natively); generated files need discipline to stay generated (a hand-edited generated file is worse than a hand-written one, because nobody audits it).
• Works best when: repos are numerous and homogeneous, and someone owns the generator.

2: Copy-once, drift-forever (the default)

Every repo gets its own files at project start, maintained by whoever
touches the repo.

• Pros: zero infrastructure; each config fits its repo exactly.
• Cons: drift is guaranteed. Within a year, the error-handling convention in repo A contradicts repo B, and nobody knows which is current. New repos clone stale templates.
• Works best when: repos are few and genuinely different.

3: Versioned kits (npm-for-config)

Treat config like a dependency: kits are versioned, updated via a
bump, and your local customizations live in known places.

• Pros: updates are deliberate events with changelogs; consistency across repos without infrastructure; local edits survive updates if the kit structure keeps generated and hand-written content separate.
• Cons: you need kits that exist (community, commercial, or in-house); a bump is still a review.
• Works best when: you run the same stack across many repos, or the same team touches many stacks.

The decision matrix

Your situation	Strategy
1–3 repos, distinct stacks	Copy-once is fine. Write good files once.
4+ repos, same stack	Versioned kits pay for themselves quickly
10+ repos, mixed stacks	Kits for common stacks + copy-once for the long tail
Monorepo	One root baseline + per-package overrides; both file layers load

Rules that help under every strategy

1. Separate universal from stack-specific. Commit conventions, safety rules, and the definition of done are 80% identical across repos. Keeping them conceptually separate makes any strategy simpler.
2. Keep the command table repo-local. The one block you should never share: commands differ per repo, and a wrong command is worse than a missing one.
3. Version visibly. A Managed by X v1.2 header comment turns "is this file current?" from an archaeology project into a grep.
4. Update events, not drift. Whatever the mechanism, changes should arrive as reviewable units, a diff, a bump, a PR , not as silent hand-edits across repos.

What we do

AgentConfig Studio is strategy 3 as a product: twelve stack kits,
semver-versioned, with an idempotent installer that tracks what it
wrote (so updates and uninstalls are clean), and a documented boundary
between pack-owned files and your local edits. The universal layer is
shared by construction; the command table is generated per stack and
marked as the first thing to edit per repo.

---

If you'd rather not assemble this by hand: AgentConfig Studio on Gumroad ships this as version-pinned, validator-tested kits for 12 stacks. The complete Next.js/TypeScript kit is free (MIT) if you want to inspect the structure first.