# ClawHub: the skill registry behind OpenClaw, and how to install skills from it

> ClawHub is the public registry for OpenClaw text skills and native packages, backed by Convex and vector search. It solves discovery and versioning for agent skills, but its CLI and web app are two different surfaces with different rules.

**openclaw/clawhub** — Skill + Plugin Registry for OpenClaw. Uploaded registry skills use soft-delete/restore (clawhub delete / clawhub undelete or API equivalents).

- Repository: https://github.com/openclaw/clawhub
- Website: https://clawhub.ai
- Stars: 9,453 · Forks: 1,487
- Language: TypeScript
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/openclaw-clawhub

## What ClawHub actually registers, and who ends up using it

ClawHub is the public skill registry for OpenClaw. Its unit of content is a text-based agent skill: a SKILL.md file plus supporting files. Around that core it also exposes a native OpenClaw package catalog for code plugins, bundle plugins, and experimental whole-agent Claw packages. The README describes the registry as designed for fast browsing and a CLI-friendly API, with moderation hooks and vector search.

The audience splits cleanly. Skill authors need a place to publish versions with changelogs and tags, including a latest tag, and to fix naming mistakes without breaking existing installs. Consumers need search that is not keyword matching, plus a way to freeze a local install so an update cannot overwrite it. Registry operators need moderation. ClawHub serves all three from one schema, which is why the same repository holds a web app, a Convex backend, and a shared schema package rather than a single service.

The naming detail that trips people up is that ClawHub is not OpenClaw itself. It is the registry OpenClaw clients pull from. The README lists OpenClaw packages as a separate catalog concept from skills, and the CLI keeps them apart too: clawhub skill publish handles skills, while clawhub package publish handles plugins.

## Convex, embeddings, and the schema package that keeps the CLI honest

The architecture is stated plainly in the README. The web app is TanStack Start, built on React with Vite and Nitro. The backend is Convex, which supplies the database, file storage, and HTTP actions, with Convex Auth handling GitHub OAuth. Search runs on OpenAI embeddings using text-embedding-3-small against a Convex vector index. The API schema and routes live in packages/schema, published as clawhub-schema.

That last point matters more than it looks. Because the CLI and the web app share one schema package, the CLI is not a hand-written client drifting away from the server. The repository layout confirms the split: src/ holds the TanStack Start app with routes, components, and styles; convex/ holds the schema, queries, mutations, actions, and HTTP API routes; packages/schema/ holds shared API types and routes. A workspace list in package.json names packages/clawhub, packages/clawhub-admin, and packages/schema.

Vector search is a deliberate trade-off. Embedding-based retrieval handles phrasing that keyword search misses, but it also means the index depends on an OpenAI API key, listed in the environment section as OPENAI_API_KEY for embeddings and indexing. Self-hosting the full stack therefore involves an external embedding provider, not just a database. The README does not describe a fallback to keyword search when embeddings are unavailable.

## Installing the clawhub CLI and running a first install

The README documents the CLI flows rather than a single install command for the binary, and it points to docs/quickstart.md and docs/cli.md for details. What the README does give is the sequence of commands you use once the CLI is present. Authentication comes first: clawhub login for an interactive session, or clawhub login --device for remote and headless environments. You can confirm the identity with clawhub whoami.

```bash
clawhub login --device
clawhub whoami
```

The device flow is the one to use on a remote box or a container, where a browser redirect back to localhost will not resolve. After login, the README's example install command targets a scoped skill name.

```bash
clawhub install @openclaw/demo
```

If you want to look before you install, the README lists an inspect command that does not write to disk.

```bash
clawhub inspect @openclaw/demo
```

Local installs are managed as a set. clawhub list shows what is present, clawhub update --all refreshes everything, and clawhub pin freezes a specific skill so updates and forced reinstalls cannot overwrite it, with clawhub unpin reversing that. Search and browsing are separate entry points: clawhub search for queries, clawhub explore for browsing, and clawhub package explore plus clawhub package inspect for the unified catalog that includes plugins. Note that install telemetry is on by default when you run clawhub install while logged in, and the README gives the opt-out.

```bash
export CLAWHUB_DISABLE_TELEMETRY=1
```

## Local install versus registry state: the delete and uninstall split

The most consequential thing in the README is a permissions note that many users will skim past. clawhub uninstall removes a local install on your machine only. It does not touch the registry. Uploaded registry skills use soft-delete and restore, exposed as clawhub delete and clawhub undelete, or the API equivalents. Packages follow the same pattern with clawhub package delete and clawhub package undelete.

Soft-delete is allowed for the skill or package owner, a publisher owner or admin, moderators, and admins. Hard delete is admin-only and is reserved for management tools and ban flows. This is a sensible design for a registry where old links and installs may still point at a slug, but it produces a real failure mode: a user who wants a skill gone from the registry and runs clawhub uninstall will see the local copy disappear while the listing stays up. The two verbs are not synonyms, and the README separates them for exactly that reason.

Rename and merge follow the same link-preservation logic. An owner rename keeps the old slug as a redirect alias. An owner merge hides the source listing and redirects the old slug to the canonical target. If you depend on a specific slug resolving, both operations preserve resolution, but the target changes underneath you.

## Nix plugin pointers and the config frontmatter

