You Pruned Your Skills to Save Tokens. The Tokens Were Never Costing You Anything.

Some evening in the last few months you opened your skills folder and started deleting. Something that scrapes a page, three variations on a git helper, a thing you installed after a conference talk and never opened. The advice was everywhere and it was specific: all those idle skills are eating your context on every single call, so cut them and get your accuracy back. It felt like flossing. You did the responsible thing.

The responsible thing was aimed at the wrong variable.

The Chore You Already Did

The advice has a name. Skill bloat is the new context tax, and once you see the phrase you see it everywhere, in posts and threads and in tooling built around it. There is a shell utility called skills-janitor that pitches itself as Tinder for your Claude Code skills and offers to swipe away what wastes context. There is an open feature request against Hermes, filed in May and still sitting there without a maintainer reply, from a user running 243 installed skills. That report is where the scary number comes from: on Hermes, which injects the name, category and description of every installed skill on every turn, the skill list was measured adding roughly 10,000 to 15,000 tokens to each API call, and manually disabling 90 skills bought back only about 37 percent of the context. That figure was measured on Hermes and belongs to Hermes. It is a different architecture from Claude Code and does not transfer. But it traveled, and it is a large part of why the folder cleanup felt urgent.

The reasoning behind all of it is clean. Skills are text. Text is context. Context is finite and it is the thing you actually pay for. Every skill you installed and never called looks like a passenger riding along on every request, so the fix is to stop carrying passengers. Prune the library, reclaim the tokens, get the accuracy back.

That is a good argument, made by careful people. They noticed their agents getting worse, went looking for a mechanism instead of shrugging, and found one that fits everything they know about how these systems work. Most builders never get that far.

Then a group of researchers took the same degradation, split it into its parts, and measured each part separately. The passengers turned out to cost almost nothing.

What the Measurement Actually Says

The paper is More Skills, Worse Agents? (arXiv 2605.24050, submitted 2026-05-21 and revised 2026-06-23). The setup is the one you would want: start from a small set of genuinely helpful skills, scale up to a library of 202, and watch what happens to task performance. What happens is that performance falls by up to 21 percent.

Carry the condition with the number, because the number is not a law of nature. Up to 21 percent is what a 202-skill library did to that particular evaluation. It is not a rate you can apply to your own 60 skills and it is not a promise about what your next install costs you. What it is good for is direction, and the direction was already obvious to anyone who has watched a big library get flaky.

That much matches the folk wisdom. The interesting part is what the authors did next, which was to stop treating the drop as one number and start asking which of two very different failures produced it. That step is the one that changes anything, because an aggregate cannot tell you which failure you have. Any story that explains a decline will fit an aggregate, and the token story fits beautifully.

The first failure is skill shadowing. As the library grows, the agent picks the wrong skill more often. Not because any individual skill got worse, but because the right one now sits next to nine plausible neighbors and the agent reaches for a neighbor. The task fails on the strength of a decision made before any work started.

Picture the three git helpers you have installed. One handles rebases, one writes commit messages, one cleans up branches. Each is fine. Ask for something that touches all three and the agent has to guess which door to open, and if it opens the branch cleaner when you needed the rebase helper, the run is already lost. Nothing in that failure has anything to do with how many tokens the other two were sitting on.

The second failure is context overhead. The agent selects correctly, does the right work with the right skill, and still performs worse than it would have with a smaller library, because carrying all that extra material degrades execution. This is the effect the pruning advice is built on. This is the passenger.

Shadowing grows with library size and drives the loss. Context overhead, in the authors' own description, is small and indistinguishable from zero.

Sit with that for a second, because it is the whole piece. The cost you spent an evening cutting was measured, by people who were specifically looking for it, and it came back at roughly nothing. The damage was in the decision. Every skill you deleted made the decision slightly easier, which is why the evening felt productive, and none of it had much to do with tokens.

The authors are direct about the conclusion. The primary bottleneck is skill selection failure rather than the enlarged context. That sentence is worth reading twice if you have ever recommended a skill audit to a teammate, because the audit was probably good advice delivered with the wrong reason attached, and the reason is what determines whether the next audit helps or hurts.

Why It Happens, and Why It Is Not a Mistake

Here is where the two halves snap together, and it starts with a design decision that was correct.

Agent Skills use progressive disclosure. Anthropic described the mechanism in October 2025: at startup, only the name and description of each installed skill get loaded into the system prompt. The full SKILL.md is read later, once the agent judges the skill relevant to what you asked for. Bundled files load later still. The guidance to skill authors that comes with it is to pay special attention to the name and the description, and now you can see why.

This is why an idle skill is nearly free. It is also exactly what the shadowing paper measured. The two findings are not in tension, they are the same fact seen from two directions: the reason your unused skills cost you almost nothing is that almost nothing about them is loaded.

Follow the consequence. If the body of the skill is not in context at selection time, then the selection decision is made from one line of text. Your agent is choosing between everything you have installed using a sentence each.

If you publish skills, reread that last sentence as a job description. Most descriptions in the wild are written to be found by a person browsing a list, which is a marketing job. The job they are actually doing is routing, for a model that will never see the rest of your file before it decides. Those two pull in opposite directions. The marketing version wants to sound broadly capable. The routing version has to be narrow enough that your skill loses cleanly when it is the wrong tool, and writing a description that volunteers to lose is a strange thing to ask of anybody, which is roughly why so few of them do.

