ClawHub Claws

Sharing a single skill is easy, and sharing a whole working agent is not. A Claw is the ClawHub answer to that gap, a versioned package that describes one complete OpenClaw agent together with the reusable resources it needs. It is explicitly experimental, and the boundary between what the registry does and what your own installation does is drawn with unusual care. Reading that boundary first makes the rest of the format obvious.

What a Claw packs

• A publishable Claw is an ordinary package directory whose package.json points at a manifest file, and that manifest opens with grouped YAML frontmatter while its non-empty Markdown body is the portable agent prompt that OpenClaw applies, byte for byte in UTF-8, as the managed soul file of the new agent.
• The frontmatter groups the agent identity, the workspace files to place, the skill and plugin packages to install with an exact version each, the MCP servers and the cron jobs, and every workspace source must name a file that ships inside the same package.
• JSON manifests remain compatible but carry no Markdown body, so an equivalent prompt has to be declared explicitly as a bootstrap workspace file, and combining a non-empty Markdown body with an explicit soul destination is rejected as an ambiguous dual source.
• Assets such as schemas, templates, examples and images are portable ordinary workspace files that belong under folders such as assets, schemas or templates and must be declared in the workspace list, while package names and versions must match package.json, dependency versions must be exact and MCP environment values must stay unresolved variable references.

ClawHub stores and scans the package; OpenClaw owns local preview, consent, apply, update, and removal.

Build, verify, publish

The publish path for a Claw is deliberately narrow. You validate the source project and build a deterministic artifact with OpenClaw, preview that exact artifact without uploading it, then publish it through the existing authenticated package flow. Experimental Claw publication accepts only an already-built archive, never a source folder and never a GitHub checkout. The CLI sends the local artifact digest with the request, ClawHub verifies it against the uploaded bytes before publication, and the same digest comes back through both the pending and the final responses. Publication rejects a missing, invalid or escaping manifest path, a source folder instead of a built archive, package identity or version mismatches, a missing or mismatched expected digest, malformed frontmatter or manifest fields, a non-empty body combined with an explicit soul destination, missing workspace source files or portable path collisions, invalid bootstrap instructions or harness profiles, the retired configuration pointer, floating skill and plugin versions and resolved MCP credentials. Accepted packages then continue through the existing ownership, moderation, static scanning, release and artifact storage pipeline. The stored release keeps the exact artifact plus a non-sensitive summary for later search and detail surfaces. Downloads return those same bytes and the same digest, and the full manifest is never duplicated into the backing store.

Two independent gates

• Claw publication is experimental and the ClawHub deployment must switch on its experimental Claws setting, because otherwise the server simply rejects publication.
• That registry gate is independent from the OpenClaw consumer gate, so hosting does not enable local preview or installation and enabling the OpenClaw CLI does not enable ClawHub publication or hosted discovery.
• While the registry gate is disabled, explicit Claw family filters are rejected, unscoped list and search results omit Claws, named Claw reads return not found, and the hosted Claw feed route returns a 404 and is not advertised in the registry discovery document.

A Claw is less a new kind of code than a way to pin the pieces an agent already uses, which is why its package list names skills and plugins with an exact version rather than a range. For the pieces it reuses, see OpenClaw skills and The ClawHub marketplace.

Why the boundary sits there

The split between the registry and the local installation is the whole design. ClawHub stores, verifies and scans the artifact, while preview, consent, apply, update and removal stay with OpenClaw, and the documentation states plainly that the registry does not bypass that preview or consent boundary. The same instinct shapes what the public API returns, since list and search results use the normal package summary fields while detail responses may add a bounded manifest summary reporting agent identity, portable resource counts, harness profile count, OpenClaw profile count and native extension count without exposing manifest or profile contents. Full manifests stay inside the exact artifact and are never projected through public release responses. Harness profiles follow the same rule from the other direction, because ClawHub validates the common shape and checks the OpenClaw profile against the shipped consumer contract but does not interpret foreign profiles, and each harness discovers only its own. Bootstrap presence is reported in the bounded catalog summary while its contents never are. For the two halves either side of that boundary, read OpenClaw plugins and Agent sandboxing next.

On Diali

Diali runs hosted OpenClaw, where each customer has their own assistant and the runtime configuration is generated from the dashboard and replaced at each release. Channels are connected from that dashboard, and agent 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 the hosted setup and Diali pricing for the plans.

• A Claw pins a whole agent, not a single skill.
• Publication takes a built archive verified by digest, nothing else.
• Two gates: one on the registry, one on your own install.