OpenClaw Skills Ecosystem and Practical Production Picks

OpenClaw has two extension stories, and they are easy to mix up.

Plugins extend the runtime. Skills extend the agent’s behavior.

That distinction matters. A plugin adds a new capability surface such as a channel, provider, or tool integration. A skill is usually lighter. It teaches the agent how and when to use existing tools, binaries, APIs, or workflows. In practice, that makes skills the faster moving part of the OpenClaw ecosystem, and also the noisier one.

This article stays on the ecosystem and selection side. For how skills and plugins combine in practice by user type, see OpenClaw production setup patterns. The question here is simpler and more useful: which skills are actually worth installing, how do they fit into OpenClaw, and which ones look more like noise than durable tooling.

Popularity notes below use ClawHub stars and downloads as a rough snapshot on 2026-04-18.

What OpenClaw skills really are

The OpenClaw skill model is elegant because it is mostly plain files.

A typical skill looks like this:

my-skill/
  SKILL.md
  scripts/
  references/
  assets/

At minimum, the skill needs SKILL.md. That file contains YAML frontmatter and markdown instructions that tell the agent what the skill does, when to use it, and what tools or commands are available.

A minimal example looks like this:

---
name: hello_world
description: A simple skill that says hello
---

# Hello World Skill

Use this skill when the user wants a quick greeting.

The useful part is not the markdown itself. The useful part is how OpenClaw loads and gates skills.

A skill can be:

• bundled with OpenClaw
• installed into a workspace
• shared at user level
• scoped to an agent
• injected by a plugin
• filtered by OS, binaries, environment variables, or config

That last point is why OpenClaw skills feel closer to operational recipes than to prompt snippets. A good skill is not only descriptive. It declares enough metadata that OpenClaw can decide whether it should even be visible.

In other words, the system is more disciplined than the average public “prompt pack” marketplace.

OpenClaw skill locations and structure

OpenClaw uses a precedence model rather than a single global skills folder.

In practice, the highest value locations are:

• <workspace>/skills for project specific overrides
• <workspace>/.agents/skills for project agent skills
• ~/.agents/skills for personal agent skills
• ~/.openclaw/skills for shared local skills
• bundled skills shipped with the install

That layout is one of the better design decisions in OpenClaw. It makes skills overrideable without editing the upstream install, and it keeps local customization from turning into a dirty fork.

It also means skill visibility and skill location are separate concerns.

A skill can exist locally and still be blocked from a given agent. That happens through skill allowlists in agents.defaults.skills and agents.list[].skills. For production, that separation is more important than the marketplace itself. It is what stops every agent from receiving every possible workflow.

There are also a few frontmatter flags worth remembering:

• user-invocable exposes a slash command
• disable-model-invocation keeps the skill out of the model prompt while still allowing explicit invocation
• command-dispatch and command-tool can bypass model reasoning and call a tool directly
• metadata.openclaw.requires.* can gate a skill on binaries, env vars, OS, or config

That is enough structure to make skills powerful, but also enough rope to create fragile packages if the metadata is sloppy.

Where to get OpenClaw skills

For practical use, there are three real sources.

ClawHub

ClawHub is the official public registry for OpenClaw skills and plugins. It is the default place to search, install, update, inspect versions, and see lightweight community signals such as stars and downloads.

If you only pick one source, use ClawHub.

Bundled skills

OpenClaw ships with bundled skills inside the install. These are lower friction, but the list is naturally smaller than the public registry.

Bundled skills are the closest thing the ecosystem has to a supported baseline.

Local and Git based skills

You can also keep skills in your own workspace or user folders, or pull them from public repositories.

This is useful for private skills, experiments, and local overrides.

There is also a public archived repository of registry skills on GitHub. It is useful as an audit trail, not as the first place to install from. Treat it as a historical dump and inspection surface, not as a curated store.

Community discovery layers such as awesome lists and filtered indexes are now part of the ecosystem as well. That is a signal in itself. Once a marketplace gets large enough, secondary curation becomes necessary.

How to install, update, and remove skills

The normal install flow is through the OpenClaw CLI.

Search

openclaw skills search "calendar"
openclaw skills search "github"
openclaw skills search --limit 20 --json

Install

openclaw skills install <skill-slug>
openclaw skills install <skill-slug> --version <version>
openclaw skills install <skill-slug> --force

By default, openclaw skills install places the skill into the active workspace skills/ directory.

Update

openclaw skills update <skill-slug>
openclaw skills update --all

Inspect and validate

openclaw skills list
openclaw skills list --eligible
openclaw skills info <name>
openclaw skills check

Install with the dedicated ClawHub CLI

If you publish skills, sync local folders, or want registry specific workflows, use the separate clawhub CLI.

npm i -g clawhub

clawhub search "research"
clawhub install <skill-slug>
clawhub update --all
clawhub skill publish ./my-skill --slug my-skill --name "My Skill" --version 1.0.0

The dedicated CLI writes a .clawhub/lock.json file in the working directory, which is useful for tracking what came from the registry.

Removal

This part is less polished than installation.

OpenClaw documents install and update flows for skills, but not a dedicated openclaw skills uninstall command. In practice, removal is filesystem based.

If a skill was installed into the workspace, remove its folder from <workspace>/skills, then start a new session.

If you want the skill to stay present but not be usable by a given agent, use skill allowlists instead of deletion.

That sounds a little manual because it is. The skill system is clean. The lifecycle UX is still catching up.

Maturity, reliability, community, and support

The skill system is mature enough to be real, but not mature enough to be calm.

That is the shortest honest summary.

What is mature

The underlying model is solid.