SkillRouter (arXiv 2603.22455, latest revision 2026-07-20) measured what that costs. Routing on names and descriptions while the skill body stays hidden loses 37 to 44 percentage points of routing accuracy compared to routing with all fields available, tested against a registry of roughly 80,000 skills. Writing better descriptions helps and does not close it: descriptions distilled from the body still land 7 to 21 points below full-field routing. And the purpose-built router in that paper, which beats every baseline they tested, tops out at 74.0 percent Hit@1. Best case, at scale, with a system designed for exactly this job, the correct skill fails to be the top pick about one time in four.

So name the trade honestly. Progressive disclosure is what makes it possible to install a hundred skills without paying for a hundred skills, and that is a real and valuable property that a lot of people would not give up if you offered. The bill for it arrives at selection time. The same choice that made skills cheap made selection blind, and both of those are consequences of one reasonable engineering decision rather than evidence of a blunder. There is a cheap version of this post that treats it as a gotcha. The honest version is more useful, because if you understand the trade you can work with it, and if you think it is a bug you will just sit around waiting for someone to fix it.

The Part Where the Pruners Were Half Right

Pruning helps. It just helps for a different reason than the one printed on the label.

When you delete a skill, you remove whatever tokens it cost, which is close to zero. You also remove a candidate that could have been picked instead of the right one. Delete three variations on a git helper and you have not reclaimed a meaningful amount of context, you have removed two chances to grab the wrong helper. Hand-pruning is a crude version of the correct fix, which is why people do it, feel a real difference, and credit the tokens.

This is the most durable kind of wrong explanation, the kind that comes with evidence attached. The prescribed action works. The person who took it got a better agent and has the receipts. Nothing about that experience contains any information about which mechanism produced it, and there is no way to tell from the inside, which is why the framing spread through a community of people who are otherwise pretty rigorous. They were not being lazy. They ran the experiment, it came back positive, and the only thing wrong was the label on the variable.

Two findings keep this from collapsing into a tidy moral about curating more. SkillsBench (arXiv 2602.12670, February 2026) found that curated skills raise average pass rate by 16.2 percentage points across 11 domains, with a spread so wide the average barely describes it: plus 4.5 points for software engineering, plus 51.9 for healthcare. In the same evaluation, 16 of the tasks came out worse with curated skills than without them. Curation is not a monotonic good and it does not distribute evenly across the work you actually do.

That spread deserves a second look before you generalize from the headline figure, because plus 4.5 and plus 51.9 are not the same result reported twice. If your work looks like software engineering, the honest expectation from that evaluation is a modest lift, and most of the enthusiasm about curated libraries is being generated by domains that are not yours.

Addition has the same problem from the other side. SkillsInjector (arXiv 2605.29794) reports that injecting more skills does not reliably improve task completion, and that treating which skills to expose, how many, and how to present them as a decision to be optimized beats the strongest baseline they compared against.

Both directions have a wrong end. Adding until the library is comprehensive breaks it. Cutting until the library is minimal breaks it differently. Count was never the variable.

Overlap, Not Count

Here is the rule that replaces the chore, and it takes about ten minutes.

Open your skill list. Read only the descriptions, one line each, the way your agent reads them. Ignore the total. What you are looking for is pairs: two skills whose descriptions could plausibly answer the same request. Not similar categories, not adjacent topics. Two lines of text that a reasonable reader could confuse when deciding which one to run.

Those pairs are what is costing you accuracy. A library of 202 sharply distinct skills is a healthier animal than a library of 40 with twelve overlapping variants, which is the opposite of what count-based pruning tells you. When you find a pair, you do not necessarily delete one. Sometimes the fix is to rewrite both descriptions until each one says the job it does and the job it does not, and if you author skills, that sentence is now the most load-bearing thing you ship.

Then there is the finding that reframes the whole problem, and it is the sharpest one in the set. A retriever can land on the right capability family and still hand back the wrong member of it. SkillResolve-Bench (arXiv 2606.10388) built a benchmark of 661 helpful and risky skill pairs against a pool of 7,982 candidates and found that a risky sibling showed up in the top three roughly 69 percent of the time, and because that pool was deliberately constructed out of helpful and risky pairs, that is a stress-test rate under adversarial conditions and nothing like what you would see across an ordinary library. Read it as a demonstration of the failure mode, not as a forecast for your setup. The retrieval worked. It found the right neighborhood. It just could not tell the twins apart.

Which is roughly the position you are in at 11 PM with two skills open in two tabs, both claiming to do the same job, both READMEs competent, both star counts respectable. Nothing in either description tells you which one falls over on the third call. The one thing that would tell you is somebody who ran both.

That is what a directory is for once selection is the bottleneck. Not breadth. Disambiguation, inside a category, between siblings that claim the same job. Ratings and reviews are selection aids, and selection is the part the research just isolated as the thing that breaks. If you want to see how your own overlapping pairs stack up against each other, browse by category on Clelp and read what people said after they ran them.

And if a skill survived your audit tonight, add your rating next to whatever is already there. Somebody is going to be staring at that same pair next week.