The Skill-Hoarding Tax

mattpocock/skills is trending again. David Ondrej's skills repo went viral. Five of the top fifteen repos on GitHub Trending are agent skill packs or config collections. The skill-sharing gold rush that we tracked in "Agent Skills Are the New Dotfiles" has only accelerated — and with it, a counter-signal that the accumulation crowd does not want to hear.

📖 Read the full version with charts and embedded sources on AgentConn →

The backlash landed in the same news cycle as the gold rush.

Nick Nisi, a developer experience engineer at WorkOS, stood on stage at AI Engineer Europe and delivered the most expensive lesson of 2026: he had generated 10,000 lines of agent skills from the WorkOS documentation, and one of those skills dropped his CLI agent's task accuracy from 97% to 77%. His fix was not to tweak. It was to delete. He removed 95% of the skills, kept 553 lines of handwritten gotchas, and watched eval time fall from 68 minutes to 6.

The thesis is simple and, by now, well-supported by data: curation is the skill, not accumulation. Every loaded skill is context tax paid on every turn. A lean, task-matched skill set does not just cost less — it performs better than a hoarded one.

The Context Tax Nobody Reads the Bill For

Here is the part that viral skill repos do not put in the README.

When you install a skill pack, what actually happens at the system level? In Claude Code, each skill's name and description loads into the context window at session start. That listing competes with your conversation, your request, and every other skill for the model's finite attention budget. A developer audit on Dev.to measured the cost directly: with 117 installed skills, roughly 7,300 tokens are injected every single turn — about 3.6% of a 200K context window consumed before the user has typed anything.

View original article on Dev.to →

That is the listing tax alone. Once a skill actually fires, its full body enters context and stays there through compaction. Reference materials bundled inline (not in separate files) pour even more tokens into the window. And the cost is not just financial — it is attentional.

⚠️ The attention budget is zero-sum. Every token of skill instructions competes with your actual conversation for the model's attention. Research on long-context models consistently shows degraded performance in the "lost in the middle" zone — and that is exactly where your 40th skill's instructions land.

The r/ClaudeAI community has been reporting the downstream effects. One practitioner reported that exceeding roughly 15 active skills causes escalating context exhaustion — the agent becomes progressively slower to reason about which skill applies, and selection gets noisier. Another audit found that approximately half of installed skills never auto-activated at all, contributing an estimated 23,000 tokens of dead weight per session.

The debate is playing out on Hacker News too, where practitioners are splitting into camps:

View discussion on Hacker News →

The Research Is In: More Instructions Make Agents Worse

This is not just practitioner folklore. Three independent research efforts in 2026 converge on the same conclusion.

The SkillReducer Study (55,315 Skills Analyzed)

The most comprehensive study is SkillReducer (arXiv:2603.29919), a collaboration between HKUST, Tsinghua, and partner institutions. The researchers analyzed 55,315 public agent skills and found that many are so verbose they actively harm performance:

• 48% mean compression rate achievable on skill descriptions without functional loss
• 39% mean reduction in body tokens
• 2.8% improvement in functional quality after compression — meaning the bloated originals were worse than their compressed versions
• 26.4% of skills lack routing descriptions entirely, creating dead weight that the agent cannot even select correctly

View original article →

Antoine Buteau's analysis of the SkillReducer findings put it bluntly: "Context is not free — it costs money, it consumes scarce input budget, and it changes what the model pays attention to." The skill body is the bigger token problem, and reference material can quietly dominate the context budget.

The ETH Zurich Study (Agent Files Reduce Success Rates)

A February 2026 study evaluated whether repository-level context files (AGENTS.md, CLAUDE.md) actually help coding agents. The finding surprised many: LLM-generated context files actively reduced agent task success rates while inflating inference costs by over 20%. Theo Browne covered the study in a video that has been viewed roughly 290,000 times, arguing that agent files are "almost like a band-aid solution."

