I've been building a tool that checks whether Claude Code actually followed the rules in your CLAUDE.md. Early on I realised I was testing it against one file: my own. So I went and got 559 real ones.
CLAUDE.md, AGENTS.md, .cursorrules, Copilot instructions, Windsurf, Gemini — from PyTorch, Kubernetes, Elasticsearch and a few hundred smaller repos. 21,986 items parsed out of them, no crashes.
Two things came out of it that I didn't expect.
63.4% of a rules file isn't a rule
Directory listings. Reference tables. Import examples. Architecture notes. Glob syntax cheatsheets.
All useful documentation. None of it is telling the agent to do anything. And it's sitting in the same file as the actual rules, competing for the same attention.
So when someone says their CLAUDE.md is 400 lines, it's usually closer to 150 lines of rules with 250 lines of README stapled on.
That reframes the "my CLAUDE.md is too long" problem. It's often not too many rules. It's rules buried in documentation.
Of the real rules, only 44.2% can be checked mechanically
Here's the split that surprised me more.
Checkable:
- "Never commit directly to main" — you can look at what git actually ran
- "No console.log in committed code" — you can look at what was written to files
- "Run the test suite before pushing" — either the command ran or it didn't
Not checkable by any tool, ever:
- "Surface bad news first"
- "Explain the trade-off before choosing an approach"
- "Keep changes reviewable"
There's no command to inspect for the second group. It's not a limitation of my parser — the information isn't in the transcript. A person has to read it and decide.
55.8% of the rules people actually write fall in that second group.
The distribution barely moved as the corpus grew
I started with 40 files: 65.4% non-instructions.
At 559 files: 63.4%.
Between those two points I added formats the parser had never been tuned on. It moved 2.0 percentage points.
That's the part I'd actually stand behind. It suggests "is this a directive?" is a property of language, not of file format — which matters, because the alternative approach (recognising every way people format
rules) is an infinite list.
What I don't know
I don't have a controlled experiment showing longer files perform worse. That's the obvious next question and I haven't run it.
But if a model is budgeting attention across a long file, it seems worth knowing that most of that file was never telling it to do anything.
The tool
It's called RuleReceipt. Free, runs locally, no account:
npx rulereceipt check
I also published the part where it got things badly wrong — it reported 10 violations on a real session of mine and every single one was false. That write-up is at https://rulereceipt.dev/postmortem, including the wrong turn I took while fixing it.
Happy to answer anything about the method. The corpus was public files only, and the classifier is in the repo.
Update, 4 September.
Two bugs in my own parser moved these numbers after publishing, so I'm correcting them in place rather than leaving them wrong. The parser had no concept of fenced code blocks, so a shell comment starting with # or a YAML item starting with - was read as a rule boundary — 588 rules were being cut mid-block, and 1,718 items (7.2% of everything extracted) were lines lifted out of code samples that had never been rules at all.
Separately, command documentation was being counted as rules. Corrected: 21,986 items, 63.4% non-instructions, 44.2% of real rules checkable. The 40-file sample moved 2.0 points rather than 2.5, which if anything strengthens the stability point.
Full history of every figure and what changed it: https://rulereceipt.dev/postmortem#history
