Skip to content
Guides

ClawHub publishing

What the registry checks before a skill folder or a plugin package becomes a public release, from owner and scope rules to categories, topics, bundled icons and trusted publishing

7 min read

Publishing is the moment a private folder becomes something other people can install. ClawHub treats it as a validation step rather than an upload, checking that your token can publish for the owner you chose, validating the metadata, name, version, files and source information, then storing the release and starting automated security checks. If validation fails, nothing is published at all. Knowing which rule you are about to break saves a great deal of retrying.

Before you publish

  • Publishing sends a skill folder or a plugin package to ClawHub under the owner you choose, and the registry checks the token, the metadata, the name, the version, the files and the source information before it stores the release and starts automated security checks.
  • Validation is all or nothing, so a failed check publishes nothing, and even a valid new release may stay out of normal install and download surfaces until review finishes.
  • For skills the simplest path is the CLI, where you sign in and publish a local folder, name an org owner explicitly or omit that flag to publish as the authenticated user, and let the tool skip unchanged content, start a new skill at 1.0.0 and publish the next patch version automatically for later changes.
  • Plugins use npm-style package names in which a scoped name carries the owner in its first part, and that scope must match the selected publish owner, so a package sitting in one organisation namespace cannot be published under another.
This prevents a package from claiming an org namespace that the publisher does not control.

Categories and topics

Skill catalog metadata decides where a skill can be found. Categories place a skill in the category filters on the skills browse page, topics become the filter chips offered inside a selected category, and both flags take comma-separated values. Category slugs must come from the fixed list and are matched exactly, so a capitalised spelling of a valid slug is rejected, whereas topics are free-form labels stored as passed and displayed in their normalised form. A skill can carry at most three categories and at most five topics, and both limits count what is left after cleanup rather than what you passed. An unknown category slug fails the publish, and a dry run does not check slugs because the registry validates them when the publish actually runs. The catch-all category is dropped when it arrives alongside a specific one, repeats are dropped after normalisation rather than rejected, each topic is capped at forty-eight characters, and topics cannot contain invisible formatting characters. A list of trust-implying topic names is reserved and rejected on the normalised form, so words such as verified, official, curated and staff pick cannot be claimed as topics. A skill first published without categories is stored under the catch-all, omitting a flag on a later publish keeps the stored values, and passing an empty value clears the field. Passing either flag publishes even when the files have not changed, which means a metadata fix creates a new patch version.

Plugin release rules

  • Before publishing a plugin, pick an owner that matches the package scope, keep the code plugin manifest identifier unique within that publisher's packages, include the OpenClaw plugin manifest, and for code plugins also ship a package manifest declaring the plugin API compatibility and the OpenClaw build version.
  • A custom catalog icon must be a valid PNG of no more than 512 KiB bundled at the reserved asset path in the package root of the published archive, because manifest icon URLs and paths are ignored and missing or invalid artwork falls back to the plugin category glyph.
  • Run the package validation command and then a dry run before creating a release, include source repository and exact commit metadata or publish from a GitHub-backed checkout so the CLI can detect them, and expect a new release to stay out of public install surfaces until automated security checks and verification finish.

Plugin catalog metadata has moved into the manifest, where a code or bundle plugin declares exactly one category or omits the field, in which case ClawHub generates one from bounded package metadata and documentation and falls back to the catch-all when classification is unavailable. The old command-line flags for plugin categories remain accepted but are ignored with a warning, so see Publishing a skill and The ClawHub CLI reference for the paths that still work.

Why the rules are strict

Every rule here protects something specific. The scope rule protects organisation namespaces, because a package named for an organisation claims that namespace and only publishers with access to that owner may publish it. Trusted publishing is a two-step setup for a related reason, since the package is published once through a normal manual or token-authenticated publish, which creates the package row and establishes the managers who may later set a GitHub Actions trusted publisher configuration, and that configured repository and workflow filename must match the OIDC claim. Waiting for publication is the default for real publishes through the reusable workflow, which fails when security checks block or fail the attempt, when the attempt expires or when the thirty-minute publication deadline is reached, and callers may raise that deadline to at most forty minutes. Recovery is deliberately additive, because recovering a failed staged attempt creates a successor with the same retained artifacts and version, runs new security checks and preserves the failed attempt and the original authorisation as audit history. Deleting the trusted publisher configuration is the documented rollback path and stops future trusted publish tokens from being minted until a manager sets it again. Related reading sits in Security audits and Publish workflow configuration.

On Diali

Diali hosts OpenClaw for you, so the runtime configuration is generated from the dashboard and replaced at each release, and each customer runs their own assistant. Channels are connected from that dashboard and state sits 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 runtime and Diali pricing for the plans.

  • Validation is all or nothing: a failed check publishes nothing.
  • The package scope must match the owner you publish as.
  • Categories decide where a skill is found, topics narrow it.
Get started

Stop reading about it, build one

Set up an agent, pick a channel, and have it working inside the app you already keep open.