Which version of the instructions was the assistant following when it wrote this? That question shows up in review when a change contradicts something everyone thought was settled, and the commit history is no help, because nothing in the source moved. The rule moved. Someone softened a line in CLAUDE.md three pushes back, the assistant started following the new version, and the code is a faithful implementation of an instruction nobody reviewed. You catch that only if you diff CLAUDE.md between pushes the same way you read a diff of the source.
Most teams do look at these files eventually. They ride along in a pull request whose title is about the endpoint, and the two-line change to AGENTS.md gets a glance on the way to the interesting part. That is the gap. A code diff tells you what the program does differently. A context diff tells you what the assistant will do differently in every session from now on, which is a larger blast radius and a quieter one.
The question a code diff never answers
A source diff is self-evidencing. You can read a function and judge it. Context files do not work that way, because the text is not the behaviour: the behaviour is the text plus whatever the assistant does with it over the next fifty prompts. Removing "never add a dependency without asking" does not fail any test. It fails three weeks later, in a session nobody is watching, when a reasonable-sounding suggestion goes in without the question being asked.
The second thing a code diff cannot tell you is whether a fact in memory is still true. Code that references a dropped library breaks loudly. A memory entry that says "we're on the old queue until Q4" simply keeps being read, and keeps being believed.
Instructions and memory move on a different clock than the source
Source changes constantly and in reviewed units. Instructions change rarely, usually in a hurry, often as a side effect of frustration: the assistant did something annoying, somebody added a line to stop it, and that line is now a standing rule with no author and no date. Memory changes in between, whenever a decision gets made or reversed.
That mismatch in cadence is why the push-to-push view matters more here than per-commit review. Over ten pushes the source may have moved through four features, while CLAUDE.md moved twice and .prjcontext/memory/decisions.md gained three entries and lost one. Those five edits are the whole story of how the project's rules changed, and they are trivial to read in one sitting if you look at them as a group instead of scattered across ten diffs about other things.
Three things a diff of CLAUDE.md between pushes can hide: a rule, a fact, and drift
Sorting each context change into one of three buckets is most of the review. They need different responses.
| Change | Looks like | What it affects | What review it needs |
|---|---|---|---|
| A rule changed | Edited or deleted line in CLAUDE.md / AGENTS.md | Every future session's behaviour | Who decided, and does the team agree |
| A fact changed | New or updated memory entry | What the assistant believes about state | Is it still true today |
| Drift | Reworded, softened, appended, duplicated | Both, invisibly | Was this a decision at all |
The rule/fact split is the same one that makes a CLAUDE.md merge conflict tractable, and it is worth applying to ordinary diffs too, not just conflicts. A deleted guardrail and an updated deploy target look identical in a diff (one line, one minus, one plus) and have nothing in common otherwise.
Drift is the category people skip. It covers the edit that changed "always run pnpm test before pushing" into "run tests before pushing", the memory file that now has two entries about the same choice pointing different ways, and the paragraph an assistant appended when you asked it to tidy up. Nothing here was decided. Something changed anyway.
Reading the diff as a decision log, not a changelog
A changelog read asks "what is different." A decision-log read asks, line by line, "who decided this and against what alternative." That second question is the one worth your ten minutes. In practice it comes down to four checks on each context change:
- Is there a date and a reason attached, or just new text?
- Does it contradict an entry that is still marked active?
- Is it a rule stated as a fact, or a fact stated as a rule?
- Would a fresh session reading only the new version reach the same conclusion you would?
The third check catches a surprising amount. "We use the repository pattern for data access" in a memory file is a description; the same sentence in CLAUDE.md is an order. Moving a line between the two files changes its force without changing a word, and a diff that shows the files separately makes that visible in a way a single merged review never does.
Contradictions deserve their own note. When a newer entry quietly disagrees with an older one, the fix is not to edit the old entry into agreement: that destroys the record of why the first choice was made, which is the argument in why editing old decisions breaks AI memory. Add the reversal, keep both, mark the old one superseded.
When the diff turns up a decision nobody made
Sometimes the answer to "who decided this" is nobody. An assistant was asked to clean up the instruction file and generalised a constraint. Someone resolved a conflict by keeping both halves. A teammate pasted a note into memory as a reminder to themselves and it now reads as project policy.
Treat that as a finding, not an embarrassment. Two useful outcomes: either you confirm the change and give it a date and a reason, or you revert it and write down why the original line existed, which is usually the more valuable artifact. The habit of asking what is worth keeping in a memory file at all is covered in the project memory guide.
Making the context diff part of the push, not an afterthought
Two cheap practices get you most of the way, whatever tooling you use. Run a status check before pushing and actually read the list of context files in it, since surprise entries there are the drift you were going to discover in November. And when you pick up a project after time away, read the context diff first and the code diff second.
This is where versioned repositories earn their place. Every prj push keeps an immutable version with its own copy of CLAUDE.md, AGENTS.md and the memory files next to the source, so you can open two versions in the browser and read the line diff of the context on its own, with a list of what changed. That is a different question from what a clone gives you, which is the current state of the project; here you want the delta between two points in time. If you want to try it on a project whose instruction file has quietly grown, the getting-started guide covers prj init, prj status and the first push.
The review takes ten minutes and finds the changes that no test will. Worth doing before you trust the newer version.
