ClawHub explained
How the OpenClaw registry turns a skill folder or a plugin package into a public listing with versions, metadata, scan status and install signals that OpenClaw can resolve again at update time
Most of the trust you place in an agent extension is decided before it ever runs. ClawHub is the registry layer for OpenClaw skills and plugins, so it is the surface on which a package is described, versioned and checked in public. A listing collects the things that would otherwise be scattered across a repository, a release page and somebody's private notes. Reading one properly takes a couple of minutes and replaces a great deal of guessing.
What a listing holds
- Each public listing is a registry record carrying an owner and a slug or package name, one or more published versions, metadata, a summary, files and source attribution, changelog and tag information such as the latest tag, download, install and star signals, and security scan and moderation status.
- A skill is a versioned text bundle centred on its SKILL.md file that can also carry supporting files, examples, templates and scripts, and ClawHub reads that file's frontmatter to learn the skill name, description, requirements, environment variables and metadata.
- Plugins are packaged OpenClaw extensions for which ClawHub stores package metadata, compatibility information, source links, artifacts and version records, and a package record can include API compatibility, a minimum gateway version, host targets, environment requirements and artifact digests.
- Publishing creates a new immutable version record, publishers drive it through the registry CLI, dry runs preview the resolved payload before upload, and the public page afterwards surfaces the published metadata, files, source attribution and scan status.
The listing page is the canonical place for users to inspect what a skill or plugin claims to do before installing it.
From listing to install
Installing is where the metadata stops being decoration. OpenClaw install commands use ClawHub as a package source for both skills and plugins. When OpenClaw installs a plugin from ClawHub it checks the advertised compatibility metadata before installing, which is why that metadata belongs in the package record rather than in a readme. Using an explicit ClawHub install source is how you say that the registry, and not some other resolver, is the source of truth for that package. OpenClaw then records install source metadata, so a later update can resolve the same registry package instead of drifting to a different one. The registry CLI also supports direct skill install and update workflows for people who want registry-managed skill folders outside a full OpenClaw workspace. Accurate metadata matters at both ends of that path, because it helps users decide whether to install a skill and helps automated scans detect mismatches between declared and observed behaviour. The habit worth forming is simple: read the listing first, install from the registry source second, and let the recorded source carry the update.
Scans and moderation
- ClawHub is open to publishing, but releases remain subject to upload gates, automated checks, user reports and moderator action, so an open registry is not an unchecked one.
- Public pages show scan summaries when they are available, and content that is held, hidden or blocked may disappear from public search and install flows while remaining visible to its owner for diagnostics.
- ClawHub exposes public read APIs for discovery, search, package details and downloads, and third-party catalogues may use them when they link back to the canonical ClawHub listing, respect rate limits and avoid implying endorsement.
The two package kinds are read differently by the registry. A skill is judged mainly on the frontmatter it declares, while a plugin is judged on the compatibility metadata it advertises before the install runs. For the detail of each kind, carry on to How OpenClaw skills work and then How OpenClaw plugins work.
Why it is built this way
A registry can either promise that everything on it is safe or make it cheap to check. ClawHub takes the second route, staying open to publishing and putting upload gates, automated checks, user reports and moderator action around that openness rather than in front of it. That is also why a listing page carries source attribution, files and scan summaries instead of a badge, because inspection beats assurance when anyone can publish. Holding, hiding or blocking content while keeping it visible to its owner applies the same idea to enforcement, since a publisher still needs to diagnose what happened. The public read APIs extend the pattern outward on conditions that keep the canonical record intact, namely linking back to the listing, respecting rate limits and not implying endorsement. The rest of the picture sits next door in ClawHub security and moderation and Configuring OpenClaw.
On Diali
On Diali each customer runs their own assistant, and the runtime configuration is generated from the dashboard and replaced at each release. Channels are connected from that dashboard, and state lives on a persistent volume, with daily snapshots and one-click restore available through the Backups add-on (included on Max). See Hosted OpenClaw on Diali for what the hosting includes and Diali pricing for what it costs.
- A listing page is for inspection, not decoration.
- Install from the registry source so updates resolve back to it.
- Open publishing plus gates, scans, reports and moderators.
Stop reading about it, build one
Set up an agent, pick a channel, and have it working inside the app you already keep open.