ℹ️ The nuance matters. Hand-written, well-scoped instruction files do help — a separate 124-pull-request study found that a well-scoped AGENTS.md cut median agent runtime by roughly 29% and output tokens by about 17%. The problem is not instruction files. The problem is the impulse to accumulate rather than curate.

The Addy Osmani Audit (100 Repositories)

Addy Osmani's "Audit your Agent files" report, published August 2026, examined 100 popular repositories and found the hygiene problem is already endemic:

• 62% had lint-related instruction leakage (rules the model already follows by default)
• 42% showed measurable context bloat (instructions exceeding the useful threshold)
• 35% had skill leakage (skills installed but never invoked)

View original article →

Osmani's prescription is aggressive: periodically delete your CLAUDE.md, your skills, and your hooks — then rebuild from scratch with only what you can justify. The Hacker News response was immediate — practitioners lined up with their own audit results:

View discussion on Hacker News →

The Hacker News thread on Osmani's audit drew sharp reactions from practitioners who had already lived the problem:

View discussion on Hacker News →

Anthropic Already Proved the Point — With Its Own Product

The most authoritative data point comes from Anthropic itself. In July 2026, Anthropic's context engineering team disclosed that they had removed over 80% of Claude Code's system prompt for its newest models with no measurable regression on coding evaluations.

💡 From the Anthropic team: "We found that we were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills." Detailed review and verification playbooks were moved into separately loaded skills that fire only when relevant — progressive disclosure instead of upfront loading.

Thoughtworks Technology Radar validated the pattern in two complementary entries. "Agent Instruction Bloat" landed as a Caution item in April 2026, warning that instruction files tend to grow until they are "long, contradictory, and stale." In November 2026, "Progressive Context Disclosure" was promoted to Adopt — the highest recommendation tier.

View on Thoughtworks Radar →

The message from both the platform vendor and the industry's most respected advisory body is the same: less instruction, loaded later, produces better results.

The community response to Anthropic's disclosure was telling — practitioners immediately started auditing their own skill sets:

View discussion on Hacker News →

The Contrarian Corner: "Skill Count Doesn't Matter"

⚠️ The counter-argument. Some developers argue that only skill names and descriptions load at session start, so having 200 skills installed costs almost nothing. The harness shortens or drops descriptions when the budget overflows. And you can raise the budget via skillListingBudgetFraction.

This argument is half-right — and the half it gets wrong is the half that matters in production.

Yes, only the listing loads at boot. But the listing itself has a cost that scales linearly with skill count. More critically, once a skill fires, its entire body enters the context window and persists through compaction. If your skills have reference materials pasted inline instead of pointing to bundled files, a single activation can inject thousands of tokens that stay for the rest of the session.

The MindStudio team coined the term "context rot" for this pattern: skill files that grow past usefulness, flooding the context window and degrading quality over time. Their recommendation — keep skills as lean operating procedures and load supporting material only when the task needs it — aligns precisely with what the research shows.

View original article →

The real cost is not at boot. It is the cumulative tax across a multi-turn session where skills fire, bodies load, references expand, and the model's attention is pulled further from the conversation that actually matters.

The Operator Playbook: How to Audit and Prune

Knowing the problem is cheap. Fixing it is where the value lives. Here is the concrete playbook, synthesized from the research and the practitioner reports.

Step 1: Measure What You Actually Use

Before deleting anything, know what fires. Run /context in Claude Code to see what loads at session start. Track which skills auto-activate across a week of real work. Nick Nisi's approach was rigorous: he ran every prompt twice — once with the skill in the system prompt and once without — then scored the difference. One of his skills scored -12%, meaning the agent performed worse with it loaded.

The metric that matters: tokens consumed per turn, measured by counting the skill listing and any loaded skill bodies against your context window budget. If a skill's token cost exceeds its measured improvement, it is costing you performance.

Step 2: Apply the Deletion Test

For each installed skill, ask three questions:

