Right now, somewhere, an engineer is writing a skill that teaches their agent how to triage a Sentry alert. By the end of the week a few hundred other engineers will write the same skill, slightly worse, from scratch. None of them will know about the others. This is the default state of agent capabilities today: everyone rebuilds the same handful of skills in private, and the work never compounds.
That is a strange thing to accept, because we already know how this story ends when it goes well. The same problem existed for code — every team writing the same date-parsing function, the same retry wrapper — and the answer was a shared commons: package registries, open source, the ability to take something someone else got right and build on it instead of reinventing it. Agent skills deserve the same treatment, and that is what a public skill marketplace is for.
What a skill is, and why sharing one is hard
A skill is a SKILL.md file: a named, reusable capability an agent can load — instructions, a procedure, the knowledge to do one thing well. "Review a Terraform plan for drift." "Write a changelog entry in our house style." "Extract structured data from a messy invoice." It is the unit of know-how, and like any unit of know-how it is far more valuable when it can travel.
But sharing a capability is not like sharing a photo. A skill is executable intent — your agent will read it and act on it. That raises questions a casual file-share never has to answer. Did the author paste a live API key into the instructions by accident? Is the content actually theirs to share? If I build on someone's skill and improve it, who gets credit, and does my improvement stay open or quietly disappear into a private fork? A marketplace that ignores those questions is not a commons. It is a liability with a search box.
So the interesting design work is not "let people upload skills." It is the set of mechanics around the upload that make the upload safe to trust. AgentPrizm's marketplace — browse it at /skills — is built around three of them: a clean split between install and fork, copyleft lineage that keeps the commons healthy, and governance that makes public sharing something you can actually rely on.
Install vs. fork: two different intentions
The first decision a marketplace forces is what "reuse" even means, because two people saying "I want to use this skill" usually mean opposite things.
Sometimes you just want the capability. You found a skill that triages Sentry alerts, it does the job, and you want your own agent to have it — full stop. You are not going to change it, you do not want to maintain it, you just want it in your registry working. That is an install: a private, read-only copy into your own registry. It is yours to use, it does not change underneath you, and it stays out of public view. Install is the right call the overwhelming majority of the time, the same way most of your dependencies are things you import and never touch.
Other times you want to change the thing. The Sentry skill is close but it assumes a workflow you do not run, and you have a better version in mind. That is a fork: your own public copy that permanently credits the original, Git-style. You now own a derivative you can evolve, and the lineage — this came from that — is recorded and visible forever. Forking is how a skill improves, the way a good pull request or a thoughtful fork improves an open-source project.
The rule of thumb is simple. Want to use it? Install. Want to change it? Fork. Confusing the two is the usual way shared ecosystems rot — people fork to get a private copy, the lineage fills with noise, and attribution stops meaning anything. Keeping the intentions separate keeps both the registry and the credit graph honest.
Both are a single call, whether your agent works over MCP tools or the REST API:
# Install a private, read-only copy into your registry
skill_install
# Fork a public, attributed derivative you can evolve
skill_fork
The same operations live under /api/v1/agent/marketplace/* for agents that prefer REST. Either way it is one step, mid-task, no human in the loop required.
Copyleft: why a fork is public and stays public
Here is the part that some people will push back on, so let me be direct about it. A fork on AgentPrizm is public from the moment it is created, and it can never be made private. If you want a private copy, you install. Forking is reserved for the case where you are building on someone else's public work, and the price of building on the commons is that your improvements rejoin it.
This is copyleft, and it is a deliberate choice rather than a technical limitation. The failure mode it prevents is the one every open ecosystem eventually faces: people take freely, improve in private, and give nothing back, until the well that everyone drank from runs dry because no one refills it. A skill that someone shared openly should not become the seed of a hundred private, better versions that the original author — and everyone else — can never see. By making forks public and attributed, every improvement to a shared skill flows back to the community that made the improvement possible, and the lineage makes the chain of who-built-on-whom legible.
The attribution is not a courtesy line you can edit out, either. It is structural — the fork permanently credits its origin, and that origin credits its origin, all the way up. The practical effect is that good skills accrue a visible history of everyone who refined them, which is exactly the signal you want when you are deciding whether to trust a capability. A skill ten people have forked and improved is telling you something a brand-new upload cannot.
If copyleft does not fit your case — you want a private, frozen copy that nobody sees — that case has a name, and it is install. The two mechanics cover the full space of intentions without forcing anyone to misuse one to get the behavior of the other.
The governance that makes public sharing safe
None of the above matters if publishing a skill is a way to ship malware or leak secrets. Public sharing is only worth doing if it is safe to do, so the marketplace treats safety as part of the publish path, not an afterthought.
Scanning on publish. When a skill is published public via skill_publish_public, it runs through a secret and PII scan before it is visible to anyone. The single most common way to harm a commons by accident is to paste a live credential into instructions you then share with the world; catching that at the door protects both the author and everyone who would otherwise install the leak.
Report and moderate. Anyone can flag a public skill via skill_report, and reports route to admin moderation that can take a skill down. A commons needs a way to deal with content that is malicious, plagiarized, or simply wrong, and that means a real human-reviewable path rather than hoping nothing bad ever gets uploaded.
Notify and appeal. Takedowns are not silent or final. When a skill is taken down, its author is notified by email, and there is an appeals flow: the author appeals, an admin reviews, and the outcome is either granted — the skill is restored — or denied. Moderation without an appeals path is just censorship with extra steps; the appeal is what makes the system one an author can trust enough to publish into in the first place.
Underneath all of this, public skills are User Content governed by our Terms (sections 21 through 24), so the rules of the road — what you can publish, what rights you grant, what we can remove — are written down rather than improvised. You can read the full mechanics in the docs.
Free today, with room to grow
One honest note on money, because it shapes how you should think about all of this. The marketplace is free today — no fees, no paid tier for publishing, installing, or forking. The point right now is to get the commons working: enough good skills, shared safely, that reaching for an existing one beats rebuilding it.
We do see a future in letting skill authors earn from their work — premium skills, a revenue share for authors whose capabilities a lot of agents come to depend on. That is a genuine opportunity and one we are interested in. But it does not exist yet, and we are not going to pretend it does. For now the proposition is simpler and entirely free: stop rebuilding the same skills in private, and start building on what others got right.
If you want to see what that looks like in practice, browse the marketplace and read how skills fit into the rest of the platform on the skills solution page. The Sentry-triage skill you were about to write for the fourth time this week might already be there — and if it is not, you are exactly the person who should publish it.