Two people edited CLAUDE.md last week. One tightened the testing rule because the assistant kept skipping the integration suite. The other added the new package manager and removed a stale line about the old deploy script. Both pushed, separately, and now there is a thread about whose version is right. The question nobody asked first is who should have owned those lines at all. A claude.md ownership policy fixes that, and it is far smaller than the word "policy" suggests.
The reflex in this situation is to resolve the collision and move on. That works once. It does not stop the same two people from colliding again next sprint, because the thing that caused it is still true: the file has no owner, so it has every owner. Resolving a CLAUDE.md merge conflict covers the cleanup after the fact. This is the part that comes before.
Six checks, in the order they actually matter.
1. Accept that the file has no owner by default
Every other file in the repo has an implicit owner. The person who wrote the auth module gets the PR. The person who maintains the pipeline reviews the pipeline change. CLAUDE.md escapes this because it is not code and it is not documentation either. It gets created in the first week by whoever set the project up, then edited by anyone whose assistant misbehaved that afternoon.
That is why it breaks before the decision records and before the session transcripts. It is the only context file everyone has a reason to touch, and the one nobody was assigned.
2. Read the conflict as a signal about sections, not people
When you look at a CLAUDE.md conflict, do not ask who edited last. Ask which kind of line each side touched. In the example above, one edit changed a rule (what the assistant must do) and the other changed a fact (what is true about the project right now). Those are two different sections of the file with two different lifespans, and they ended up fighting only because they share one document and one push.
If both edits had touched the same rule, you have a real disagreement about how the team works, and that belongs in a conversation, not in a merge tool. In practice most CLAUDE.md conflicts are not disagreements. They are two correct edits to unrelated parts of the same file.
3. Split ownership by section
This is the whole policy. Three kinds of content, three different owners:
| Section | What it holds | Who owns edits |
|---|---|---|
| Rules | "Run pnpm test -- --run before committing", "Never edit files in generated/" | Whoever owns the thing the rule protects |
| Facts | Stack, directory layout, real commands, service names | Whoever's change made the fact true |
| Tool preferences | Which agent reads which file, output and formatting conventions the team relies on | The team, changed rarely and deliberately |
Rules follow the underlying responsibility. If one person maintains CI, they own the testing and lint rules, even when someone else noticed the problem. The fix is to tell that person, not to patch the rule yourself. Rules that are written by whoever was annoyed most recently are also the ones that stop working, which CLAUDE.md guardrails: why they fail goes into.
Facts have a cleaner rule: the fact edit rides along with the code change that caused it. Rename api/ to services/api/, and updating the path in CLAUDE.md is part of that PR, not a separate cleanup push. That single habit removes most fact conflicts, because the only person editing a fact is the person who changed it.
Tool preferences are where teams overreach. The shared file should hold only the preferences the whole team depends on. Your personal taste in commit message verbosity goes in your own local config, untracked. If you keep both CLAUDE.md and AGENTS.md, your AGENTS.md editing rules should say which file is canonical and which one points at it, so an edit never has to be made twice. One file or two, without drift lays out both setups.
Notice that none of this assigns the file to a person. "Sam owns CLAUDE.md" sounds tidy and creates a bottleneck on the one file everyone needs to change on a Tuesday afternoon.
4. Add exactly one review step
The temptation after a painful conflict is to put CLAUDE.md behind an approval process. Resist it. One step is enough:
A rule edit needs one person who did not write it to read the diff before it lands. A fact edit needs nobody.
That asymmetry is the point. Facts are verifiable, cheap to fix, and wrong in obvious ways. Rules change how an assistant behaves across every future session, and a badly worded rule is invisible until something ships wrong. Reviewing the diff rather than the file matters here too, because a two line change to a rule section is easy to read and a 180 line file is not. Diffing CLAUDE.md pushes shows what to look for in that review.
We built PrjLab partly around this problem. Every prj push creates an immutable version you can open in the browser, with a list of changes and a line diff against the previous one, so "which section changed, and who pushed it" is a thirty second look rather than an argument. The ownership policy is what makes that diff readable: when sections have owners, you can tell at a glance whether an edit was in someone's lane.
5. Decide what happens when a new section fits nobody
It will happen within a month. Someone wants to add guidance about handling database migrations, and migrations have no clear owner yet.
Write the section anyway, and name an owner in the same push, even provisionally. A line like <!-- owner: priya, since 2026-10-22 --> above the section is enough. If nobody is willing to claim it after a week, that is useful information: the content is probably not a rule but a decision you made once, and it belongs in project memory with the reasoning attached rather than in the instruction file as a standing order.
6. Write the claude.md ownership policy into the file it governs
A team CLAUDE.md policy that lives in a wiki page gets read once. Put it at the top of CLAUDE.md, in about five lines:
## Editing this file
- Rules: owned by whoever maintains the thing being enforced. Ask them.
- Facts (paths, commands, stack): edit in the same PR as the change.
- One non-author reads the diff before a rule edit lands. Facts need no review.
- New section? Name an owner in the same push.
- AGENTS.md mirrors this file. Edit here, not there.
Your assistant reads those lines too, which is a small bonus: an agent asked to update project instructions tends to respect a scope rule that is written down in the file it is editing.
This is the cheapest kind of CLAUDE.md governance. It does not add approvals, it does not create a gatekeeper, and it changes a merge conflict from a question about people into a question about sections. If you want to see how the versioning side works in practice, the getting-started guide walks through the first push.
