Fewer Skills, Better Results

A skill in Claude Code is a folder with a markdown file in it. The agent sees every skill's name and description at the start of every session and loads the full instructions only when a task seems to match. That design makes skills cheap to add, and I have added a lot of them. My library is in the dozens, kept as files in my vault and synced to the live skills folder.

Cheap to add does not mean free to keep. Every description sits in the context next to every other one, and next to the actual task. Two descriptions that sound alike force the model to guess. A skill that loads when it should not brings its whole body of instructions along.

Two sources in my research notes look like they pull in opposite directions. Nick Nisi's AI Engineer talk, posted this week, is about deleting 95 percent of his skills. Nate Herk's video from earlier in May lists the six best skills out of the hundred-plus he says he tried.

What Nisi measured

Nisi does developer experience work at WorkOS across more than twenty repos in eight languages. He generated skills from the product documentation: over 10,000 lines, split per section, regenerated when the docs changed. On paper that is careful engineering.

His evals said otherwise. By his account a run took 68 minutes with constant retries. He rewrote the material by hand as 553 lines covering only the things models reliably got wrong. Runs dropped to 6 minutes and accuracy went up. The number that stuck with me is from a single skill on a single task: 77 percent correct with the skill loaded, 97 percent without it. "I was actively making it worse," he says, and he adds that he only knew because he was measuring.

His explanation is that "the models know how to code". What they lack is the product-specific traps. A summary of the docs repeats what the model can already work out. A short list of gotchas tells it where it will go wrong.

Two cautions before leaning on this. The 77 and 97 figures are one skill on one company's evals, presented in a conference slot that opens with a plug for his employer. And what he measured is skill content, not skill count. He did not test whether a large index of descriptions hurts routing. That half of my argument is inference. I think it is a fair one, because the mechanism is the same: tokens that do not help the task still take attention. I cannot cite a number for it.

What the best-of list is really saying

Herk's video reads like the opposite advice. Here are the things to install: Skill Creator, Superpowers, GSD, the built-in review commands, Context Mode, ClaudeMem, and Frontend Design as a bonus.

Look at the headline again. He tried more than a hundred and kept six. That is a cut of about the same size as Nisi's. He just presents the survivors.

	Nate Herk's list	Nick Nisi's talk
Starting point	100+ skills tried, by his count	10,000+ lines generated from docs
What survived	Six picks and a bonus	553 hand-written lines
Filter	Helps work that clients pay for	Beats the no-skill baseline in evals
Evidence shown	His own claims and project READMEs	One with and without score, plus run times

The difference is the filter and the proof. Herk's test is commercial: each pick maps to a failure that costs time or trust on client work. The evidence is thinner. The 400 hours and 100 skills are his own count. One slide shows a single quality bar at 48 percent with nothing to compare it to. The Context Mode size reductions come from that project's README. The claim that sessions stretch from 30 minutes to three hours is stated, not shown. He also sells coaching, and the video ends by pointing at it.

He earns some credit back by saying plainly that GSD does not save tokens. Subagents cost more, and what they save is rework.

Most of his six are also plugins that change the environment through hooks, sandboxing or a memory store. I run Context Mode myself, and it does its work in hooks and tool routing, not by being one more description for the model to match. That is a different cost profile from a markdown skill.

So the two sources agree on size and disagree on what counts as proof.

The test a skill has to pass

Nisi's question is the better one. On a task I care about, does the agent do better with this skill loaded than without it? He notes that Claude now ships an evals skill that runs the comparison and writes a side-by-side report, so asking has become cheap.

Running that for dozens of skills is still a lot of work. I would screen first, in this order:

Has it been invoked in the last month? If not, its description is pure overhead.
Does its description overlap with another skill's? Merge them or delete one.
Does the body tell the model things it already knows, or things it gets wrong in my setup? Keep only the second kind.
For what survives and matters, run it with and without.

I have not run step four on my own library yet, so I cannot say which of my skills would pass. My guess is that skills built around a hard check will hold up, since that is closer to what Nisi calls enforcing than to instructing. I am less sure about long skills that restate general advice.

Key Takeaways

Skills are cheap to add and not free to keep. Descriptions and loaded bodies both compete with the task for attention.
Nisi's measured case is about content: 553 hand-written lines beat 10,000 generated ones, and one skill did worse than no skill. It is a single product's evals.
A best-of list is also a deletion. Herk kept six of a hundred-plus, filtered by paid work, and most of his numbers are claims.
The keep test is with versus without on a real task. Usage and overlap are cheaper screens to run first.

Sources

Next: list every skill I have not invoked in a month, then run with and without on the three I would be most reluctant to delete.