1. Has it auto-activated in the last 30 days? If not, it is dead weight. Delete it or move it to an on-demand slash command.
2. Does the model already know this? Newer models have internalized many coding best practices. Anthropic found that 80% of their own instructions were redundant with the model's training. Your lint rules, your "write tests first" instruction, your "use TypeScript strictly" reminder — the model probably already does these. Test it.
3. Is the body self-contained? If a skill pastes reference documentation inline instead of pointing to a bundled file, it is a context bomb waiting to fire. Refactor it: move references into references/ and let the skill load them on demand.

Step 3: Compress What Remains

The SkillReducer research showed that even skills worth keeping can usually be compressed by 40-50% without functional loss. The key insight: most skill bloat comes from over-explained edge cases and redundant examples. Write your skills like error messages — short, specific, actionable.

Before:

## Code Review
When reviewing code, always check for the following issues:
- Security vulnerabilities such as SQL injection, XSS, and CSRF
- Performance issues like N+1 queries, missing indexes, etc.
- Error handling — make sure all errors are caught and handled
- Test coverage — ensure important paths are tested
...
(200 more lines of enumerated checks)

After:

## Code Review
Review for: correctness, security (OWASP top 10), performance
(N+1, missing indexes), error handling, test coverage.
Flag blockers with red, suggestions with yellow.

The model knows what "OWASP top 10" means. You do not need to enumerate all ten.

Step 4: Structure for Progressive Disclosure

The Thoughtworks Radar "Adopt" recommendation is progressive context disclosure — load instructions only when the task needs them. In practice, this means:

• Lean SKILL.md files with operating procedures only (target: under 100 lines)
• References in references/ directory — loaded when the skill activates, not injected upfront
• Subagent delegation for heavy workflows — run complex skills in their own context window instead of polluting the main session
• Hooks and deterministic checks instead of instructions — if the rule can be enforced by code, it should be

ℹ️ The 553-line benchmark. Nick Nisi's final skill set was 553 lines of handwritten gotchas — down from 10,000 lines of generated documentation. That is a 95% reduction with a measurable accuracy improvement. Use that ratio as a sanity check: if your combined skill footprint exceeds 1,000 lines, you are probably over-instructing.

What the Skill-Sharing Repos Should Learn

The repos driving the gold rush — mattpocock/skills, davidondrej/skills, obra/superpowers, and the dozens of smaller collections — are not the problem. Skill sharing is genuinely useful, and the open-source ethos behind it is good for the ecosystem.

The problem is that these repos are optimized for installation, not for curation. A new user clones the whole pack, installs all 20 skills, and never measures whether their specific workflow benefits. That is how you end up with 7,300 tokens of overhead per turn on a 200K window.

View on PostHog →

What would help:

• Per-skill benchmarks — show measured impact on common tasks, not just descriptions
• Recommended subsets — "for web development, install these 4" instead of "install all"
• Conflict detection — flag skills that overlap or contradict each other
• Token cost labels — show the context footprint of each skill (listing + body + references)

Until skill repos ship these features, the curation burden falls on you. And the research is clear: carrying that burden — auditing, measuring, and pruning — pays for itself in faster sessions, lower costs, and better output quality.

The Bottom Line

The skill-hoarding tax is real, it is measurable, and it compounds. Every token of skill instructions that does not earn its keep is a token stolen from your actual conversation. The gold rush of 2026 gave us a library of powerful tools. The discipline of late 2026 is learning which ones to leave on the shelf.

Anthropic deleted 80% of its own instructions. Nick Nisi deleted 95% of his skills. The SkillReducer team proved that compressed skills outperform bloated ones by 2.8%. Thoughtworks moved progressive disclosure to Adopt.

The signal is unanimous. The fastest agent is not the one with the most skills. It is the one that loads exactly what it needs, when it needs it, and nothing else.

---

For more on the agent skills ecosystem, see our coverage of the skills marketplace race, the supply-chain risks of skill sharing, and the tokenmaxxing pattern.

Originally published at AgentConn