Skills are plain files, easy to inspect, easy to override, easy to version, and flexible enough to express both tiny instruction packs and fairly serious task helpers. OpenClaw also separates visibility, precedence, and runtime gating in a way that feels intentionally designed rather than bolted on.

The community signal is also real. OpenClaw itself is one of the most visible open source AI agent projects right now, and the skill ecosystem is large enough that third party curation has already appeared.

What is not mature

Registry quality is uneven.

The interesting issue is not whether a skill can work. Many do. The issue is whether the packaging, metadata, secret handling, and trust story are coherent.

A good OpenClaw skill is narrow, boring, and inspectable.

A weak OpenClaw skill usually has one or more of these problems:

• metadata that does not match what the skill actually needs
• hidden or undocumented environment variables
• third party taps or installers with thin provenance
• broad account access for a narrow task
• hooks that quietly become default behavior
• an impressive pitch with very little durable workflow value

This is why “most downloaded” is not the same thing as “production ready”.

Support reality

Support comes from a mix of places:

• official docs
• ClawHub metadata and scan pages
• GitHub issues and repository history
• community comments and curation lists

That is enough for active operators. It is not the same as enterprise support.

If you need predictable ownership and response times, the skill ecosystem still feels more open source registry than platform contract.

Security concerns are not optional

OpenClaw is powerful because it can act.

That also means skills should be treated as code, not decoration.

The official security posture already hints at the correct mental model. Run the gateway on a dedicated machine, VM, or container. Use a dedicated OS user. Keep personal accounts and browser profiles away from that runtime. Restrict high risk tools. Treat links, attachments, and pasted instructions as hostile by default.

That guidance becomes more important, not less, once skills enter the picture.

The ClawHub moderation story has improved, but it is still fundamentally a public registry. Skills can be reported, hidden, deleted, and scanned. Publishing now has some basic controls. But the high level lesson from recent incidents is obvious: a public skill registry attracts malware quickly.

The right filter is simple:

• instruction only skills are usually lower risk
• small helper scripts can be fine if metadata and provenance are clean
• hooks deserve extra scrutiny
• skills that touch sensitive accounts need the highest bar
• any scan flag should matter more than social hype

Popularity is not a trust signal. At best, it is a hint that a skill solved a real problem for many people.

The most useful OpenClaw skills right now

The most useful skills are not the flashiest ones. They are the ones that make repeated workflows cheaper, clearer, or safer.

My filter here is opinionated:

• narrow scope beats broad promise
• inspectable beats magical
• local or transparent beats opaque proxying
• workflow value beats novelty
• clean packaging beats vibes

Safety and self correction

These are the least glamorous skills in the ecosystem, which is exactly why they matter.

The first one is popular for a reason. It is not a gimmick. It creates a feedback loop around failure, which is one of the few things that consistently pays off in agent systems.

The second one is not popular in absolute terms, but it is one of the most sensible installs you can add if you plan to browse ClawHub regularly.

Search and research

Search skills are where OpenClaw gets genuinely useful, but also where packaging quality varies a lot.

The strongest pattern here is that method often beats breadth.

Multi Search Engine is the broad utility pick. Tavily Search is the cleaner service backed pick. Academic Deep Research is the process pick. None of them are flashy. All of them can be useful.

Developer workflows

This is the most obviously valuable category for technical readers.

The GitHub skill is the kind of skill the ecosystem should have more of. It is boring, direct, and tied to a tool developers already know.

Agent Browser is more powerful, but also deserves more care. Browser state files, cookies, and page context are real data surfaces. That does not make the skill bad. It makes it operational.

Memory and knowledge

This category is more valuable than it looks at first glance.

The ontology skill stands out because it treats memory as structure rather than as note accumulation. That is a stronger long term direction for agent systems than endlessly appending summaries.

Workspace and personal productivity

This is the most uneven category. It contains genuinely useful skills, but also some of the most obvious metadata mismatches.

This is where the ecosystem gets interesting.

Gog is clearly useful. It is also a good example of why utility and trust are separate questions. The current scan notes point out metadata mismatches around binaries and credentials. That does not automatically make it malicious. It does make it a skill to inspect before granting account access.

Notion sits in the same category. Good workflow value. Messier packaging story.

Openai Whisper is the opposite. It is limited, local, and refreshingly straightforward.

The skills I would not rush to install

Some skills are popular for understandable reasons and still do not make my first pass list.

That is the larger pattern in one table.

High download counts do not erase packaging problems.

The real shape of the OpenClaw skills ecosystem

The OpenClaw skills ecosystem is already big enough to be useful and already noisy enough to need curation.

That is usually the moment an ecosystem becomes real.

The good news is that the underlying skill format is strong. Skills are inspectable. Overrides are clean. Precedence is sensible. Gating is practical. ClawHub provides versioning, discovery, stars, downloads, comments, and basic moderation.

The bad news is that public registries move faster than trust models.

If you want the short opinionated take, it is this:

• the skill system is better than the average AI marketplace
• the registry is more useful than safe by default
• the best skills are small, specific, and operationally boring
• suspicious metadata is not a cosmetic issue
• “popular” should never outrank “inspectable”

Final take

If I were trimming OpenClaw skills down to the set that looks most durable right now, I would start with:

• self-improving-agent
• Skill Vetter
• Github
• Multi Search Engine
• Tavily Search
• Academic Deep Research
• ontology
• Openai Whisper

Then I would consider Gog and Notion only after a manual review of current metadata, source, and secret handling.

That is probably the right framing for the entire OpenClaw skills ecosystem in 2026.

The good part is already very good.

The safe part still requires an adult in the room.

For how skills combine with plugins in real deployments by user type, see OpenClaw production setup patterns.

For the plugin layer those skills depend on, see OpenClaw plugins guide.