Vetting a ClawHub skill before your agent runs it

OpenClaw is a self-hosted personal agent: it runs on a machine you control, talks to you through chat apps and, depending on how you set it up, can act on files, the shell, the browser and your accounts. ClawHub is the public registry where people share skills for it. Installing a skill takes seconds, and that is exactly the problem. A skill is a set of instructions, often with scripts attached, that your agent will follow with all the access you have given it. Treat each one as untrusted code written by a stranger until you have read it. This page is not a list of recommended skills; any such list goes stale, and none can vouch for what you install. It is a review method you can apply to any skill from any public registry. If you are still choosing an agent, see choosing a personal agent and making it reliable.

What a skill is and why it deserves a review

In the format OpenClaw uses, a skill is a folder with a SKILL.md file at its core: a short header with a name and a description, followed by instructions in plain language. The folder may also hold scripts, templates and reference files. The agent reads the description to decide when the skill is relevant and loads the rest when it is. For the general concept, see what agent skills are.

Three things make skills riskier than they look:

• Instructions are executable intent. A sentence such as "before starting, run the setup command below" will be carried out by an agent with shell access. Malicious or careless instructions do not need a single line of code to cause harm.
• Bundled scripts run with your agent's rights. If the agent can read your home directory, so can any script it is told to run.
• Content can change after you install it. A skill that fetches a script from a URL at runtime, or updates itself, can behave differently tomorrow than it did on the day you read it.

Map what the skill can touch

Before installing, download the skill and read every file, not just the description on the registry page. Note what it does under five headings:

A quick first pass from the terminal finds the obvious cases; it does not replace reading:

grep -rnE "curl|wget|base64|eval|chmod|ssh|\.env|token|api[_-]?key|crontab" ./skill-folder

Then compare what you found with what the skill claims to do. A weather skill that reads your mail configuration, or a note-taking skill that wants a payment token, has already told you what you need to know.

Decide permissions separately from the skill

A skill describes what the agent should do. It should never be the thing that decides what the agent may do. Set permissions in the agent's own configuration and keep them narrow, whichever skills are installed:

• Run tool execution in a sandbox or under a separate user account where your agent supports it, with access limited to a working directory.
• Prefer allow lists to block lists for commands and tools. Check which controls your OpenClaw version offers, such as sandboxing and approval prompts for commands.
• Require a confirmation for anything that sends, deletes, pays or schedules.
• Give the agent its own low-privilege credentials, never your personal tokens.
• Keep the agent's configuration and memory files out of reach of skills that have no reason to change them.

The principle is the same one that applies to MCP servers and CLIs: connecting a capability should not, by itself, widen authority. The note on how to connect tools without widening authority develops the idea, and start agents read-only explains why the first version of any new capability should look rather than change.

Check provenance

A registry listing gives you a name and a description. Before trusting it, establish who wrote the skill and whether what you download matches what you reviewed.

• Publisher. Is there a linked source repository and an identifiable maintainer with a track record of other work? A new account with a single popular-sounding skill deserves extra caution.
• Name. Watch for near-copies of well-known skills, one letter off or with an extra word. Typosquatting is an old trick in every package registry.
• Source match. Does the registry package match the repository? Diff the two.
• History. Read the changelog or commit history. Large changes in a minor update, or scripts recently added to a skill that used to be text only, are worth a second look.
• Signals that are not evidence. Download counts, stars and reviews show popularity, not safety. A widely installed skill is also a more attractive target.

Once you have reviewed a version, pin it. Keep a copy in your own repository or configuration so that the code you run is the code you read, and treat every update as a fresh review.

Test on a sample before real use

Reading catches a lot, but behaviour is the final check. Run the skill in a throwaway environment first:

1. Set up an isolated environment: a virtual machine, a container or a separate OS user with a fresh agent profile and no real credentials.
2. Prepare sample data that resembles your real material but contains nothing sensitive, plus a few decoy files holding obviously fake secrets.
3. Run representative tasks the skill is meant for, and a few it is not meant for.
4. Watch outbound network connections, file changes outside the working directory and any new scheduled jobs.
5. Read the agent's transcript. Did it follow the skill's instructions into anything you did not ask for? Were the decoy secrets read or sent anywhere?

If the skill passes, install the pinned version with the narrow permissions described above, and keep an inventory of installed skills with each version and when you reviewed it. Remove skills you no longer use; each one is extra attack surface. For small needs, writing your own is often quicker than reviewing someone else's: turning a CLI into an agent skill shows the pattern.

Where GoCux fits

GoCux treats skills the way this page recommends: a reusable set of instructions grants no permissions by itself. In a GoCux work order, GoCux picks the skills the work calls for, but what the agent may do is set by the order's scope and the company's rules, never by the skill. Consequential actions wait for a person whatever a skill says: sending something out, destroying data, exporting files and scheduling work all stop for a decision, and a change to the agent's own instructions is held for review before it takes effect. Every step, decision and outcome lands on one audit trail. The customer CLI keeps ownership of its local tools and permissions. See agent skills in the docs and the seven action classes that pause for a person.

Review checklist

• You read every file in the skill, not only the registry description.
• You listed the files, commands, hosts, credentials and actions involved, and they match its stated purpose.
• Nothing downloads and runs code at install or run time without your review.
• The publisher and source repository are identifiable, and the package matches the source.
• The version is pinned and a copy is kept under your control; updates trigger a new review.
• The skill ran in an isolated environment with sample data and decoy secrets, and stayed within its purpose.
• Permissions live in the agent's configuration, narrow and independent of the skill.
• Sending, deleting, paying and scheduling still require your confirmation.