Good work that cannot spread, and content nobody can account for
Two states, and most organisations are in both at once.
- Somebody built something that works. It lives in their own CLAUDE.md, a personal upload or a one-off directory, and every version of "how do I give this to everyone else?" has died on contact with security.
- The same skill has been written three or four times, because nobody could find the first one and nowhere was allowed to be the answer.
- Content came in from outside carrying no record of its origin, licence or version, and reached an agent holding production credentials with nothing in the way.
- Nobody can say afterwards where a given instruction came from, or who let it in.
A catalog, not a skills folder
One instance per organisation, holding everything your agents and your people are allowed to use.
Skills
Commands
Agents
Hooks
MCP servers
Plugins
Bundles
Submitted, checked, approved, and then everywhere
The loop is the product. A member submits, the rules run before a human is involved, an administrator approves, and every agent surface picks it up without an operator doing anything.
A member of your organisation offers a skill, a command, an agent, a hook, an MCP server or a plugin to the catalog.
Hands on: a candidate
The rules run before anyone reads it. Provenance must be declared or the build fails. Licence eligibility is enforced per distribution tier and fails closed. The file is checked against the catalog’s own rules, each finding naming the rule it broke.
Hands on: a verdict
An administrator reviews it. Today that review is a pull request in your own repository and the approval is its merge — audited, attributable, and in a system your engineers already trust.
Hands on: a merge
The entry lands in your git repository, and the catalog is served from one pinned commit of it. What an agent reads is an exact version with a name on it.
Hands on: a commit
Every connected surface picks the change up through its own adapter. Nobody copies a file anywhere, and nobody has to be told to re-sync.
The rules run before a human is involved
Provenance is declared or the build fails. Licence eligibility is enforced per distribution tier, and it fails closed rather than warning and continuing. The file is validated against the catalog's own rules, and every finding names the rule it broke and where that rule came from.
The same checks run in the contributor's browser before they open a pull request, so a file is fixed while it is still theirs rather than after CI rejects it. The file never leaves the browser to be checked.
Fail-closed is the whole point. Advisory checks are a report nobody reads.
One approved source, reaching the places git cannot
Claude Code. The catalog repository is added as a plugin marketplace, and the instance is added as an MCP server at /mcp/skills. Claude Code sees the entries as skill:// resources.
Any MCP host. One endpoint, OAuth with the platform's public client. A registry that distributes through a package manager cannot reach a host that only speaks MCP; this serves both from the same approved source.
A command-line interface and a Terraform provider are coming. Neither exists today, and this page will not pretend otherwise.
Your repository, not our copy of it
The catalog is served from a commit of a repository you own, in a documented format.
The source of truth
Your git repository holds the entries. The catalog serves one pinned commit of it rather than a synchronised copy.
The instance
Your own deployment at your own hostname, with its own OAuth audience and its own repository — a separate deployment, not a namespace inside a shared system.
The whole thing, if you want it
The platform deploys inside your own infrastructure and runs on your Kubernetes. Self-hosting is an option, not an enterprise upsell.
A second copy of your content somewhere else
There is no registry holding a duplicate of your entries, and nothing to reconcile when the two drift. If OpsHero went away tomorrow, what you would still have is a git repository you own in a format that is written down.
We are customer number one
OpsHero runs its own instance in production, serving its own catalog to its own engineers' agents. It is the same product described above, not a demonstration build.
entries served from one pinned commit — 212 skills, 39 commands, 13 agents and 21 plugins
Source: the live OpsHero instance, 20 September 2026
Three ways this arrives
What it costs depends on which of these you want and how much of the catalog already exists, so the page does not print a number it has not agreed.
Hosted
We run your instance.
- Your own deployment, your own hostname, your own OAuth audience
- Your repository stays the source of truth
- Upgrades and operation are ours
Self-hosted
You run the whole platform.
- Deploys inside your own infrastructure, on your Kubernetes
- Configured per organisation rather than forked
- For estates where nothing leaves the perimeter
With an engagement
We build the catalog with you.
- For an organisation whose problem is that it has nothing worth governing yet
- An AI Champion or Forward Deployed Engineer works with your team
- The honest starting point for most companies
The ones people actually ask
Why not just use pull requests, when we already have CODEOWNERS and CI?
For engineers, pull-request review does most of this, and where it does we do not argue. What it cannot do is let somebody who does not commit to repositories submit or approve, express licence tier or a subscription to a verified vendor, reach the surfaces git cannot reach, or tell you what has gone stale.
What happens to us if OpsHero goes away?
You keep a git repository you own, in a documented format, with every entry and its history in it. That answer is the reason the source of truth is your repository rather than our database.
Can this run in our own infrastructure?
Yes — the whole platform, on your Kubernetes, configured per organisation. Self-hosting is a first-class option rather than an upgrade.
Will curating this eat a quarter?
It can, and pretending otherwise would not survive the first week. If your corpus is large and nothing in it may be deleted, that is a consulting problem before it is a product one and we would rather say so on a call. The engagement exists for exactly this.
What is actually in the catalog — only skills?
Skills, commands, agents, hooks, MCP servers, plugins and bundles. The assumption that this is a skills-only product is the most common thing we correct.
See it running, with a catalog in it
A real instance, a real catalog, and an agent connecting to it during the call. Then the part that matters: what it would take to point it at your repository.
- The live catalog and what is in it
- What connecting your first agent involves
- Whether you have enough to govern yet, including when the answer is no