How rules layer - personal, repo, organization

Rules can come from more than one place at once: a repo-wide file your team commits, path-specific files over the directories that need them, personal instructions (account-level rules set on github.com that follow you across repos, plus your editor’s user-level instruction files), and instructions your organization sets centrally. Most of the time these stack peacefully, each adding context the others do not. When they contradict, you want to know which one wins before it surprises you in a diff.

The precedence order

On GitHub.com chat, code review, and the cloud coding agent, the documented precedence order is:

Personal > Repository > Organization.

• Personal instructions sit on top, and they have two homes. The account-level ones are set at github.com/settings/copilot and apply to your sessions everywhere; VS Code additionally reads user-level instruction files from your own home directory (for example ~/.copilot/instructions in current builds). Both outrank repository files - which is also why a personal rule that fights your team’s repo rules quietly ships code that does not match the team’s. Use them sparingly.
• Repository instructions - the committed .github/copilot-instructions.md, the AGENTS.md or CLAUDE.md convention files, and path-specific files - are the shared team layer.
• Organization instructions sit at the bottom of the stack.

For a monorepo or a checkout nested inside a parent repo, VS Code controls parent-repo discovery with chat.useCustomizationsInParentRepositories (per the custom instructions documentation, as of September 2026). And do not assume the same precedence and discovery behavior across Copilot CLI, IDEs, GitHub.com, and the cloud agent; the surfaces combine instructions differently.

The organization layer, precisely

The misconception to head off is that org instructions are always in force everywhere. The truth is narrower and worth being exact about:

By default, the IDE does not apply organization custom instructions. Outside the IDE, they take effect in chat on GitHub.com, in code review (Copilot reviewing pull requests), and in the cloud coding agent (the async Copilot that works on GitHub). In VS Code, org instructions are not on by default: discovery is gated by the client-side setting github.copilot.chat.organizationInstructions.enabled, which VS Code’s own documentation describes enabling for org-level instruction discovery. GitHub’s support matrix, separately, still listed Organization support for VS Code Copilot Chat as absent as of October 2026, so the two primary sources currently disagree about how completely the layer reaches the IDE; check both, and verify in your own editor, before relying on org instructions there. JetBrains does not apply the organization layer.

Where org rules actually reach

An org-level instruction reliably shapes GitHub.com chat, code review, and cloud-agent pull requests. Whether it shapes what Copilot writes in a teammate’s VS Code depends on the setting above and on surface support that is currently documented inconsistently; in JetBrains it does not apply. If a rule must hold in the editor, put it in the repository-wide file (.github/copilot-instructions.md or your AGENTS.md) - the broadly supported shared layer. Path-specific files are the one repo-level mechanism with a gap: they are not honored in GitHub.com chat.

So when “Organization” appears in a precedence order, remember that the order describes what happens on the surfaces where all three layers exist. In your editor, the org layer may simply not be present, and what governs your Copilot is personal over repository. The practical placement decision: which layer does this rule need to live in so it reaches the surfaces that must obey it?

The three layers get easier to reason about once you see where each one physically lives - and with Copilot that is an unusual map: mostly .github/, VS Code settings, and toggles on github.com rather than dotfiles. Walk it file by file, including the surfaces later chapters build on (prompt files, custom agents, skills, MCP):

Claude CodeCodexCopilotCursorOpenCodePi

committedin git, shared with your teamgitignoredlocal only, never sharedauto-generatedwritten by the tool; do not hand-edit

your-project/

.github/copilot-instructions.mdcommitted

▾.github/instructions/committed

AGENTS.mdcommitted

▾.github/prompts/committed

▾.github/agents/committed

▾.github/skills/committed

.vscode/mcp.jsoncommitted

.github/workflows/copilot-setup-steps.ymlcommitted

you (VS Code & github.com)

VS Code settings.json

Personal instructions (github.com)

Org instructions (github.com)

▾~/.copilot/skills/

~/.claude/CLAUDE.md

Select a file or folder

Every entry shows what the file does, when Copilot reads it, whether it belongs in git, and a working example.

Which leaves the chapter’s final question: of all the conventions you could write down, which ones actually earn a place in the file? What earns a place in the file.