Before you install an OpenClaw skill, ask these provenance questions

Published June 15, 2026 · OpenClawBlog Team

A community skill may arrive as one readable SKILL.md file. It may also bring helper scripts, templates, assets, dependency instructions, environment variables, or a command that invokes an existing tool. The short listing is therefore not the artifact. It is an introduction to the artifact.

OpenClaw's skills documentation says to treat third-party skills as untrusted code and read them before enabling them. That wording matters. A package name, a community listing, or a passing scan does not answer who published the exact bytes, what those bytes can reach, or what will change when the package is updated.

This checklist focuses on provenance rather than popularity. The goal is a small record that connects the publisher, source, revision, files, requested access, scan state, and future maintenance path. Documented behavior is identified as such. The trial steps are proposed checks, not tests performed for this article. No live installation or execution is claimed here.

What provenance is supposed to establish

Editorial inference: provenance is the chain between the thing you found and the bytes you will allow into an OpenClaw session. That chain should be short enough to explain on one page: owner, canonical listing, source locator, exact release or commit, file set, declared requirements, installation scope, and update owner. If one link is missing, you may still have a useful package, but you do not have a defensible reason to trust it.

Documented behavior: ClawHub records include an owner and slug, published versions, metadata, source attribution, changelog and tag information, download and star signals, plus security scan and moderation status. A published version is an immutable registry record. The same page describes a skill as a versioned bundle centered on SKILL.md that can include supporting files, examples, templates, and scripts.

That definition gives you the first review question: is the thing being offered really a file-backed skill? If the package also contains openclaw.plugin.json, a runtime entry point, or a native package layout, it may need a plugin review as well. OpenClaw's manifest reference says the native manifest is read before plugin code is loaded, while the project's security policy says plugins run in process with the Gateway and can have the same operating-system privileges as the OpenClaw process. Classification changes the trust boundary.

Questions the provenance record must answer

Who is the publisher, and is the name unambiguous?

Documented behavior: OpenClaw's skills CLI accepts owner-qualified ClawHub references such as @owner/<slug>. Bare slugs remain supported when a skill is already installed or unambiguous, but the documentation recommends owner-qualified references to avoid publisher ambiguity. For Git and local installs, the skill name comes from the name field in SKILL.md when it is valid, then falls back to the directory or repository name.

Proposed check: record the owner-qualified name, listing URL, source repository URL, and the namespace that controls the repository. Compare those values before downloading anything. A repository with a similar name is not the same publisher. Stars, downloads, and a polished README may help discovery, but they do not prove that the account publishing the current release controls the source you inspected.

OpenClaw's moderation guidance treats impersonation and misleading metadata as reportable marketplace problems. An unclear identity is not proof that a skill is malicious. It is a reason to defer until the identity and source can be explained.

Can you trace the listing to the source?

Documented behavior: ClawHub listings expose source attribution and version records. The skills CLI supports ClawHub, Git, and local-directory source forms. The documentation also describes resolver-backed GitHub skills that apply scan and force-install policy before returning a pinned commit.

Proposed check: write down the complete locator you intend to use. For a registry release, keep the owner, slug, and version. For Git, keep the repository and an explicit tag or commit, for example git:owner/repo@<ref>. For a local archive, keep the archive name and a digest if one is available. If you reviewed a repository branch but install a separately downloaded archive, the source chain has a gap.

A branch is a moving pointer. A tag can be moved by a maintainer. A release archive can contain files that are not visible in the README. Editorial inference: the useful question is not whether the source looks official. It is whether another operator could retrieve the same revision you approved.

Which exact release did you inspect?

Documented behavior: openclaw skills verify @owner/<slug> asks ClawHub for a trust envelope. For an installed ClawHub skill, verification uses the version and registry recorded in .clawhub/origin.json. The CLI also accepts --version and --tag selectors. The verification command reads the stored scan result; it does not start a new scan.

