Should you delete your CLAUDE.md? Only half of it

A clip of Boris Cherny, who created Claude Code, is making the rounds. His advice, at YC: every six months, delete your CLAUDE.md, your skills and your hooks, and see what the model does. It might surprise you.

He's right about a lot of it. But after running Claude Code, Codex, Cursor and Grok agents side by side for months, I don't think "delete everything" is the whole lesson. I think there are two kinds of lines in a rules file, and only one of them goes stale.

Lines that go stale: capability patches

These are rules you wrote because the model of the day couldn't do something:

• "Always read the whole file before editing it."
• "Use TypeScript strict mode; don't use any."
• "Write the test first, then the implementation."
• "Think step by step before large refactors."

Each one patched a weakness. Newer models often do these things unprompted, and the old rule now costs context, or worse, fights a better default the model would have picked. These are the lines Boris is talking about. Delete them and watch.

Lines that don't: reporting and safety contracts

These rules aren't about what the model can do. They're about what you need from it to trust the result:

• "End every task with: Done (with evidence) / Not done / Unverified."
• "Never claim tests pass without the exact command and its output."
• "Never skip, delete or loosen a test to make it pass without approval."
• "Ask before destructive, external or paid actions; proceed on reversible ones."
• "Only cite paths and URLs you opened in this session."

A smarter model doesn't make these redundant. A smarter model gets more done between check-ins, so a false "done" costs more, not less. These lines are a contract between you and whatever model is behind the agent this month. Every upgrade so far has left them just as useful for me.

A 10-minute version of the six-month purge

Instead of deleting the file and hoping, sort it:

1. Copy CLAUDE.md somewhere safe. You'll want the diff.
2. Tag each line: capability (patches something the model couldn't do), project (facts: stack, commands, layout) or contract (how it reports, what it may not do).
3. Delete the capability lines. Run two or three real tasks. Add back only the ones whose absence actually hurt you.
4. Check the project lines against reality. Stale commands and paths are worse than none; agents follow outdated docs faithfully.
5. Keep the contract lines. If you don't have any, these are the ones worth adding.
6. If you run several agents, make one file the source of truth (AGENTS.md, with CLAUDE.md importing it) so the purge happens once.

The test I use

For any line, ask: "If the model were twice as capable tomorrow, would I still want this?"

• "Use pnpm, not npm": yes, it's a project fact.
• "Read the file before editing": probably not.
• "Paste the test output before saying done": absolutely, and more so.

Want the contract lines ready-made?

My ten favourites are free on GitHub: top-10-agent-rules.md.

All 40 failure patterns I've collected, each with its symptom and a one-line rule, are on a printable 3-page cheat sheet: 40 AI Coding-Agent Failure Patterns + One-Line Fixes ($3).

If you'd rather someone else sort your file, I do a $9 quick review of one CLAUDE.md / AGENTS.md / .cursorrules: what's stale, what conflicts, and five paste-ready fixes.

Which lines in your rules file have survived the most model upgrades?