A rich skill library feels like more capability, but every skill you load sits in context whether it's relevant or not, and that crowds out the model's grip on the actual task.
The Details:
Loading skills at session start pre-fills context with trigger conditions, examples, and steps for tasks that may never come up. That noise competes with recent instructions for the model's attention, so a constraint mentioned three messages back quietly loses weight against the freshest tokens, even though nothing was technically deleted.
Broad trigger phrasing causes false fires. A skill written to catch "code review" style tasks can latch onto the word "test" in a two-line fix request and launch a full audit nobody asked for. The opposite failure also happens: a real refactor arrives, and an explicit constraint gets buried behind irrelevant skill instructions that never should have loaded in the first place.
Not everything reusable deserves to be a skill. Repository-wide habits like formatting rules or forbidden directories belong in a persistent project file that's always present. A skill should only exist for a narrow, recognizable task type; a one-off reminder inside a single conversation costs nothing once that turn ends, while a permanent skill costs context every session forever.
A workable maintenance habit is a weekly check of which skills actually fired during real sessions, not which ones theoretically could. Most libraries turn out to have roughly half their skills sitting unused, while the two or three that fire reliably are usually the ones a developer would have written first. Reading trigger descriptions cold after time away exposes ambiguity before it shows up as a misfire mid-task.
Bottom Line: A lean, ruthlessly pruned skill set beats a sprawling one every time, because context is scarce and each unused skill is a tax paid on every task, whether it ever fires or not.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
