Where SkillHub sits in the agent-skills stack: collection → harness → registry

[FenjuFu]

Where SkillHub sits in the agent-skills stack: collection → harness → registry

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 this project. SkillHub 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 simply 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)

The useful consequence of these being separate layers is that they compose, and we have deliberately built toward that rather than toward lock-in:

• Same format. SkillHub speaks the same SKILL.md layout, 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 (compat/ClawHubCompatController) so existing ClawHub-style registry clients keep working against a SkillHub deployment. Native CLI APIs are the primary interface; the compat surface is there so nobody has to rewrite a client to try this.
• A generic, harness-neutral install target. CLI 0.1.9 added installation into the user-level ~/.agents/skills directory, usable on its own or alongside agent-specific locations such as ~/.codex/skills and ~/.claude/skills, with canonical-path checks to stop conflicting destinations. This one matters more than it looks: .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

We are not trying to 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.

Open threads — please don't open a new issue for these

Two of the obvious follow-ups already have live threads, and we would rather have the discussion concentrated there than spread across duplicates:

• Importing/syncing skills from community-format Git repos → #516
• Skill-as-Code directory layout + semantic versioning → #540

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.md frontmatter 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. Drop them in this thread with the two versions involved and we will try to reproduce.