Nobody Owns Your Agent's Skill Library

Your Agent’s Tools Are Already Running

You probably don’t know how many skills your agents are loading.

If your team uses Claude Code, Codex, or any of the newer coding agents that accept SKILL.md files, MCP servers, or plugin directories, your agents are quietly pulling in instructions from a dozen places. They come from vendors, open-source projects you trusted last quarter, and teammates who thought “this would be helpful” and dropped a folder into the project root.

None of those sources talk to each other.

Right now, your agent might run a skill that says “always use the V2 API” while another skill in the same session says “migrate to V3.” It might blow through its context budget because three different skill files each load the same 2,000-word onboarding guide. You won’t see the conflict until the agent produces a plan that contradicts itself or silently drops a step because it ran out of tokens.

Nobody owns that library. And that is becoming a real operations problem.

Who Keeps Them Honest?

The people who build the tools have no reason to coordinate.

A platform like Medusa publishes a set of development skills as a Claude Code plugin and a separate MCP server with migration prompts for Shopify, WooCommerce, and Magento. They also maintain an ecommerce storefront best-practices skill and a CLI skill. As Shahed Nasser wrote at Medusa, those tools are spread across repositories in different formats. Medusa solved the update problem by treating their documentation as the single source of truth and building automation that triggers pull requests against every skill repository whenever docs change.

That’s good for them. But you are not Medusa. You are assembling skills from a dozen vendors, internal tools, and open-source repos. Nobody is running a notification pipeline for you.

The open-source world is already producing skill package managers. The skillctl project is a local CLI that lists installed skills, checks for conflicts, enforces a token budget, and lets you switch profiles per project. It explicitly says it “doesn’t care where skills come from” and it detects runtimes including Claude Code and Codex. The project has zero stars on GitHub at the time of this writing, which tells you something: people are building the tools because the problem is real, not because there is a market yet.

Skills will only get more scattered as more agent platforms adopt skill-based discovery. Every new MCP server, every new SKILL.md in a repo, every new plugin directory, is another uncontrolled input into your agent’s behavior.

The Context Cost You Are Not Tracking

A skill file is not free. Every description, every instruction, every body word eats from the agent’s context window.

skillctl includes a budget command that sums up the description tokens across all installed skills and exits with code 1 if you exceed a threshold. It warns when a skill body exceeds 5,000 words or 500 lines. Those are artificial numbers, but the principle is not. An agent that loads 15 skills each averaging 300 description tokens plus a few thousand words of body can lose a third of its usable context before it even sees your codebase.

Meanwhile, tools like ripwire are trying to help agents avoid reading whole files in the first place. Ripwire builds a ranked call graph and a test-to-run list so the agent can work from a map instead of grepping around. It indexes a repository in under half a second using a few megabytes. That’s orders of magnitude leaner than a graph-database MCP server. That kind of efficiency is exactly what you want your agent to use. But if your skill library is bloated, you waste that advantage before the agent ever calls ripwire.

The two problems are connected. You can give your agent a fast, low-context tool for understanding the codebase, but you can also drown it in skill instructions that nobody reviewed for overlap or token cost.

What to Do on Monday

Start with an inventory.

If you are using Claude Code, check the skillOverrides in the project’s configuration. If you are using Codex, check [[skills.config]] entries. Look for duplicated instructions, outdated migration guides, and skills that conflict with each other. You can do this manually with a spreadsheet, or you can try a tool like skillctl to automate the list.

Next, pick a single source of truth for your organization’s conventions.

Medusa uses their documentation as that source and propagates changes to every skill repository. You can do something simpler: maintain one canonical SKILL.md that every project inherits, and build a script that regenerates per-project skill files from it. The point is that you need a place where you decide what is true, and all other skill files become derivations, not independent copies.

Finally, set a budget. Decide how many description tokens your agent can afford to spend on skill instructions. Enforce it. When a new skill would push you over the limit, you have to retire an old one. That forces the discipline that no vendor will impose on you.

The agent skill library is a distributed system that nobody designed. It landed on your lap because it was easier than writing custom prompts. But it is now an operational asset, and like any other asset, it decays if nobody owns it.

Nobody owns your agent’s skills today. That means either you do, or chaos does.