This is part 3 of a series on project rules for AI coding agents. Part 1 covered how Cursor, Claude Code, and Codex load your rules. Part 2 covered enforcing rules with hooks. This one covers the part almost nobody does: figuring out which of your rules are dead weight.
Nearly every long-lived rules file I've seen has the same life story. It starts as five lines. An agent does something annoying, someone adds a rule. A bug slips through, someone adds a rule. Six months later it's 40 rules, and nobody can tell you which ones still matter.
The reason is an asymmetry in how it feels: deleting a rule feels risky, keeping it feels free. But keeping isn't free:
CLAUDE.md
is loaded into context each session; in Cursor, alwaysApply
rules ride along on everything. Tokens spent on dead rules are tokens not spent on your actual code.So the file needs an audit loop. The question is what signal to audit on.
The obvious instinct is to count how often each rule fires — how often it gets attached to a request. Cursor even shows you which rules attached, so this feels measurable.
After part 1 of this series, a reader (@dipankar_sarkar) pushed on exactly this point, and his framing is the right one: count outcomes-changed, not matches. A rule that attached to 200 requests but never changed what the agent did is indistinguishable from a comment. Attachment tells you the rule was present, not that it was load-bearing.
The catch is that "outcomes-changed" is a counterfactual. To measure it directly you'd need to know what the agent would have done without the rule — and you can't observe that during normal operation. You can't A/B test every rule on every request without doubling your workload.
But there's a cheap approximation.
If you can't simulate the world without the rule, create it — briefly.
rules-quarantine.md
that no tool loads (for Cursor rules, flip alwaysApply
off or move the file out of .cursor/rules/
). Git keeps the history either way; this is reversible by design. One trap to avoid: don't just mark a section "ignore this" inside CLAUDE.md. The agent still reads every token of the loaded file, so the rule is still in context — and your test measures nothing.What makes this safe is the asymmetry of the two failure modes. A regression from a wrongly-deleted rule is visible and cheap — it shows up in a diff you were reviewing anyway, and git revert
fixes it. A dead rule you keep is invisible and permanently costly — it taxes every request forever and nobody ever notices. In a workflow where you review agent output anyway, deletion is much safer than it feels.
Between deletion tests, the day-to-day signal is simpler: what do you keep correcting? Every time you fix agent output by hand, that correction lands in one of three buckets, and each bucket has a different action:
That's the whole triage. Every rule ends up in one of four states: enforce (promote to hook), keep (observed saves), add (correction with no rule), delete-test (no evidence either way).
Concretely, once a quarter (or every N sessions if you move fast):
The end state of a well-audited rules file is short. Models absorb more conventions with every release — a rule that genuinely earned its place in January may be base-model behavior by June. The rules that survive repeated deletion testing are the ones encoding things models can't know: your architecture decisions, your team's non-obvious constraints, your definition of done.
Treat rules like dependencies, not like law: audit them, upgrade them, and remove the ones that no longer do anything. The file you end up with is smaller, cheaper, and — because every surviving rule is there for a reason someone can name — actually trusted by the people and agents who read it.
I maintain Rulestack — rule packs for Cursor, Claude Code, and Codex, audited against current tool behavior, so you start from rules that earn their place. Feedback welcome on Bluesky @ai-shop.bsky.social.