Akshay Katyal published a confession this month. His team built a skills library for their agents, watched it grow to 96 skills across a single plugin, and then deleted 93 of them in one pull request. Every deleted skill had zero invocations in the prior 60 days. The library had become something nobody planned and nobody owned: a second codebase, running in parallel to the real one, with all the liabilities of code and none of the discipline.
His phrase is the one worth keeping. “A catalog that only ever grows isn’t the good sign it looks like.”
Most teams read a growing skills catalog as momentum. More skills, more leverage, more captured knowledge. Akshay’s data says the opposite. Growth without retirement is not a healthy signal. It is debt accumulating in a place your tools refuse to look.
A Second Codebase You Forgot to Govern
When you ship application code, the whole apparatus of software engineering applies. Version control. Code review. Tests. Linters. Deprecation cycles. Owners. The machinery exists because everyone agrees code rots and someone has to maintain it.
A skills library is also code. It has logic, dependencies, assumptions about the world, and behavior that other systems rely on. But it slips past the apparatus. Skills get added through a quick PR or, often, a single commit by a single author. Akshay reports that across a shared marketplace of 600-plus skills spanning roughly 80 plugins, about half the catalog is exactly that: one commit, one author, never touched again.
That is the shape of an ungoverned codebase. Write-once, review-lightly, maintain-never. The difference is that nobody calls it a codebase, so nobody assigns it the maintenance budget a codebase demands.
The Rot You Cannot See in the Diff
Here is what makes skill decay genuinely dangerous. It does not show up in version history.
Application code rots visibly. A function breaks because someone changed its caller, and the change sits in a commit you can point to. You can git blame the decay. With skills, the file never changes. The skill that worked perfectly in March still has the same bytes in June. What changed was everything around it.
The external API the skill wraps shipped a new version. The model under the agent got better and no longer needs the hand-holding the skill provides, or worse, the skill’s instructions now actively fight the model’s improved defaults. The codebase the skill operates on got reorganized, so the paths and conventions it assumes are quietly wrong. The decay is real, and none of it appears in the diff. The skill’s context rotted while the skill itself sat still.
This is the trap. Your normal instincts for finding stale code all key off change. You look at what was recently modified, what has churn, what is throwing errors. A rotting skill triggers none of those signals. It just sits there, fully present in context, consuming tokens, nudging the agent toward instructions that no longer match reality. We wrote about codebase decay in slow-down-agent-decay. This is its sibling: the second codebase decays the same way, but with even fewer alarms, because the second codebase has no test suite watching it.
Skills in Context Are a Cost, Not a Library
There is a comforting mental model that says unused skills are harmless. They sit on a shelf. If nobody calls them, they cost nothing. Pay it no mind.
That model is wrong for the same reason a cluttered context window is wrong. Skills do not sit inertly on a shelf. Their metadata loads into the agent’s working context so the agent knows they exist and when to reach for them. Every skill in the catalog is a small, permanent tax on every decision the agent makes about which skill to use. Ninety-three dead skills are ninety-three distractions the agent must consider and reject. As we argued in passive-context-ai-agents, the context an agent carries shapes its behavior whether or not you invoked it on purpose. A dead skill is passive context with a negative return.
So the catalog that only grows is not free storage. It is a rising floor of noise. Each addition makes the agent’s selection problem marginally harder, and the marginal cost is invisible until the day someone measures invocations and discovers that 97 percent of the library is dead weight.
Nobody Owns the Deletion
The deepest problem is not technical. It is about authority.
Creating a skill is a celebrated act. Someone solved a problem, captured the solution, and made it reusable. There is a name on the commit and a small dose of credit. Deleting a skill is the opposite. It is unglamorous, mildly risky (what if someone needed that?), and produces no visible win. So the create side of the ledger has many eager authors and the delete side has none.
This is why Akshay’s 93-skill deletion is the actual story, not a footnote to it. Someone had to claim the authority to delete. Someone had to decide that zero invocations in 60 days meant a skill was dead and that dead skills leave. Most organizations never assign that authority to anyone, which is exactly why their catalogs only grow. A garbage collector is not a person who hates skills. It is the function that reclaims what is no longer reachable. Software runtimes automate it because manual memory management is where the leaks live. Skill libraries have no such automation and, in most teams, no human playing the role either.
How to build skills well is a solved-enough problem. How they die, and who signs off on the funeral, is the unsolved one. The build side has taxonomies, templates, and best practices. The retirement side has nothing, which is why retirement does not happen.
Do This Now
You do not need a framework. You need an owner and a metric.
Instrument invocations. If you cannot answer “how many times was each skill called in the last 60 days,” you are flying blind and every other step is guesswork. Counting is cheap. Start there.
Name the owner of deletion. One person or one role holds the authority to retire skills, and retiring a dead skill is treated as a contribution, not a loss. Put it on the same footing as creating one.
Set a default policy. Akshay’s threshold is a fine starting point: zero invocations in 60 days flags a skill for review, and the burden of proof sits with keeping it, not removing it. Review the flagged list on a schedule, not when the catalog finally hurts.
Read your growing catalog correctly. A skills library that only adds and never removes is not a trophy case. It is a second codebase accruing debt your diff will never show you, until someone runs the numbers and deletes 93 things at once.
This analysis synthesizes We Accidentally Built a Second Codebase (Akshay Katyal, June 2026).
Victorino Group helps teams put a lifecycle and an owner on their agent skill libraries. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation