When two files disagree
You shipped one instruction file, added a second, and the output went inconsistent. This is the most common practical failure of the whole approach and there is almost nothing written about it, so this page assembles the documented precedence order for each tool from the vendor's own pages.
The headline finding: two major vendors document precedence orders that are exact opposites of each other. Cursor puts the organisation at the top. GitHub puts it at the bottom. Any file claiming to be portable has to live with that.
It sits under brand voice for AI, and if you would rather skip the reading, eleven questions will produce a consistent set for every surface.
Which file wins?
In most cases, none of them. The word precedence is misleading here, because with the exception of one ChatGPT tier, no vendor documents an override. They document a priority ordering in which every applicable instruction is still supplied to the model. Nothing is dropped. The model is handed all of it and left to reconcile.
That is why the failure looks like inconsistency rather than like one file plainly winning. You have not configured a hierarchy. You have written two things and asked a model to hold both.
The documented precedence order, per tool
| Tool | Documented order | Override or priority? |
|---|---|---|
| OpenAI, chain of command | Platform, then developer, then user, then guideline | Genuine chain of command |
| ChatGPT projects | Project instructions above global custom instructions | Override, and on Enterprise and Edu they replace entirely |
| GitHub Copilot | Personal, then repository, then organisation | Priority only, all relevant sets still supplied |
| Copilot, within a repository | Path-specific, then repository-wide, then AGENTS.md | Priority only, both used when both match |
| Cursor | Team rules, then project rules, then user rules | Merged, earlier sources take precedence on conflict |
| Claude memory files | Filesystem root down to working directory, closest read last | Concatenated, not overridden |
Read the Copilot and Cursor rows next to each other. GitHub ranks organisation instructions last, so an administrator cannot use them to overrule a repository. Cursor ranks team rules first, and team rules can be enforced so that members cannot disable them. The same instinct about where authority should sit produces opposite implementations, and a file written on the assumption of either one is wrong on the other.
What happens when both apply at once?
GitHub is explicit that all relevant instruction sets are provided, and that repository-wide and path-specific instructions are both used when both match. Anthropic is explicit that discovered memory files are concatenated rather than overriding each other, walking up the directory tree with the closest file read last.
So the practical model is additive, not selective. Two files that agree reinforce each other. Two files that disagree hand the model a contradiction, and what it does with that is the subject of the next section.
Why CLAUDE.md plus AGENTS.md is not a duplication problem
Claude Code reads CLAUDE.md and not AGENTS.md. The documentation says so in as many words, and a search of the full official changelog for AGENTS.md returns nothing. Meanwhile AGENTS.md is read by a long list of other tools and is used by over sixty thousand open-source projects, with no mandatory fields.
The documented fix is not to maintain two copies. It is a one-line import at the top of CLAUDE.md that pulls AGENTS.md in, after which the shared rules have one home and CLAUDE.md carries only what is specific to Claude Code. Imports resolve to a maximum depth of four hops, and relative paths resolve against the importing file rather than the working directory.
This is the only official cross-vendor portability recipe that exists anywhere, which is worth knowing before writing your own.
What does a model do with two rules that contradict each other?
Anthropic answers this directly and the answer is uncomfortable: if two rules contradict, the model may pick one arbitrarily. Not the more specific one, not the more recent one, not the closest one on disk. Arbitrarily.
The same documentation frames memory as context rather than enforced configuration, with no guarantee of strict compliance, because the file is delivered as a user message after the system prompt rather than as part of it. That single architectural fact explains most of what people experience as an assistant ignoring them, and the precedence chain page covers why it happens in more detail.
The operational consequence is that a contradiction is not a tie to be broken. It is a defect to be removed from your own files before the model has to guess.
How do you write rules that fail loudly rather than quietly?
- Write prohibitions rather than preferences. Never use an exclamation mark is checkable by a person, by a linter and by you. Keep it energetic but professional is not, and two such lines can contradict without either being wrong.
- Keep one canonical file and derive the rest. If the same rule exists in five places by hand, the fifth copy is where the contradiction will be.
- Put the mechanical rules everywhere and the long rationale in one place. Person, contractions, spelling variant and punctuation prohibitions cost a few characters and never conflict. Paragraphs of philosophy conflict easily and cost the most context.
- Prefer a rule a checker can run. The download includes a style checker configuration for exactly this reason: a rule that a tool enforces cannot quietly disagree with a rule in another file.
A precedence table you can keep
The table above is the whole of it, and it is deliberately short enough to paste into your own documentation. Two cautions on keeping it: Cursor's documentation has changed materially and recently, to the point that its older rule-type names no longer appear and the legacy dot-file has been removed from the docs entirely, and the figures most often quoted for Copilot instruction limits do not appear in GitHub's documentation at all.
Check the source pages rather than trusting a summary, including this one. Every link below carries the date it was last read.
If you would rather not maintain the table, this tool writes each file for the surface it belongs in, which is the same information expressed as output instead of as a chart.
Where these come from
Every claim above is quoted from one of these, and each was read on the date beside it. If one of them has changed since, the page is wrong and we would like to know.
- OpenAI: Model Spec, chain of command checked 2026-08-16
- Anthropic: memory, load order and conflicts checked 2026-08-16
- GitHub: repository instructions and precedence checked 2026-08-16
- Cursor: rules and rule precedence checked 2026-08-16
- AGENTS.md checked 2026-08-16
One canonical document, rendered per surface, is how a precedence problem stops being yours: make one file per tool from eleven questions.