{"slug": "your-rules-file-only-grows-here-s-how-to-find-the-rules-that-do-nothing", "title": "Your rules file only grows. Here's how to find the rules that do nothing", "summary": "A developer proposes a method for auditing AI coding agent rules files to identify and remove dead weight. The approach involves temporarily quarantining rules to test their impact, arguing that deleting unused rules is safer than keeping them due to the cumulative token cost. The developer recommends triaging rules based on observed corrections and periodically testing for deletion.", "body_md": "*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.*\n\nNearly 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.\n\nThe reason is an asymmetry in how it feels: **deleting a rule feels risky, keeping it feels free.** But keeping isn't free:\n\n`CLAUDE.md`\n\nis loaded into context each session; in Cursor, `alwaysApply`\n\nrules 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.\n\nThe 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.\n\nAfter part 1 of this series, a reader ([@dipankar_sarkar](https://dev.to/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*.\n\nThe 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.\n\nBut there's a cheap approximation.\n\nIf you can't simulate the world without the rule, *create* it — briefly.\n\n`rules-quarantine.md`\n\nthat no tool loads (for Cursor rules, flip `alwaysApply`\n\noff or move the file out of `.cursor/rules/`\n\n). 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`\n\nfixes 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.\n\nBetween 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:\n\nThat'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).\n\nConcretely, once a quarter (or every N sessions if you move fast):\n\nThe 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.\n\nTreat 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.\n\n*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.*", "url": "https://wpnews.pro/news/your-rules-file-only-grows-here-s-how-to-find-the-rules-that-do-nothing", "canonical_source": "https://dev.to/rulestack/your-rules-file-only-grows-heres-how-to-find-the-rules-that-do-nothing-4n2m", "published_at": "2026-07-13 23:15:09+00:00", "updated_at": "2026-07-13 23:44:09.828558+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools", "machine-learning", "large-language-models"], "entities": ["Cursor", "Claude Code", "Codex", "Rulestack", "@dipankar_sarkar"], "alternates": {"html": "https://wpnews.pro/news/your-rules-file-only-grows-here-s-how-to-find-the-rules-that-do-nothing", "markdown": "https://wpnews.pro/news/your-rules-file-only-grows-here-s-how-to-find-the-rules-that-do-nothing.md", "text": "https://wpnews.pro/news/your-rules-file-only-grows-here-s-how-to-find-the-rules-that-do-nothing.txt", "jsonld": "https://wpnews.pro/news/your-rules-file-only-grows-here-s-how-to-find-the-rules-that-do-nothing.jsonld"}}