How rules layer — personal, repo, organization

You now have rules coming from more than one place: a repo-wide file your team commits, path-specific files over shared-lib’s helpers, and — once you start tuning Copilot to your own taste — personal instructions that live on your machine and follow you across repos. Most of the time these stack peacefully, each adding context the others don’t. But occasionally they say contradictory things, and when that happens you want to know which one wins before it surprises you in a diff.

The precedence order

When rules collide, the order is:

Personal > Repository > Organization.

• Personal instructions — your own, on your machine — sit at the top. They’re how you like to work, and they override the others when they conflict. Use them sparingly: a personal rule that fights your team’s repo rules is a way to quietly ship code that doesn’t match the team’s.
• Repository instructions — the committed copilot-instructions.md, AGENTS.md / CLAUDE.md, and path-specific files — are the shared team layer, in the middle.
• Organization instructions sit at the bottom of the precedence stack.

For a monorepo, or a checkout nested inside a parent repo, there’s a setting that controls whether Copilot also discovers customizations from parent repositories: chat.useCustomizationsInParentRepositories. Turn it on when your repo’s conventions legitimately live one level up; leave it off when a parent checkout would pull in rules you don’t want.

The organization gotcha — read this twice

Here’s the misconception that trips up almost everyone, and it’s worth being exact about.

Organization custom instructions do not apply in your IDE. Not in VS Code, not in JetBrains, not in the other editors. They take effect only in chat on GitHub.com, in the cloud coding agent, and in code review on GitHub. The server-side control for them is github.copilot.chat.organizationInstructions.enabled, and it governs those GitHub-side surfaces — not the editor you’re working in right now.

So why does “Organization” even appear in a precedence order you mostly experience in the IDE? Because precedence describes what happens on the surfaces where all three layers exist — primarily GitHub.com chat, code review, and the cloud agent. In your editor, the organization layer simply isn’t present, so what governs your Copilot there is your personal instructions over your repository instructions, full stop.

The practical consequences are sharp:

• A convention your org sets centrally will shape what Copilot does in a draft PR from the cloud agent and in GitHub.com chat — but it will not shape what Copilot writes in a teammate’s VS Code. If a rule must hold in the editor, it has to live in the repository file, where every surface reads it.
• Don’t assume an org-level instruction is silently enforcing your standards in everyone’s IDE. It isn’t. The repo-committed file is the only layer that reaches every surface.

This is exactly why the repo-wide file you wrote in the first lesson carries the weight it does: it’s the one layer present everywhere Copilot runs.

The mental model

Think of it as three rings of context — yours, your team’s, your org’s — read together, with the inner ring winning ties. But know where each ring is visible: personal and repository everywhere you work; organization only on GitHub’s own surfaces. Get that right and the precedence order stops being a trivia question and becomes a placement decision — which layer do I put this rule in so it reaches the surfaces that need it?

Which leaves the last and most human question of the chapter: of all the conventions you could write down, which ones actually earn a place in the file? What earns a place in the file.