Your rules file only grows. Here's how to find the rules that do nothing

This is part 3 of a series on project rules for AI coding agents. covered enforcing rules with hooks. This one covers the part almost nobody does: figuring out which of your rules are dead weight.

The append-only problem

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:

• 
  Context cost. Rules ship with every request. In Claude Code, 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.


• 
  Dilution. Agents don't weight 40 instructions equally. Every low-value rule competes for attention with the rules that actually prevent incidents. A short file is not just cheaper — it's followed better.


• 
  Rot. Rules encode assumptions about tool behavior at the time of writing. Tools change monthly. A rule that references behavior that no longer exists is worse than noise: it teaches the agent (and new teammates) something false.

So the file needs an audit loop. The question is what signal to audit on.

"Did it fire?" is the wrong question

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 ( — 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.