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 hit your secrets. A skill can run arbitrary 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 applies here. Probably more, because skills run with the developer’s full agency. A bad skill doesn’t fail loudly. It just quietly does the wrong thing in fifty pull requests.
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.
The Architecture
The system has three layers, and it maps onto the same shape as the standards work you’ve already done.
Layer 1: The Registry. A single 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 (superpowers, voltagent, others), and 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.
Layer 2: The Installer. A script 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.
Layer 3: The Bootstrap Skill. This is the piece that makes it actually 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.
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.
That is what infrastructure does. It removes humans from the critical path.
Why This Is Governance
This isn’t just a developer-experience nicety. It’s supply-chain discipline.
Skills execute code. They read your repos. They touch your credentials. They issue commands on your behalf. The moment a developer installs a random skill from a random marketplace, your security posture has changed, and you didn’t review it. That’s the same maturity gap as letting developers install arbitrary npm packages, NuGet feeds, or pip libraries with no central oversight. We solved that for traditional dependencies a decade ago. AI tooling is in the early-2010s phase right now.
The curated marketplace is your supply chain. The registry is your allowlist. The pull request review is your control. None of this is exotic. It’s the same governance you already apply to every other piece of third-party code that touches your codebase. Apply it to skills, because skills are exactly that kind of code.
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.