The catalogs got huge. The team problem stayed the same size.

The numbers are impressive. Let’s appreciate them for a second.

ClawHub — OpenClaw’s community skill registry — has 44,000+ skills. They cover everything from Kubernetes deployment to Slack bot orchestration, contributed by a community of 1,600+ developers. You can search, browse, install, and you’re running a new skill in minutes.

Hermes Atlas maps 100+ open-source tools, skills, plugins, workspaces, and integrations across 12 categories. The Hermes ecosystem has spawned projects like SkillClaw (705 stars), hermes-workspace (500+), and mission-control (3,700+ stars for fleet management).

skills.sh has thousands of skills from publishers like Vercel, Prisma, Supabase, Stripe, and Coinbase, with support for 55+ agents.

GitHub’s gh skill indexes skills across GitHub repositories with provenance tracking, immutable releases, and version pinning.

Two years ago, “agent skill” was barely a concept. Today there are more skills available than most teams will ever evaluate, let alone adopt. Discovery — the problem of finding a skill that does what you need — is thoroughly solved, multiple times over, by multiple well-funded players.

So why is your team still copy-pasting files between directories?

Discovery vs. distribution vs. team coordination

The skill ecosystem has three layers, and the industry attention has concentrated heavily on the first two.

Layer 1 — Discovery. Finding skills. ClawHub, Hermes Atlas, skills.sh, gh skill search. Massive catalogs, good search, publisher partnerships. Solved.

Layer 2 — Individual distribution. Getting a skill onto one developer’s machine. openclaw skill install, hermes skill add, npx skills install, gh skill install. Multiple good CLIs that download a file and place it in the right directory for the agent you’re currently running. Solved.

Layer 3 — Team coordination. Getting one skill, correctly formatted, to every agent your team uses, and keeping it in sync when someone improves it. Not solved. Barely addressed.

This isn’t because layer 3 is unimportant. It’s because layers 1 and 2 are the natural products of the companies building them.

ClawHub is built for OpenClaw. It indexes OpenClaw-formatted skills, installs them into OpenClaw’s skills/ directory, and assumes the consumer is an OpenClaw user. That’s exactly what it should do — OpenClaw is building for its ecosystem.

Hermes Atlas is built for Hermes. It maps the Hermes ecosystem, links to Hermes-compatible tools, and assumes the consumer runs Hermes Agent. Again, correct — Nous Research is building for Hermes users.

skills.sh is the most agent-agnostic of the bunch, supporting 55+ agents. But even there, the unit of distribution is one developer installing one skill. There’s no concept of a team library, no mechanism for ensuring your five-person team is all running the same version, no way to re-emit a skill in different formats for different agents simultaneously.

Each catalog solves the problem for its platform, for one user, at one point in time. The team problem — many agents, many people, ongoing sync — is a different shape entirely, and the catalog architecture isn’t built for it.

The format gap between catalogs

Even if you’re willing to do the manual work, moving skills between ecosystems isn’t just a copy operation.

A ClawHub skill assumes OpenClaw’s conventions: user-invocable and disable-model-invocation frontmatter flags, requires.env for environment variables, install specs declaring dependencies by package manager (brew, node, go, uv). The description field is doing real work — it’s the only thing OpenClaw reads during discovery before deciding whether to load the skill. Directory names must be snake_case and match the name field.

A Hermes skill assumes a different structure entirely: version, author, license, and platform support in frontmatter. The body follows prescribed sections — ## When to Use, ## Prerequisites, ## How to Run, ## Procedure, ## Pitfalls, ## Verification. The skill lives in ~/.hermes/skills/ under a category subdirectory. It’s optimized for Hermes’s progressive disclosure model and its self-improving update cycle.

A skills.sh skill leans toward the Agent Skills standard but includes compatibility metadata for specific agents — and notes in its compatibility matrix that features like context: fork and allowed-tools are agent-specific and silently no-op elsewhere.

A gh skill artifact carries provenance metadata — source repo, git ref, tree SHA — baked into the frontmatter for auditability. It’s version-pinned to a tag or SHA with immutable releases.

These aren’t minor differences. They’re different philosophies about what a skill file should contain, how it should be structured, what metadata matters, and where it should live. A skill authored for one ecosystem doesn’t just “work” in another — it loads in a degraded state, missing the fields or structure that its target agent relies on.

The ClawHavoc lesson

There’s a security dimension here too. In early 2026, researchers discovered the “ClawHavoc” campaign — 341 malicious skills published to ClawHub that contained hidden behaviors and prompt injections. The skills looked legitimate, had plausible descriptions, and installed cleanly. The malicious payload was buried in the instruction body where casual review wouldn’t catch it.

ClawHub addressed this, and Hermes’s closed learning loop sidesteps it entirely (skills are created by the agent from its own experience, not installed from an external catalog). But the incident highlights something important: when your team installs skills from multiple sources across multiple agents, the governance surface area multiplies.

Which versions are running? Who installed what? Has anyone reviewed the content? When the answer is “each person installed their own copy from whatever source they preferred, into whatever agent they’re running, and nobody has a central view” — that’s a governance gap.

A team library with one canonical source at least gives you one place to review, one version to audit, and one update path when something needs to change.

What the team layer looks like

The catalogs are good at what they do. ClawHub for OpenClaw discovery, Hermes Atlas for the Hermes ecosystem, skills.sh for the broadest agent coverage, gh skill for provenance-tracked individual installation. Use them. Browse them. Find skills there.

But when you find something your team needs — or when you write your own team conventions — the question becomes: how does this reach everyone, in every agent, and stay current?

That’s the gap Botdocs fills. Not a bigger catalog. Not a competing registry. A team library where you maintain one canonical skill and it re-emits in every agent’s native format: OpenClaw’s expected frontmatter and path, Hermes’s structured sections and category directories, Claude Code’s SKILL.md, Cursor’s .mdc rule, Copilot’s .instructions.md, and beyond.

When you improve the skill — or when Hermes’s learning loop surfaces a better version — one botdocs sync updates every copy across every agent for every team member. A new hire pulls the whole team library on day one instead of asking “which skills do I need and where do I install them?”

What Botdocs doesn’t do is replace the catalogs. Discovery is their job, and they’re good at it. What Botdocs does is the thing the catalogs aren’t designed for: taking one skill and making it land correctly — right format, right path, right frontmatter — in every agent your team uses, and keeping it there as the skill evolves.

44,000 skills on ClawHub is an achievement. Getting the five that matter to your whole team, in every agent they run, kept in sync as those skills improve — that’s a different problem. It’s the team problem. And it’s the one worth solving next.