ClawHub stores a nix-clawdbot plugin pointer in SKILL frontmatter so the registry knows which Nix package bundle to install. The README is explicit that a nix plugin differs from a regular skill pack: it bundles the skill pack, the CLI binary, and its config flags and requirements together. The frontmatter example uses a metadata object with a clawdbot key containing a nix object with plugin and systems fields.

```yaml
---
name: peekaboo
description: Capture and automate macOS UI with the Peekaboo CLI.
metadata:
  {
    "clawdbot":
      {
        "nix":
          {
            "plugin": "github:clawdbot/nix-steipete-tools?dir=tools/peekaboo",
            "systems": ["aarch64-darwin"],
          },
      },
  }
---
```

On the consumer side, the README shows the corresponding Nix configuration entry that pulls the same source. Skills can also declare config requirements and an example snippet under a config key, with requiredEnv, stateDirs, and example fields. That is a useful convention because it lets a skill state which environment variables it needs before it runs, rather than failing at first invocation. It is also entirely convention-based: the README describes the frontmatter shape but does not describe validation that rejects a skill whose declared requiredEnv does not match what it actually reads.

## Where ClawHub is the wrong tool

ClawHub is a registry for OpenClaw skills and packages, not a general-purpose package manager. If your artifact is a library consumed by a language toolchain, the shared schema package and the Convex-backed registry give you nothing that your ecosystem's registry does not already provide. The README's own framing is text-based agent skills plus an OpenClaw package catalog, and that is the boundary.

The second boundary is operational. Running the stack locally requires Bun, and the README notes Convex runs through bunx with no global install needed. The detached worktree preview path additionally requires Worktrunk. The environment list includes GitHub OAuth credentials, JWT keys for Convex Auth, and an OpenAI key for embeddings. A local dev loop is therefore not a single binary you start; it is a Convex deployment plus a web app on port 3000 plus seeded fixtures. The README documents bun run seed:dev as the step that waits for the local Convex deployment, runs the dev fixture seed, and refreshes global stats, with fixtures owned by @local and safe to rerun.

A third limitation is documentation coverage rather than design. The README does not document rollback for a published version, and it does not describe what happens to existing installs when an owner merges a skill beyond the redirect. If your workflow depends on either behaviour, the README is silent and you would need the specs directory or the source to answer it.

## How ClawHub differs from a plain git-based skill distribution

The obvious alternative for distributing agent skills is a git repository that users clone and point their agent at. The difference in approach is where the metadata lives. With a git repo, versioning is commits and tags, discovery is whatever you write in the README, and there is no registry-side notion of an owner, a moderator, or a canonical slug. ClawHub puts those in the database: versions carry changelogs and tags including latest, ownership gates who can rename or merge, and moderators and admins can curate and approve skills.

That buys you redirects. A git clone breaks when a directory is renamed; ClawHub keeps the old slug as a redirect alias on rename and redirects a merged source slug to the canonical target. It also buys search that does not depend on the author's choice of words, because retrieval runs through embeddings rather than keywords. What it costs is a dependency on the hosted service and its auth. A git repo works offline and forever; ClawHub's registry operations require a login and a reachable backend. The README also lists a pin mechanism for local installs, which is the closest analogue to checking out a fixed commit, and it exists precisely because the registry can move underneath an unpinned install.

## Conclusion

Adopt ClawHub if you are publishing or consuming OpenClaw skills and want versioned slugs, changelogs, and a CLI that works headlessly. Do not adopt it as a general package manager for non-OpenClaw tooling, and do not treat clawhub uninstall as a registry action. Verify first that your install path matches the registry semantics you expect: run clawhub inspect before clawhub install, and confirm whether you need clawhub delete or clawhub uninstall for the change you are making.

## FAQ

### What is ClawHub for?

ClawHub is the public skill registry for OpenClaw. It publishes, versions, and searches text-based agent skills made of a SKILL.md plus supporting files, and it also exposes a native OpenClaw package catalog for code plugins, bundle plugins, and experimental whole-agent Claw packages.

### How to install skills from ClawHub?

Log in with clawhub login, or clawhub login --device on a headless machine, then run clawhub install with a scoped skill name such as @openclaw/demo. The README also lists clawhub inspect for looking at a skill without installing it.

### How to install the ClawHub CLI?

The README documents the CLI commands and points to docs/quickstart.md and docs/cli.md for setup, rather than giving a single install command in the main file. Once the CLI is available, the first steps are clawhub login and clawhub whoami.

### How to use ClawHub in OpenClaw?

ClawHub is the registry that OpenClaw clients pull from. You authenticate with clawhub login, find skills with clawhub search or clawhub explore, install them with clawhub install, and manage the local set with clawhub list, clawhub update --all, clawhub pin, and clawhub unpin.

### How to use ClawHub skills?

Skills are text-based packs: a SKILL.md plus supporting files, which the web app renders and the CLI installs. The README lists browsing skills, publishing new versions with changelogs and tags, and pinning local installs so updates cannot overwrite frozen copies.

### How to install ClawHub on Ubuntu?

The README does not give a platform-specific install procedure for Ubuntu or any other distribution. It documents the CLI commands and points to docs/quickstart.md and docs/cli.md; the local development path it describes requires Bun, with Convex run through bunx.

## Sources

- [Official documentation](https://clawhub.ai)
- [Official README](https://github.com/openclaw/clawhub#readme)
- [Project repository](https://github.com/openclaw/clawhub)
- [Release notes](https://github.com/openclaw/clawhub/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openclaw-clawhub