Pruning configuration

Every Foundations section before this one teaches you how to add something — a CLAUDE.md rule, a skill, a sub-agent, a hook, a slash command, a plugin. None teach you how to cut. Pruning is the missing primitive, and the system gets worse without it.

Configuration accretes. A rule gets added to fix a specific bad output and never gets removed when the bad output stops happening. Two entries contradict each other because they were written months apart. A rule that’s vague enough to interpret differently across runs produces inconsistent behaviour, but it stays because no single output was wrong enough to flag. Each addition felt justified at the time, so the bloat is hard to notice — but the cost compounds.

This section gives pruning the same status as adding.

What to look for

Four shapes of entry reliably belong in the prune pile:

Reactive rules that no longer apply. A rule added in response to one bad output, while the bad output was a one-time issue. “Don’t use the deprecated useEffect pattern” was useful in week three; in week ten the deprecated pattern is gone from the codebase, but the rule lives on.
Contradictions. Two entries that pull in opposite directions. A CLAUDE.md rule says “prefer Server Actions over API routes” while a path-scoped rule in the API folder says the opposite. The model satisfies whichever was read more recently, and you get drift.
Duplicates. The same rule stated in three places — once in CLAUDE.md, once in a skill, once in a hook trigger. Updating one location doesn’t update the others, so the rules diverge over time.
Vague entries. “Be concise” or “use good judgement” produce inconsistent behaviour because the model interprets them differently across runs. Vague rules that don’t constrain outcomes are worse than no rules — they give false confidence that the behaviour is governed.

The bullets above describe symptoms. The underlying test is simpler: does removing this entry make the system measurably worse? If you can’t name what would change, the entry is probably noise.

How to test that an entry still earns its keep

Pull the entry out for a session, run the kind of work it was meant to govern, and watch for regressions. If outputs come back the same, the entry wasn’t doing the work you thought it was — either the model had stopped relying on it, or the rule was being routed around. If outputs come back worse, the entry is earning its place; put it back.

The test is cheaper than the deliberation. Most “should this stay?” questions resolve in one session of running without it.

A few specifics:

For a CLAUDE.md rule, comment it out for one session. Run a normal mix of work. Check the output against what the rule was trying to prevent.
For a skill, rename the folder so the auto-trigger fails. Use the workflow without the skill. If you reach for the skill manually, it earns its keep; if you don’t notice it’s gone, it doesn’t.
For a slash command, stop using it for a week. If you don’t replace it with anything, the workflow it codified wasn’t recurring; delete the command.
For an entry in auto-memory, delete the file and the line in MEMORY.md, then run a session that would have used it. The absence either costs something or it doesn’t.

The pattern is the same in every case: take it out, observe, decide.

Cadence

Pruning belongs in the same review rhythm as the rest of the maintenance work — the monthly CLAUDE.md review covered in CLAUDE.md and the project’s memory.md monthly pass covered in Memory. Do them together. One pass over a project’s configuration, asking the same question of every entry: does this still earn its keep?

A single 20-minute pass usually catches more than separate ad-hoc reviews spread across the month. The accumulated context lets you spot contradictions and duplicates that aren’t visible when you’re looking at one file at a time.

The cost of pruning is small; the cost of not pruning compounds. The pile of stale rules grows quietly until you notice the model has started ignoring a section of CLAUDE.md you can’t remember writing.