Anti-Bloat Principles

Every rule you add to CLAUDE.md has a cost. Not just the token cost — though that matters — but an attention cost. Every rule competes with every other rule for Claude's limited attention budget. A 100-line CLAUDE.md where every line is essential will outperform a 500-line CLAUDE.md where 60% is filler, every time. The signal-to-noise ratio of your rules file directly correlates with output quality.

The 200-line threshold is where most teams start seeing diminishing returns. Below 200 lines, adding a new rule almost always improves behavior. Between 200 and 400 lines, adding a rule improves the specific behavior it targets but may slightly degrade adherence to other rules. Above 400 lines, you are in the danger zone — Claude starts pattern-matching against the most recent or most prominent rules and quietly ignoring the rest.

Bloat enters CLAUDE.md through three vectors. First: rules that were relevant during a specific sprint but never got removed. "We are migrating from Redux to Zustand — always use Zustand for new state management" was critical in January. By March, the migration is complete and the rule is noise. Second: redundant rules that say the same thing in different words. "Always use TypeScript strict mode" and "Never use any type" and "Enable all strict checks in tsconfig" are three rules where one would suffice. Third: rules that duplicate information Claude already knows from training data. "Use async/await instead of .then() chains" is already Claude's default behavior in modern TypeScript projects. The rule adds tokens without changing behavior.

The pruning audit is simple. Once a month, read every rule and ask: has Claude violated this rule in the last 30 days? If not, it either works so well that Claude has internalized it (keep it) or it governs a scenario that never arises (delete it). The distinction is usually obvious.