A question that keeps coming up from people arriving here after using one of the big skill projects: "I already get my skills from a collection, and my agent already installs them — what does a registry add?"
Fair question. Here is the honest map, written as a landscape rather than a pitch.
Three layers, not three competitors
The agent-skills ecosystem has settled into three distinct layers. Most projects are excellent at exactly one of them.
1. Content — curated collections. anthropics/skills popularized the Agent Skill format itself (a SKILL.md with name / description frontmatter plus supporting files). mattpocock/skills is opinionated taste applied to that format — skills kept deliberately small, composable and model-agnostic, shipped straight from a working .agents directory. Its two install paths are a genuinely interesting design fork: the Claude Code plugin gives you a managed, read-only bundle you subscribe to, while skills.sh copies editable files into your project so you can fork and hack. Subscribe-vs-fork is a real distribution philosophy question, and both answers are defensible.
2. Runtime — the harness. openclaw/openclaw is where skills actually execute: cross-platform, personal-assistant-shaped, shipping a large first-party skills/ tree of its own, with ClawHub as its distribution and publishing path. The harness owns invocation, sandboxing and the user-facing loop.
3. Infrastructure — the registry. That is SkillHub. It is a registry and governance platform, not a skill collection. It answers a different question from the two above: when the skills are yours and private, who may publish them, which version is running in production, who approved it, and what happened last Tuesday?
| Curated collection | Harness | SkillHub | |
|---|---|---|---|
| Owns | The skills and their taste | Execution + the user loop | Hosting, versioning, access control |
| Source of truth | A public Git repo | The local install tree | Your own deployment, behind your firewall |
| Versioning | Git history | Whatever was installed | Semantic versions, beta/stable tags, latest tracking |
| Access | Public | Local | Namespaces, RBAC, review workflow, audit log |
| Distribution | Clone / copy / plugin subscribe | Harness-native install | Full-text search + CLI install |
None of this is a criticism of layers 1 and 2. A registry is the wrong tool for distributing taste, and a curated public collection is the wrong tool for distributing your company's internal deployment runbook to 300 engineers with an approval trail.
The interop already exists — and that's the point
-
Same format. SkillHub speaks the same
SKILL.mdlayout, so a skill from any Agent Skill folder publishes straight into a private registry without repackaging. - ClawHub-compatible endpoints. The server ships a compatibility layer so existing ClawHub-style registry clients keep working against a SkillHub deployment. Native CLI APIs are the primary interface; the compat surface exists so nobody has to rewrite a client to try this.
-
A harness-neutral install target. CLI
0.1.9added installation into the user-level~/.agents/skillsdirectory, usable on its own or alongside agent-specific locations such as~/.codex/skillsand~/.claude/skills, with canonical-path checks to stop conflicting destinations..agents/is quietly becoming the cross-harness convention — it is, after all, the directory the collections themselves are shipped from.
What we are explicitly not trying to do
Out-curate anyone. Skill quality is editorial work and the collections are better at it. If your team's answer is "we just install a public collection and it's great" — that is a complete answer, and you do not need a registry until you have private skills plus someone who has to sign off on them.
The question we actually want answered
If you run skills across more than one harness, we would like to hear about the concrete incompatibilities you have hit — not opinions, but reproducible ones:
- A
SKILL.mdfrontmatter field that one harness requires and another rejects. - A package that validates in one toolchain and fails in another.
- A metadata block a harness needs (invocation hints, permission declarations) that has nowhere to live in the shared format.
Cross-harness skill validation is the part of this problem we have the most direct experience with, and concrete breakages are far more useful than a standards debate.
Discussion thread: https://github.com/iflytek/skillhub/discussions/691
Top comments (0)