Your Agent Doesn't Need More Skills — It Needs Fewer of Them

The instinct when a coding agent misses something is to add a skill for it. Missed a test? Write a "run tests" skill. Skipped a review step? Write a "review before commit" skill. After a few months of this you have a folder of forty skill files and the agent is somehow worse at doing the right thing automatically than it was with ten.

That's not a coincidence. Skills don't just sit there waiting to be useful — they compete for the model's attention every time it decides what to load. More of them isn't free.

The failure mode is selection, not capacity

An agent choosing which skill applies to a request is doing a matching problem: does this description fit what the user is asking for? With ten well-scoped skills, that's usually unambiguous. With forty, several descriptions start to overlap — "helps with debugging," "assists with fixing bugs," "runs when something breaks" — and now the agent is guessing between near-duplicates instead of confidently picking one.

The symptom you actually see isn't "too many skills loaded," it's misfires: the wrong skill fires, or the right one doesn't, or two skills half-apply and the agent blends them into something neither author intended. If you're debugging why a skill "used to work" and now doesn't fire reliably, check whether a newer skill's trigger description quietly started overlapping with it before you assume the model regressed.

What actually earns a skill

A workflow deserves a skill the third time you've explained it, not the first. If you've caught yourself typing the same instruction into an agent conversation twice, write it down as a skill on the third — anything sooner and you don't yet know if it's a real recurring pattern or a one-off you're pattern-matching too early.

A reasonable shape to aim for:

• One process skill per workflow phase. Debugging, code review, planning — each is a distinct procedure with its own gates, not one giant "how to code well" file trying to cover all three badly.
• A handful of domain skills for whatever your actual niche is — the stack, the conventions, the tools you use every day.
• Persona or standing-rule files for things that are always true, kept separate from anything conditional. (This is the same split that makes SOUL.md vs. AGENTS.md work: identity that never changes shouldn't live in the same file as an operational rule that gets patched next sprint.)

The part almost nobody does: retire skills

Adding a skill feels like progress. Deleting one feels like losing work. That asymmetry is exactly why libraries only grow. But a skill that hasn't fired in a month is either miscategorized (the trigger doesn't match how you actually phrase requests) or genuinely dead (the workflow it covered doesn't happen anymore) — and either way it's still in the selection pool, still a candidate the agent has to rule out on every single request.

Treat your skill folder like you'd treat a codebase: versioned, occasionally pruned, and audited when something starts behaving strangely. Before writing skill #41, spend five minutes checking whether skill #12 hasn't fired since you wrote it — the fix might be deleting a file, not adding one.

A quick audit if triggers feel muddy

1. List every skill's description in one place, side by side.
2. For each pair that could plausibly both apply to the same real request, that's your overlap — narrow one or merge them.
3. Note the last time each skill actually fired. Anything past a month gets either fixed or deleted, not left alone.

None of this requires tooling — it's a five-minute pass over plain Markdown files. If you're maintaining a larger library and want the trigger-writing part done for you rather than iterated by hand, Skill Forge ships 43 skills pre-organized into five non-overlapping domains, which is mostly useful as a reference for how tight a trigger description needs to be before it stops fighting its neighbors.

Full answer: https://agentkitworks.com/answers/how-many-skills-does-claude-code-need