OpenClaw Skills CLI Reference

`openclaw skills`

Local skills can be examined, ClawHub can be searched, and skills can be pulled from ClawHub, Git, or local folders. You can also confirm ClawHub skills and refresh any installs that ClawHub tracks.

For more details:

The skills system: Skills
The Skill Workshop: Skill Workshop
Configuration for skills: Skills config
Installs from ClawHub: ClawHub

Commands

openclaw skills search "calendar"
openclaw skills search --limit 20 --json
openclaw skills install @owner/<slug>
openclaw skills install @owner/<slug> --version <version>
openclaw skills install skills-sh:<owner>/<repo>/<slug>
openclaw skills install git:owner/repo
openclaw skills install git:owner/repo@main
openclaw skills install ./path/to/skill --as custom-name
openclaw skills install @owner/<slug> --force
openclaw skills install @owner/<slug> --force-install
openclaw skills install @owner/<slug> --acknowledge-clawhub-risk
openclaw skills install @owner/<slug> --acknowledge-install-policy-warning
openclaw skills install @owner/<slug> --agent <id>
openclaw skills install @owner/<slug> --global
openclaw skills update @owner/<slug>
openclaw skills update @owner/<slug> --force
openclaw skills update @owner/<slug> --force-install
openclaw skills update @owner/<slug> --acknowledge-clawhub-risk
openclaw skills update @owner/<slug> --acknowledge-install-policy-warning
openclaw skills update @owner/<slug> --global
openclaw skills update --all
openclaw skills update --all --agent <id>
openclaw skills update --all --global
openclaw skills verify @owner/<slug>
openclaw skills verify @owner/<slug> --json
openclaw skills verify @owner/<slug> --version <version>
openclaw skills verify @owner/<slug> --tag <tag>
openclaw skills verify @owner/<slug> --card
openclaw skills verify @owner/<slug> --global
openclaw skills list
openclaw skills list --eligible
openclaw skills list --json
openclaw skills list --verbose
openclaw skills list --agent <id>
openclaw skills info <name>
openclaw skills info <name> --json
openclaw skills info <name> --agent <id>
openclaw skills check
openclaw skills check --agent <id>
openclaw skills check --json
openclaw skills curator status
openclaw skills curator status --json
openclaw skills workshop propose-create --name "qa-check" --description "QA checklist" --proposal ./PROPOSAL.md
openclaw skills workshop propose-update qa-check --proposal ./PROPOSAL.md
openclaw skills workshop list
openclaw skills workshop inspect <proposal-id>
openclaw skills workshop revise <proposal-id> --proposal ./PROPOSAL.md
openclaw skills workshop apply <proposal-id>
openclaw skills workshop reject <proposal-id> --reason "Not reusable"
openclaw skills workshop quarantine <proposal-id> --reason "Needs security review"

ClawHub is accessed directly by search, update, and verify. A native ClawHub skill gets installed through install @owner/<slug>. When install skills-sh:<owner>/<repo>/<slug> is used, ClawHub is asked to map an external listing to the precise synchronized commit on GitHub; no downloads from skills.sh are performed by OpenClaw. Such entries appear as Not scanned by ClawHub, and that trust status remains intact across updates and verification processes. For skills that are claimed or have been scanned by ClawHub, @owner/<slug> is the tool to use. An unmanaged Git skill is cloned via install git:owner/repo[@ref], while install ./path duplicates a local skill directory. The active workspace's skills/ directory is the default target for install, update, and verify; when --global is set, the shared managed skills directory becomes the destination. Local skills visible to the current workspace and config are still what list/info/check inspect. For workspace-backed commands, the target workspace is determined by --agent <id>, then by the current working directory if it falls within a configured agent workspace, and finally by the default agent.

At the source root, SKILL.md is expected for Git and local directory installs. The install slug is derived from the SKILL.md frontmatter's name when that value is valid, otherwise it comes from the source directory or repository name; --as <slug> can be used to override it. Only ClawHub is supported by --version. Neither npm package specifications nor zip/archive paths are accepted for skill installs, and openclaw skills update only refreshes installs that ClawHub tracks.

A separate request path, skills.install, handles gateway-backed skill dependency installs that originate from onboarding or the Skills settings.

In an interactive terminal, when security.installPolicy gives back warn, OpenClaw shows the reason and findings, then prompts with type: '<skill>' to install anyway (or update anyway). Should the fully rendered review go past 4,000 characters, OpenClaw fails closed before any prompt; trim or combine the policy output first. A matching answer causes the staged skill to be evaluated once more before proceeding. Direct CLI commands that are declined or noninteractive halt before the commit stage; after the review, --acknowledge-install-policy-warning serves as the explicit noninteractive approval covering every warning in that particular command invocation. Each approved warning gets re-evaluated before the process continues. That flag is off-limits for automatic and managed skill installs. When a matching direct CLI command exists, use it; otherwise, adjust security.installPolicy to yield allow for the reviewed request and then retry the managed flow. Neither --force nor the acknowledgement can override block or a policy failure.

Notes:

