ClawHub acceptable usage

Marketplace policies usually read as a list of forbidden topics, which is why they age badly. ClawHub's is built the other way round: it judges what a listing does and how it presents itself, so the same subject matter can pass or fail depending on the framing around it.

What is welcomed, and on what condition

• Developer productivity is allowed when the listing helps users build, test, migrate, debug, document or operate software.
• Interface, data and automation workflows are allowed when the scope is clear, required credentials are explicit, and risky actions carry a review, dry-run, preview or confirmation path.
• Defensive security and abuse-review tooling is allowed when it is framed for authorised review, preserves evidence and keeps human approval boundaries clear.
• Personal and team workflows are allowed on consent-based accounts with transparent setup, and catalogues are allowed when each listing is distinct, accurate and reasonably maintained.

Context matters. The same topic can be acceptable in a narrow defensive or consent-based setting and unacceptable when packaged as an abuse workflow.

The line the policy actually draws

Read the allowed column again and every row has a condition attached, which is the whole design. Nothing on it is permitted because of its topic; each is permitted because of a property, clear scope, explicit credentials, a confirmation step, consent, maintenance. The disallowed list is its mirror image, covering content whose main purpose is abuse, deception, unsafe execution or rights infringement.

The categories that catch honest people out

• Hidden or misleading execution requirements: obfuscated install commands, pipe-to-shell installers without clear reviewability, undeclared secret or private-key requirements, or metadata that hides what the listing really needs to run.
• Rights infringement: republishing someone else's skill, plugin, documentation, brand assets or proprietary code without permission, violating licence terms, or impersonating the original author.
• Spending or charging tools without a clear human approval step, which sits inside the fraud category even when nothing about the tool is fraudulent.

The first of those is worth dwelling on, because a pipe-to-shell installer is normal practice in much of the ecosystem and is still disallowed here. The test is reviewability: a user has to be able to see what will run before it runs. For how to declare that properly, see The ClawHub skill format, and for what the scanner does with it, Reading a ClawHub security audit.

Behaviour is policed too

The policy does not stop at content. How publishers use discovery, install and trust surfaces is reviewed separately, and manipulating discovery, metrics, trust signals, moderation systems or user attention is a violation in itself. Bulk-publishing large numbers of low-effort, duplicative, placeholder or machine-generated listings without real user value is named outright, as is flooding search or category surfaces with near-identical entries. A technically clean skill can still breach the policy purely through how it is published. See ClawHub moderation and account standing for what happens next and What ClawHub checks before publishing for the checks at upload.

On Diali

Diali hosts OpenClaw, and a policy that keeps the registry clean is the reason an assistant can install from it at all. Each customer runs their own assistant on isolated infrastructure, 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.

• The policy judges packaging, not topic.
• Reviewability is the test for an installer.
• Bulk low-effort publishing is abuse on its own.