Proposed check: save the version, tag or commit beside the copy of SKILL.md and the supporting files you read. Then verify that the selected release is the one you intend to install. If the listing now points to a newer version, repeat the review rather than assuming the difference is harmless. If the installed origin record points to a different registry or release, stop and reconcile it.

This distinction prevents a common mistake: treating a successful verification response as approval of every future version. Verification can establish that a selected release matches a registry record and its stored trust information. It does not make the instructions self-explanatory, and it does not inspect a new release that has not been selected.

Do the description, metadata, and files agree?

Documented behavior: the skill format reference allows a skill to declare required environment variables, binaries, configuration paths, a primary credential, operating-system restrictions, and dependency installation specifications. OpenClaw can also expose a skill as a user-invocable command or dispatch a command directly to a registered tool. ClawHub's security audit checks instructions, metadata, declared environment variables and permissions, install instructions, included files, compatibility data, and capability metadata.

Proposed check: read the complete SKILL.md, then enumerate the files beside it. Look for scripts, package manifests, install commands, downloaded URLs, shell commands, credential names, configuration paths, and references to browsers or messaging tools. Compare what you see with the declared requirements. A skill described as a local formatter deserves a different review from one that asks for an API token, a command-line binary, and unrestricted network access.

Pay attention to omissions without turning them into accusations. An undeclared environment variable may be an authoring mistake. An unexplained installer, encoded payload, or second download deserves a pause because the stated purpose no longer describes the full behavior. The correct response is to ask for an explanation or reject the package, not to invent certainty from a suspicious-looking line.

What authority will the skill inherit?

Documented behavior: OpenClaw filters skills by environment, configuration, binary availability, and other metadata, but the project still tells operators to treat third-party skills as untrusted code. Skill settings can inject an API key or environment variable into the host process for an agent turn; the documentation says that value is not injected into the sandbox. Shared skill libraries also do not create a separate trust domain from the Gateway.

Proposed check: write down the actual host, agent workspace, tools, credential scope, network path, and output destinations that the first run could use. Ask whether the skill needs file reads, file writes, shell execution, browser control, message sending, or a provider account. The skill's instructions may describe a workflow, but the resulting impact depends on the tools and credentials available to the session.

If the package only works when connected to your real mailbox, repository, cloud account, or production channel, the proposed test is too wide. Use dummy data and a separate account where possible. A sandbox can reduce the consequences of a bad run, but it does not turn an in-process plugin into untrusted code, and it does not undo a message or external change already made.

What does the audit result actually tell you?

Documented behavior: ClawHub's security audit guide separates audit status from risk level. Pass means no visible issue above low risk was found. Review means the findings should be read before installing. Warn calls for extra caution. Malicious means do not install. Pending means the audit has not finished, and Error means it could not be completed. Risk level describes apparent blast radius, not whether the package is malicious.

A Pass is useful evidence, not a guarantee. The audit page says the checks focus on whether the name, summary, metadata, requested authority, and actual content line up. That is narrower than proving the absence of every unsafe behavior. A medium-risk publishing skill may be legitimate and still deserve a stricter boundary than a low-risk text formatter.

Proposed check: save the exact status, risk level, findings, details URL, and date. Read a Review or Warn result instead of flattening it into safe or unsafe. Treat Pending and Error as incomplete evidence. The skills CLI documents a force-install path for a pending GitHub-backed skill, but clearing a wait condition is not the same thing as completing the review.

Which installation scope will change?

Documented behavior: OpenClaw installs a skill into the active workspace skills/ directory by default. The --global option targets the shared managed skills directory, which can be visible to all local agents unless allowlists narrow that visibility. An operator-owned security.installPolicy can receive install metadata and the staged source path for ClawHub, uploaded, Git, local, update, and dependency-installer paths, and it fails closed when it cannot return a valid decision.

Proposed check: choose the narrowest scope for the first review. Record whether the skill is per-agent, workspace-wide, or shared. If a policy hook exists, keep its decision and findings with the provenance record. If no policy exists, that is not proof of danger, but it means the review is relying more heavily on the operator's inspection and runtime boundary.

