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.
- Your people use three or four different AI assistants. Each one has its own rules about whether skills and MCP servers can be added and by whom, so whatever governance you have covers one of them.
See exactly what your agents are allowed to use
One approved place for everything your agents use
Most teams keep agent skills as files in a folder, copied from one laptop or project to the next. Skills Manager replaces the folder with a catalog.
A skills folder
Files copied by hand into each project and onto each laptop. It holds one kind of thing, nobody signed it off, and nobody can say which version an agent read.
The Skills Manager catalog
One instance for your organisation. It holds skills and everything around them, each entry approved for you, and serves one pinned, approved version to the tools your people connect.
Submitted, checked, approved, and then everywhere
An employee submits, 12 verification and evaluation checks run before a human is involved, an administrator approves, and every agent surface picks it up without an operator doing anything. Further security and quality gates apply, and every skill is graded on a daily schedule.
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
Validation runs before anyone reads the artefact. Provenance must be declared and licence eligibility is enforced. The file is checked against the OpsHero Handbook and your company’s own rules, and each finding names the rule it broke. A security scan and a quality gate apply too.
Hands on: a verdict
An administrator reviews it. Once approved, it is released to the catalog.
Hands on: an approval
Every harness or agent picks up the change through its own tools: a pinned skill version for an agent, Skills over MCP for Codex, the Skills Marketplace for Claude, and so on.
Every skill is checked before it is served
This is OpsHero's own catalog pipeline, as the portal reports it.
12 / 12 gates passing
Every gate runs before content is released.
Secrets
Scanned on every change; HIGH and CRITICAL findings fail the build.
Behavioural grading
Skills are run against test fixtures and graded on what the agent actually did.
Catalog
220 skills, 52 commands and agents.


One validated source. Delivered natively to every harness and agent.
Skills Manager is the single place your organisation publishes skills, MCP servers, hooks and commands. Every entry is validated before release, and each harness and agent receives it in the format it already understands. There’s nothing to convert or wrap.
Claude Code. Installed from the Skills Manager marketplace. Each engineer signs in, and their access follows their identity.
Codex. Served over MCP using Skills over MCP. Codex finds and loads skills through its standard MCP connection.
Claude Teams. Synced into your organisation through Anthropic’s own sync. Skills show up for the whole team without anyone installing them by hand.
Agents. A pinned version of each skill is mounted directly into the agent’s sandbox. The agent runs exactly the version you approved, with no fetching at runtime.
Same approved release on every channel. Validate a change once and it reaches all four the same way.
Yours to keep, even if we disappear tomorrow
Everything in the catalog stays yours, in a documented format.
The source of truth
Your entries stay in your own source of truth. The catalog serves one pinned version of them, not a synchronised copy.
The instance
Your own deployment at your own hostname, with its own OAuth audience – 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, you would still have every entry, in a format that is written down.
The ones people actually ask
What happens to us if OpsHero goes away?
You keep every entry and its history, in a documented format that you own. That is why the source of truth is yours rather than our database.
Can this run in our own infrastructure?
Yes, by arrangement. We deliver the platform into your own Kubernetes; talk to us about what your environment requires.
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 own skills.
- 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



