Finding and installing OpenClaw skills without getting burned

What are OpenClaw skills?

OpenClaw skills are Markdown instruction files, one folder per skill with a SKILL.md inside, that tell the agent how and when to use a tool. OpenClaw loads them from skills/ in your workspace and from ~/.openclaw/skills/. You install them from the ClawHub registry with openclaw skills install @owner/slug, or from any GitHub repo with npx skills add owner/repo -a openclaw.

Third-party skills are untrusted code. The OpenClaw docs say so directly, and the registry’s history (covered below) shows why. Of the 195 repositories in our catalog, 34 list OpenClaw as a supported agent. None of those 34 came out of our review without notes: 19 are marked “review before installing” and 15 “broad access”.

Where OpenClaw loads skills from

The OpenClaw skills docs list seven locations. When two skills share a name, the higher one wins:

1. <workspace>/skills
2. <workspace>/.agents/skills
3. ~/.agents/skills (default state only)
4. <state-dir>/skills, the managed or local folder
5. <state-dir>/agents/<agentId>/agent/workshop-skills
6. bundled skills
7. skills.load.extraDirs and plugin skills

A SKILL.md is found up to six folders deep, so you can group skills in subfolders. The skill’s name comes from the name field and falls back to the folder name. The skills CLI table lists OpenClaw’s project path as a plain skills/ folder, not a dotted one like .claude/skills/.

The OpenClaw SKILL.md

Frontmatter needs name and description. OpenClaw also reads user-invocable (default true) and disable-model-invocation (default false), which control whether you can call a skill directly and whether the model may pick it on its own. In the body, {baseDir} points at the skill’s folder.

Eligibility is set in a metadata.openclaw block. A skill can require binaries (requires.bins, or requires.anyBins for at least one), environment variables, config paths and an operating system. A skill that doesn’t meet them isn’t eligible. Without the block, it is eligible by default. The older metadata.clawdbot block is no longer read, so skills written for the earlier name need renaming. For sandboxed agents, requires.bins is checked on the host, so the binary also has to exist inside the container.

ClawHub: the OpenClaw skills hub

ClawHub is the public registry for OpenClaw skills and plugins. It tracks versions, tags, changelogs, downloads, stars and security scan summaries. Day-to-day use goes through the openclaw command:

openclaw skills search "calendar"
openclaw skills install @owner/slug
openclaw skills install @owner/slug --global
openclaw skills install git:owner/repo@ref
openclaw skills update --all
openclaw skills verify @owner/slug

--global installs into ~/.openclaw/skills. openclaw skills update tracks only ClawHub installs, so reinstall Git or local sources to refresh them.

A separate clawhub CLI (npm i -g clawhub) handles login and publishing with clawhub skill publish <path>. Run directly, clawhub install puts skills into ./skills and records them in .clawhub/lock.json. When you are logged in, it may send an install event for aggregate counts; set CLAWHUB_DISABLE_TELEMETRY=1 to turn that off.

Skills and plugins are separate things on ClawHub. Plugins install with openclaw plugins install clawhub:<package>, and the docs say released OpenClaw versions through 2026.10.4 need the clawhub: prefix. npm:<package> installs straight from npm. A plugin is code, so it deserves more scrutiny than a Markdown skill. You can look at a skill before installing it with clawhub inspect @openclaw/demo.

Updating, pinning and removing

The clawhub CLI also has pin, unpin, uninstall and list. clawhub uninstall removes only the local copy. On the registry side, deleted skills are soft-deleted and can be restored, and a hard delete is admin-only. After openclaw skills update --all, re-read what changed in anything you depend on.

What happened with ClawHavoc

In February 2026 security researchers reported ClawHavoc, a campaign in which large numbers of malicious skills were published to ClawHub. According to the analyses by Antiy and Palo Alto Networks Unit 42, many of them posed as crypto tools or as “required prerequisites” and delivered infostealers and backdoors. Published counts differ between reports, so we don’t quote one here.

The pattern matters more than the number. A skill that asks you to download and run a prerequisite is asking you to run code that sits outside the file you can read. Our security page lists the checklist we use against it.

The current ClawHub docs describe several safeguards: publishing requires a GitHub account that passes an age-based gate, automated checks run on every release and show their state before install, releases held or blocked by scans can be pulled from public listings, signed-in users can report skills, and moderators can hide content and ban accounts. These are the registry’s own descriptions. They reduce risk and don’t remove it.

Safer settings for third-party skills

OpenClaw gives you controls worth using:

• security.installPolicy can run a trusted local policy command before an install goes ahead.
• Discovery rejects skill roots and SKILL.md files whose real path leaves their folder, unless you allow a symlink target explicitly.
• Secrets in skills.entries.*.env and apiKey go into the host process only, not the sandbox, and are injected for the run only if the variable isn’t already set.
• Agent allowlists under agents.defaults.skills and agents.entries.*.skills limit which skills an agent sees. Leave the field out and skills are unrestricted; an empty list exposes none.
• openclaw skills verify checks an installed skill. It is a check, not a review. Open the files yourself.

Reading a ClawHub skill before you install it

ClawHub’s security analysis compares what a skill declares (environment variables, binaries, install specs) with what it does, and medium-severity findings stay visible on the page instead of hiding the skill. Use the same comparison yourself:

1. Read the metadata.openclaw block. Every entry under requires.env is a secret the skill wants. Ask whether the task needs it.
2. Read the install specs. Anything that downloads a binary is code you aren’t reading.
3. Open the scripts, and check any URL the skill tells the agent to fetch.
4. Look at the scan state on the detail page, then at the publisher’s other skills.
5. Install on a machine or workspace without your real credentials the first time.

None of this is OpenClaw-specific advice, but a registry that anyone can publish to makes it matter more. Our security checklist has the longer version.

Which OpenClaw skills are worth installing?

Lists titled “best OpenClaw skills” or “awesome OpenClaw skills” usually rank by popularity. We rank by what a skill does and what it can reach. Three entries from our catalog that list OpenClaw show how much that matters:

• googleworkspace/cli gives the agent access to Gmail, Drive, Calendar and Docs. Tokens stay stored locally and go only to Google, but anything the skills run can send mail or edit files as you. Verdict: install with caveats, and set scopes carefully.
• browser-use/browser-use is a maintained browser agent. Several of its skills pre-approve unrestricted shell access, setup steps pipe a vendor script into sh, and cloud profile sync uploads local cookies to the vendor. Marked “broad access”.
• snyk/agent-scan scans the agents, skills and MCP servers on your machine. It needs a Snyk token and sends redacted component data to Snyk, so it earns caveats too.

Skills that need no accounts and only read files are the safest first installs. Our best skills page ranks the whole directory, and the skills index shows each review. The list of packs further down this page is filtered to repositories that mention OpenClaw, and methodology explains how we assign the statuses.