ClawHub quickstart

Most first sessions with ClawHub stall in the same place, on the question of which command belongs to which job. The registry ships two entry points that look interchangeable and are not: OpenClaw is the consumer and the clawhub CLI is the publisher. Once that line is clear the rest of the workflow is short.

Installing from the registry

• Skills are searched and installed from OpenClaw itself, with openclaw skills search for discovery, openclaw skills install for a named slug, and openclaw skills update --all to refresh everything at once.
• OpenClaw records where a skill came from, so a later update can continue to resolve it through ClawHub rather than guessing at its origin.
• Plugins follow the same shape through openclaw plugins search, openclaw plugins install and openclaw plugins update --all.
• A plugin install takes a clawhub: prefix when you want OpenClaw to resolve the package through ClawHub rather than npm or another source.

Use OpenClaw when you are installing things into OpenClaw. Use the clawhub CLI when you are signing in, publishing, managing your own listings, or using registry-specific workflows.

Signing in to publish

Publishing starts with the separate clawhub package, installed globally through npm or pnpm, followed by clawhub login and clawhub whoami to confirm the session. A headless environment that cannot complete a GitHub sign-in uses an API token from the ClawHub web UI instead, passed to clawhub login as a token, which is also the shape a CI job wants.

Publishing a skill

• A skill is a folder with a required SKILL.md file and whatever supporting files it needs, published with clawhub skill publish and a slug, a name and a changelog.
• The command skips unchanged content, so a re-run after no edits is harmless: new skills start at 1.0.0 and later changes publish the next patch version automatically, with a dry run to preview and an explicit version when you want to choose.
• A repository holding several skills does not need a script of its own, because the reusable GitHub workflow calls skill publish for each immediate skill folder under the skills directory.

A plugin is published through a different command and a stricter contract. Code plugins must carry OpenClaw compatibility metadata in package.json, including the plugin API version they were built against, and the publish command accepts a local folder, a GitHub repo, a GitHub ref or an existing archive. Preview it with a dry run first, which resolves the package metadata, the compatibility fields, the source attribution and the upload plan without publishing anything. For the two package kinds in detail, read How ClawHub works and then What ClawHub checks before publishing.

Look before you install

Before installing anything, inspect it. The web page and the CLI detail commands both expose metadata, source links, versions, changelogs and scan status, and public listings show the latest scan state, which is the single most useful signal on the page. Releases held or blocked by moderation may be hidden from search and install surfaces until the problem is resolved, so an absence is information too. For what the scanner is looking for, see Reporting a ClawHub vulnerability and OpenClaw security best practices.

On Diali

Diali hosts OpenClaw, so the consumer half of this workflow is already installed and signed in when you arrive. Each customer runs their own assistant, the runtime configuration is generated from the dashboard and replaced at each release, 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.

• Install with OpenClaw, publish with clawhub.
• Declare the environment variables, tools and permissions in SKILL.md so a reader knows the cost before installing.
• Read the scan state on the listing before the install, not after.