One developer on your team has forty skills installed from six different marketplaces. They installed the latest one yesterday. They aren’t sure what half of them do anymore, but the firehose feels productive.
Another developer hasn’t updated anything in two months. They got their CLI working once. They aren’t about to mess with a setup that works. New skills exist for everyone else.
A third developer wrote a skill that does something brilliant. It saves them an hour a day. Nobody else has it. They posted about it in Slack once. The Slack message scrolled away.
These are three different developers, and they are all symptoms of the same problem. Your org has no infrastructure for skill distribution. Skills are just files on individual machines, picked by individual taste, updated on individual whims.
Enterprise AI needs curated tooling the same way enterprise code needs standards.
The Curation Problem
Public marketplaces ship constantly. Superpowers, voltagent, and dozens of others release new skills every week. Some of them are excellent. Some of them are half-baked. Some of them conflict with the standards your team agreed to last quarter. Most of them, frankly, are written by people you have never met and probably never will.
Telling every developer “go pick the ones you like” is the same anti-pattern as telling every developer “go decide what counts as good code.” You tried that. It didn’t work. That’s why you have standards in the first place.
The reflex when people hear “curated marketplace” is to assume it’s about restriction. It isn’t. It’s about an enterprise having SOPs in a world where the tools themselves are now distributed software with privileged access. A skill can read your repo. A skill can touch credentials. A skill can run commands inside your CLI. That is not a category of thing developers should be installing from strangers based on a screenshot in a tweet.
The same governance you apply to npm packages, NuGet feeds, and Docker images belongs here too. Probably more, because skills run with the developer’s full agency. A bad package usually breaks at build time or runtime. A bad skill can quietly write the wrong pattern into fifty pull requests before anyone notices the common source.
This is not theoretical. In June 2026, CSO reported on AIR research showing that a fake AI agent skill reached more than 26,000 users after passing security checks. The skill appeared credible because it was accepted into a popular open-source agents repository and was marked safe by multiple scanners. The risky behavior did not live in the submitted files. It lived behind an external domain the skill told agents to trust, and that external content could change after installation.
Snyk’s ToxicSkills research found the same shape of problem at ecosystem scale. Snyk scanned 3,984 agent skills from ClawHub and skills.sh and reported that 534 contained at least one critical security issue, 1,467 had at least one security flaw, and 76 contained confirmed malicious payloads. The issues included prompt injection, malware distribution, exposed secrets, unsafe third-party content, and unverifiable external dependencies.
OWASP now treats this as its own agentic-skills risk category. AST01 is “Malicious Skills,” with Critical severity and all platforms affected. The OWASP guidance is blunt about why this is different from old dependency risk: malicious skills can attack through code and through natural-language instructions that tell the agent what to do.
That is the security problem in one sentence: the thing you approved yesterday may not be the thing your agents execute tomorrow.
A curated marketplace says: this is the shelf. These are the skills your org has decided are appropriate to run inside your codebase. You can use anything on the shelf. Adding to the shelf is a pull request.
That makes the curated marketplace part of your supply chain. The registry is your allowlist. Pull request review is your control. None of this is exotic. It is ordinary software governance applied to AI tooling.
The Architecture
The system has three layers, and it maps onto the same shape as the standards work you’ve already done.
A single registry file, call it plugins.json, lives in a shared internal repo. Your .github-private is the natural home. It lists every marketplace your org has blessed, plus every internal skill, extension, and plugin your org wants distributed. That file is version-controlled. Changes go through pull request review. There is exactly one answer to the question “what skills does our org use,” and the registry is it.
The installer reads the registry and installs or updates every listed item from its source. In our case it’s a PowerShell script, but the language doesn’t matter. What matters is that the script is idempotent, runs locally on each developer’s machine, and produces the same end state every time. Run it once and you have the org’s blessed toolkit. Run it again tomorrow and you have the updated version of it.
The bootstrap skill is the piece that makes the system propagate. The marketplace itself contains a skill whose job is to run the installer and restart the CLI. The marketplace updates itself. A developer says “update my skills” and they are current. No instructions, no documentation page, no Slack thread explaining the script’s path. The skill is the path.
The reason this third layer matters is that it dissolves the gap between “we shipped an update” and “every developer has it.” Without it, distribution is an awareness problem: did everyone see the announcement, did they remember to run the command, and do they even know there was an announcement. With it, distribution is one invocation away. The bar to be current is lower than the bar to be out of date.
The whole system fits in a single repo. The registry is a file. The installer is a script. The bootstrap is a skill that calls the script. Three pieces, no platform engineering team required.
I have this running at my own company. Our internal marketplace distributes a set of skills to developers and other users. The code scorecard skill has seen meaningful adoption because developers can use it to evaluate their work against the same quality lens before code review. The story writer skill is also being used by developers to report bugs they find with enough structure for the work to be actionable.
The marketplace also distributes the update skill itself. That skill runs a PowerShell script that refreshes each user’s local copy of the skills and pulls down anything newly added to the marketplace. The distribution mechanism is part of the distributed toolkit.
Front, Don’t Build
You aren’t trying to replace superpowers or voltagent. You are aggregating them.
The public marketplaces exist. They have skills your developers want. Other people maintain them. The smart move is to point your registry at the ones you trust, treat them as upstream sources, and curate which of their offerings you bring into your shelf.
Your internal layer is additive. It’s where your org-specific skills live: the one that knows your codemap, the one that follows your standards, and the one a developer wrote last week to solve a problem only your team has. Public marketplaces handle the universal stuff. Your internal layer handles the proprietary stuff. The registry combines them.
This is leverage, not ego. The infrastructure is light because someone else built the marketplaces. Your job is curation and an internal shelf, not a competitor product.
Three Devs, One Marketplace
Now go back to the three developers from the top.
The eager developer gets a curated firehose. They can install every skill in the marketplace and trust that each one was vetted before it landed on the shelf. They aren’t restricted, they are accelerated. The friction that used to live in their head (“is this skill safe, does it match our patterns, will it conflict with my other tools”) is now upstream of them. The shelf already answered those questions. They get to play with everything on it.
The heads-down developer gets the latest without seeking it. They don’t follow announcements. They aren’t in the AI Slack channel. They don’t read the wiki. They didn’t need to. They ran the update skill, and now they have everything new. The org’s investment in tooling reaches them automatically, on their next workday, without any social cost. Nobody had to convince them.
The creator gets a path to ship. They built something useful. They want it to matter beyond their own machine. They open a pull request against the registry. A reviewer (a peer, a lead, or an architect, depending on your governance) reads the skill and approves it. The next day, every developer in the org who runs the update skill has it. Their work compounds across the team instead of dying on one workstation. They are now a force multiplier, not a hobbyist.
Three different developers, three different relationships to AI tooling, and the same marketplace serves all of them. That isn’t a coincidence. The eager developer needs a vetted shelf. The heads-down developer needs zero-friction updates. The creator needs a distribution channel. The marketplace is all three at once because they are different views of the same problem: how does the right tool get to the right developer at the right time, without depending on anyone’s attention or memory?
The marketplace turns that problem into infrastructure instead of social coordination.
Closing the Side Door
A curated shelf only works if developers can’t shop somewhere else. Most orgs today (mine included) lean on culture and convenience: the marketplace is the path of least resistance, so devs use it. That works when your developers are mostly the “config once and go” type. It stops working the moment somebody motivated decides to install whatever they want.
When you’re ready to harden, the levers exist. They vary by tool. Some CLIs expose an org-policy hook that lets you pin the skill source. Most orgs already run a corporate proxy or artifact mirror, and extending it to cover marketplace traffic is a small lift on top of infrastructure you have. Filesystem permissions on the skills directory close the manual-copy bypass. The exact mix depends on whether you’re locking down Claude, Copilot, Cursor, VS Code, or all of them.
The point isn’t to pick a control today. The point is to know which controls exist so the conversation can happen on purpose.
Getting Started
If you don’t have an internal skills marketplace yet, the path is short:
- List the marketplaces you trust. Start with the public ones whose skills your developers already use.
- Write the registry. A single file in a shared internal repo. List the marketplaces, the skills, the extensions, and the plugins.
- Write the installer. A script that reads the registry and installs everything in it. Idempotent.
- Write the bootstrap skill. A skill that runs the installer and restarts the CLI. This is the piece your developers will actually use.
- Document the PR path. When someone builds a new internal skill, they open a pull request against the registry. Reviewers approve. Distribution is automatic.
Standards govern what your AI writes. The marketplace governs what your AI can do. You need both.
Receipts
- Malicious skill research: CSO reported that AIR demonstrated a fake AI agent skill that passed security checks and reached more than 26,000 users before the payload behind an external domain was changed. AIR said the research payload collected only user email addresses so affected users could be notified.
- External instruction risk: The CSO report explains that the skill relied on a mutable external documentation domain, which static scanners did not catch because the dangerous behavior was not contained in the submitted skill files.
- ToxicSkills study: Snyk reported that its researchers scanned 3,984 agent skills from ClawHub and skills.sh, finding 534 with at least one critical security issue, 1,467 with at least one security flaw, and 76 confirmed malicious payloads.
- Agent skill risk model: Snyk’s study calls out prompt injection, malware distribution, exposed secrets, third-party content exposure, and unverifiable external dependencies as major skill supply-chain risks.
- OWASP AST01: OWASP’s Agentic Skills Top 10 entry for Malicious Skills assigns Critical severity, marks all platforms as affected, and distinguishes skill risk from traditional package risk because attacks can use both executable code and natural-language instructions.
- Internal marketplace: At a marketing services SaaS provider, my team has an internal marketplace that distributes skills to developers and other users. Adoption is visible around the code scorecard skill and story writer skill, and the marketplace distributes its own update skill that runs a PowerShell refresh script.