Flag/behavior	Description
`search [query...]`	An optional query; leaving it out opens the standard ClawHub search feed.
`search --limit <n>`	Limits how many results come back.
`install git:owner/repo[@ref]`	Pulls in a Git-based skill. Branch refs can include slashes, for example `git:owner/repo@feature/foo`.
`install ./path/to/skill`	Installs from a local folder whose top level holds `SKILL.md`.
`install --as <slug>`	Swaps out the inferred slug when installing from Git or a local directory.
`install --version <version>`	Only relevant to native ClawHub skill refs, not `skills-sh:` refs; the mirrored reference already points to the exact synchronized commit.
`install --force`	Replaces an existing workspace skill directory that shares the same slug.
`update --force`	Forces replacement of a tracked skill even when its installed files diverge from the recorded install digests. Skipping this flag keeps local edits intact during updates. Skills installed before digest tracking need one forced update before later updates can be verified. Apply force per skill; `--all --force` also swaps out skills where local edits are detected.
`install/update --force-install`	Fetches a pending GitHub-backed ClawHub skill ahead of ClawHub's scan finishing.
`--global`	Points at the shared managed skills directory; incompatible with `--agent <id>`.
`--agent <id>`	Selects one configured agent workspace; overrides inference from the current working directory.
`update @owner/<slug>`	Refreshes a single tracked skill. Combine with `--global` to aim at the shared managed skills directory rather than the workspace.
`update --all`	Refreshes tracked ClawHub installs in the chosen workspace, or the shared managed skills directory when paired with `--global`.
`verify @owner/<slug>`	Outputs ClawHub's `clawhub.skill.verify.v1` JSON envelope as the default. `--json` also works as the explicit machine-output spelling. Bare slugs are tolerated for compatibility when the skill is already present or unambiguous; owner-qualified refs remove publisher ambiguity.
`verify` provenance	When ClawHub supplies server-resolved source provenance, the verify JSON also carries a commit-pinned `openclaw.verifiedSourceUrl`. Source URLs that are unavailable or self-declared remain confined to the raw provenance envelope and are never promoted.
`verify` version selector	`verify` relies on `.clawhub/origin.json` for installed ClawHub skills, so it checks the installed version against the registry it originated from. `--version` and `--tag` override the version selector but keep that installed registry when origin metadata is present.
`verify --card`	Emits the generated Skill Card Markdown instead of JSON. Returns a non-zero exit when ClawHub responds with `ok: false` or `decision: "fail"`; unsigned signatures are only informational unless ClawHub policy shifts.
Skill Card fingerprint	Installed ClawHub bundles may contain a generated `skill-card.md`. OpenClaw leaves verification to the ClawHub server and does not refuse an installed skill solely because that generated card alters the bundle fingerprint.
`check --agent <id>`	Inspects the selected agent's workspace and reports which ready skills that agent's prompt or command surface can actually see.
`workshop --agent <id>`	Allowed before or after a Workshop leaf command, such as `workshop --agent <id> list` or `workshop list --agent <id>`. When both appear, the leaf value takes precedence.
`curator --json`	Allowed before or after a Curator leaf command, such as `curator --json status` or `curator status --json`.
`list`	Runs by default when no subcommand is given.
`list`/`info`/`check` output	Rendered output is written to stdout. With `--json`, the machine-readable payload also stays on stdout for pipes and scripts.
`curator status --json`	Provides the legacy age-based lifecycle state written by older releases. Daily collection review ignores this state.

Community ClawHub skill installs and updates verify trust before any download begins. Versioned community archive releases depend on exact-release trust metadata. Resolver-backed GitHub skills let ClawHub's install resolver enforce scan and force-install policy before a pinned commit is returned; use --force-install to fetch a pending GitHub-backed skill before that scan finishes. Malicious or blocked community releases are turned away. Risky community releases demand review and --acknowledge-clawhub-risk when a non-interactive command must proceed past that review. Official ClawHub skill publishers and bundled OpenClaw skill sources skip this release-trust prompt.

Remove a ClawHub skill

Removing a ClawHub-tracked skill is done through the standalone ClawHub CLI. If that CLI is missing, install it explicitly first:

npm i -g clawhub
clawhub uninstall @owner/my-skill

Before deleting the skill directory and its .clawhub/lock.json entry, the CLI asks for confirmation. Use the installed skill's owner-qualified name or bare slug, not its original skills-sh: reference.

Pick the same root where the skill was installed: the agent workspace for an agent-specific skill, or the OpenClaw state directory for a shared skill installed with --global:

clawhub --workdir /path/to/agent-workspace uninstall @owner/my-skill
clawhub --workdir ~/.openclaw uninstall @owner/my-skill

When OPENCLAW_STATE_DIR is set, that configured state directory applies to shared skills instead:

clawhub --workdir "$OPENCLAW_STATE_DIR" uninstall @owner/my-skill

The default skills watcher detects the removal on the next agent turn. If watching is off, launch a new session.

Skill Workshop

openclaw skills workshop handles skill proposals that are waiting in the chosen workspace. These proposals only become active skills once they are applied. For details on how proposals are stored, how support files are safeguarded, which Gateway methods are involved, and the approval policy, refer to the Skill Workshop.

openclaw skills workshop propose-create \
  --name "qa-check" \
  --description "Repeatable QA checklist" \
  --proposal ./PROPOSAL.md
openclaw skills workshop propose-create \
  --name "qa-check" \
  --description "Repeatable QA checklist" \
  --proposal-dir ./qa-check-proposal
openclaw skills workshop propose-update qa-check --proposal ./PROPOSAL.md
openclaw skills workshop list
openclaw skills workshop inspect <proposal-id>
openclaw skills workshop revise <proposal-id> --proposal ./PROPOSAL.md
openclaw skills workshop apply <proposal-id>
openclaw skills workshop reject <proposal-id> --reason "Duplicate"
openclaw skills workshop quarantine <proposal-id> --reason "Needs security review"

Alongside the --proposal/--proposal-dir content, propose-create, propose-update, and revise can also take --goal <text> and --evidence <text> to capture the reasoning and supporting details behind the proposal.