In November 2026 we ran an audit over the agent rules files (CLAUDE.md, AGENTS.md, Cursor rules, Copilot instructions) of 10 well-known open-source repos, then checked every finding by hand against the repo at a pinned commit.
8 of the 10 had at least one line that would send an agent the wrong way. These are good, well-run projects. That is the point: nothing in a markdown file expires, so rules files go stale in every repo when the code moves on.
| Repo | Confirmed findings |
|---|---|
| trigger.dev | 8 |
| Payload | 4 |
| cal.com | 4 |
| Novu | 4 |
| Documenso | 4 |
| Langfuse | 2 |
| Twenty | 2 |
| Excalidraw | 2 |
| Formbricks | 0 confirmed |
| tRPC | 0, clean (23 of 30 claims checkable, all true) |
The commit for each repo and every finding with its file and line are in the full results.
Three kinds kept coming up
Paths that moved. A folder gets renamed or deleted and the rules file still points at it. In trigger.dev, six paths had moved or never existed, such as app/v3/presenters/**, which now lives at app/presenters/v3/. In cal.com, three rules files point at packages/features/calendar-cache-sql, which is gone. The agent searches, finds nothing, and guesses.
Tools that changed. eslint to oxlint, Remix to React Router, React 18 to 19. Langfuse's AGENTS.md says every package lints with eslint; all four have run oxlint since a migration. Twenty's CLAUDE.md says the front end is on React 18; its package.json says ^19.2.0.
Two files that disagree. In trigger.dev, one AGENTS.md says to update the skills folder when SDK features change, and three other files say not to unless asked. In Documenso, .cursorrules says "prefer types over interfaces", then "use functional components with TypeScript interfaces" two lines later. Which one the agent follows depends on which it read last.
Why a stale rule is worse than a long file
Long files are a known problem: Anthropic's docs say a CLAUDE.md past about 200 lines uses more context and is followed less, and Chroma's context rot study found even a single irrelevant distractor lowers accuracy. A stale rule is not irrelevant. It is sent on exactly the task it misleads, and it reads as authoritative as the true rules around it. Either the agent follows it and writes wrong code, or it follows the code and looks like it ignored your file.
Check your own
Start with what the repo can answer: every path the file names that no longer exists.
grep -ohE '`[^`]*/[^`]*`' CLAUDE.md AGENTS.md 2>/dev/null \ | tr -d '`' | sort -u \ | while read -r p; do [ -e "$p" ] || echo "gone: $p"; done Expect some noise from globs and URLs. Then check tool names against package.json, and read any two files that cover the same topic side by side.
The audit we ran is a free, read-only skill, audit-memory. We found false alarms too (a symlinked AGENTS.md reported as a duplicate, a test command reported as hanging); each was dropped from the results, and the skill now checks for them.
When did someone last check your rules file against the code?
I work on Harbor (gethrbr.com), shared memory and rules for AI coding agents. The longer write-up, on context rot and stale rules, is at https://gethrbr.com/blog/context-rot-stale-rules.
