How OpenClaw skills work

A skill is a folder with a SKILL.md file: YAML frontmatter with a name and a description, then a Markdown body that teaches the agent how and when to use a tool. OpenClaw follows the AgentSkills spec, loads bundled skills plus your own, and filters them at load time by environment, config and which binaries exist. That is the whole mechanism; the rest is where they come from and who wins.

Where skills come from, in order

• Workspace skills win: the skills folder inside the agent’s workspace, then the project’s agents folder, then your personal agents folder.
• Managed local skills in the state directory, shared by every agent that uses it; then the Workshop skills an agent drafted itself.
• Bundled skills shipped with the install, and last, extra directories and the skills plugins carry.
• The same name in two places: the highest source wins. Folders can be grouped up to six levels deep, and the name comes from the frontmatter, not the path.

Installing from ClawHub puts a skill into the workspace, or into the shared directory with the global flag; updates track ClawHub installs only, so Git and local installs are reinstalled to refresh. A verify command asks the registry for the skill’s trust envelope and exits non-zero when verification fails, and the skill page shows the latest scan before you install.

Gating: why a skill is not there

A skill can declare what it needs: binaries on the path, environment variables, config paths that must be truthy, an operating system. Missing any of them and the skill is filtered out at load time, silently. A skill without a metadata block is always eligible unless disabled; an always flag bypasses the requirement checks but never the operating-system filter.

• user-invocable: exposed as a slash command.
• disable-model-invocation: kept out of the agent’s normal prompt, still callable by command.
• command-dispatch tool: the command bypasses the model and calls a registered tool directly.

Treat third-party skills as untrusted code. Read them before enabling.

Security, honestly

Skill discovery refuses paths that resolve outside their root, the Workshop rejects symlinked skills, and the docs say to prefer sandboxed runs for untrusted inputs. None of that reads the skill for you. What is ClawHub explains the registry’s audit statuses; the practical rule is that a skill is instructions plus scripts, and scripts run with whatever the agent can run.

Skills, plugins, and the Workshop

Plugins are code and skills are instructions; plugins can ship skills. The Workshop is where the agent drafts skills from its own work and you approve them. Which ones to install first is a different question, and the best OpenClaw skills to install first answers it with the security verdicts.

On Diali

Diali’s catalog carries the registry’s skills for both engines with its own review on each, installs them into the assistant’s sandbox from the dashboard, and takes the keys a skill needs there rather than in a config file. Loading order and gating are the same OpenClaw underneath. The Diali skills catalog is the catalog; Hosted OpenClaw on Diali is the assistant.

• A folder, a SKILL.md, a name and a description.
• Closest to the workspace wins; missing requirements filter silently.
• Third-party skills are code: read them, then sandbox.