Run the separate openclaw security audit after relevant configuration changes, using the project's security guidance to interpret Gateway findings. That command checks the surrounding deployment posture. It does not replace reading the skill's files or verifying the selected release.

Who owns updates and recovery?

Documented behavior: the skills CLI updates tracked ClawHub installs. Git and local sources must be reinstalled or otherwise refreshed by their source owner. ClawHub's moderation page says a listing can be held, hidden, quarantined, revoked, or removed from public install surfaces, and advises users not to install a hidden or blocked release until the issue is resolved. It also makes clear that ClawHub does not maintain or patch the source code of a third-party skill.

Proposed check: decide what triggers a new review. A new version, changed source ref, new environment variable, new dependency, new command, or expanded permission should reopen the record. Keep the reviewed revision available long enough to compare an update. Name the person or team who can disable the skill, rotate credentials, notify the publisher, and investigate side effects.

Editorial inference: removing a skill file is not the same as undoing what it already did. If a trial can send messages, edit records, publish content, or call a paid API, its recovery plan belongs in the approval decision.

Use the CLI as a record, not an approval button

The current skills CLI exposes documented inspection and verification commands:

info and check help you inspect local metadata and which skills are visible to an agent. verify asks ClawHub for the selected release's trust information and can use the installed origin record. The commands are useful evidence to save beside the source URL. They are not a replacement for reading the files, comparing the declared access, or deciding whether the current Gateway is an appropriate place to run the skill.

For a non-ClawHub source, preserve the source shape you reviewed, such as git:owner/repo@<ref> or a local directory path. Do not copy a source locator from a guide and silently substitute a different repository, branch, archive, or package name.

A proposed disposable trial

The following is a proposed test sequence, not a test result from this article:

1. Save the owner, listing URL, source locator, version or commit, file inventory, metadata, audit state, and intended scope.
2. Use a separate workspace or operating-system account when the source is unfamiliar. Keep production credentials out of the first run.
3. Enable only the smallest tool set needed for one bounded task. Prefer a sandbox for untrusted inputs and risky tools, as OpenClaw recommends.
4. Use dummy files and a predictable output directory. Watch for unexpected file changes, process launches, network requests, credential use, or messages.
5. Compare the result with the task you wrote down. Disable or discard the test environment if the skill reaches beyond that task.
6. Re-review the artifact before expanding its workspace, tools, account access, or update channel.

A clean trial only shows that the chosen example did not reveal a problem under those conditions. It does not prove that the skill is safe with different input, a different prompt, a different tool policy, or a later release.

Failure paths worth treating as stop signs

• The owner-qualified listing, source repository, and package identity do not match.
• You reviewed a branch or archive, but the install points to another revision.
• The package is called a skill but includes a native plugin runtime or an unexplained installer.
• The skill asks for credentials, binaries, configuration, or network access that its description does not justify.
• The audit is Malicious, the listing is blocked or hidden, or the result is Pending or Error without a reason you can resolve.
• The only available test requires a real account, production files, broad shell access, or permission to publish.
• No one owns future updates, credential rotation, incident response, or rollback.

Do not treat --force or --force-install as provenance. They are operator choices that can confirm a source or continue a guarded flow. If a warning exists because the selected release is pending review, the warning is part of the evidence, not an obstacle to hide.

The short rule

Editorial inference: install only when you can answer seven plain questions: who published it, where the bytes came from, which exact revision you read, what the files require, what the audit actually found, where the skill will run, and who owns the next change. If one answer is missing, not yet is a complete security decision.

A community catalog is useful for discovery. Consent begins later, when the source, revision, authority, and recovery path make sense together.

Sources

Sources were opened and checked on September 13, 2026. The OpenClaw documentation pages did not expose publication dates.

• OpenClaw skills documentation
• How ClawHub works
• ClawHub skill format
• OpenClaw skills CLI
• ClawHub security audits
• ClawHub moderation and account safety
• OpenClaw plugin manifest reference
• OpenClaw Gateway security guidance
• OpenClaw security policy