How do we keep rules files in sync across 250 repos without opening 250 PRs for one rule?

You keep rules files in sync across repos by not syncing them. A rule that applies to all 250 repos does not belong in 250 files. It belongs in the organization layer that each coding agent already loads before it reads the repo. The organization rules layer is the set of instructions an agent loads for every repository from a place your company controls, outside any single repo. Claude Code, Cursor and GitHub Copilot each have one, so keep the source for all three in one rules repository and a new rule becomes one PR there. Each repo's own file shrinks to the build commands and quirks that are true only for that repo.

Why 250 copies drift no matter how you sync them#

Copies drift because every repo is its own merge queue with its own owners and CI. For example, say the platform team adds "never log request bodies" and a bot opens 250 PRs. Two hundred merge within a week, thirty sit behind failing CI, and twenty owners close the PR because the bot's version conflicts with a hand edit. You now have three versions of the rule in production, and no agent can tell which one is current.

With three tools each reading its own file, one rule can mean 750 edits. AGENTS.md helps by giving most tools one shared file, and the spec says "the closest one takes precedence" when files nest (agents.md). But nesting only covers folders inside a single repo. Our post on keeping CLAUDE.md, AGENTS.md and .cursorrules in sync covers the multi-file side; the multi-repo fix is to move shared rules out of repos entirely.

Where the org layer lives in each tool#

A managed CLAUDE.md is an instructions file that Claude Code reads from a fixed system path on each laptop, such as /etc/claude-code/CLAUDE.md on Linux, before any project file. Anthropic's docs say to "use MDM, Group Policy, Ansible, or similar tools to distribute the file across developer machines". Developers can exclude other CLAUDE.md files, "but not this one" (Claude Code memory docs).

Team Rules are Cursor's org-wide rules, kept in the admin dashboard. An admin can mark a rule enforced, and then it "is required for all team members and cannot be disabled". Order is "Team Rules → Project Rules → User Rules," and "earlier sources take precedence when guidance conflicts" (Cursor rules docs). So the org rule beats a stale repo copy.

Copilot's organization custom instructions need a Business or Enterprise plan. They work "for sessions running on the GitHub website" and "for Copilot code review," and "they are not supported in local client sessions". In Copilot Chat on github.com they rank below personal and repository instructions (GitHub Copilot docs). That is the reverse of Cursor: a leftover repo copy of an old rule beats the new org rule. Delete the repo copy when you promote a rule.

Filling the gaps the org layer leaves#

Copilot in the IDE is the main gap, because its org layer stops at the browser. For the developers who use it, keep the shared rule in each repo's instructions file until GitHub extends org support, and treat that as the one place you still need a bot. Generate those files from the rules repository, so the bot never edits by hand.

Claude Code has a second route for teams without MDM. Rules in ~/.claude/rules/ "apply to every project on your machine". A shared checkout of the rules repository can be linked there, since .claude/rules/ "supports symlinks". Project symlinks pointing elsewhere need a one-time approval per project (memory docs, linked above).

A rule that must never be broken should not be text at all. Anthropic's docs split it plainly: managed CLAUDE.md is for "behavioral guidance," and permissions.deny in managed settings is for blocking tools or paths. Cursor says the same of its enforced rules: "AI guidance should not be your only security control". The answer on agents ignoring CLAUDE.md rules covers hooks for this.

What stays in each repo, and what moves to retrieval#

After the move, a repository's AGENTS.md or CLAUDE.md holds only local facts, such as build commands, test commands and the folder nobody should touch. Those change with the repository, so its own pull requests keep them current.

A third kind of rule fits neither place. For example, "use version 2 of the payments client, not version 1" is a team decision, made in a PR thread and argued in Slack. Copying it anywhere freezes it at the date of the copy, and rules-file rot follows. These belong in retrieval, where the agent asks when it needs the answer.

That is where Unblocked fits. A context engine is a service that reads code, PRs, issues, docs and Slack threads together and answers over MCP with the asking user's permissions, and Unblocked is the one we build. Its context_get_rules tool returns the 20 highest-severity rules from a repo's own instruction files, filtered to the paths being changed, and context_research finds the PR or discussion behind a rule (Unblocked docs). It reads each repo's files as they are and pushes nothing into them, so it complements the organization layer.

One rule, one PR: the rollout#

1. Create a rules repository. Put the shared rules in one markdown file per topic, such as logging or secrets, with a short note on why each exists. The rules files vs a context engine post helps sort which rules are stable enough to live there.
2. Have its CI render three outputs: the managed CLAUDE.md for your MDM tool, the text for Cursor Team Rules, and the text for Copilot's org instructions. Paste the last two by hand if you have no API for them; it is two edits, not 250.
3. Delete the shared rules from repo files once the organization layer carries them. In Copilot this matters most, since repo text outranks org text.
4. Mark the few rules that must hold as enforced in Cursor, and back them with permissions.deny or a hook in Claude Code.

From then on, a new rule is one reviewed PR in one repository, and every agent across all 250 repositories picks it up.