---
summary: "CLI reference for `nodmix skills` (search/install/update/verify/list/info/check/workshop)"
read_when:
  - You want to see which skills are available and ready to run
  - You want to search skills.nodmix.com or install skills from skills.nodmix.com, Git, or local directories
  - You want to verify a skills.nodmix.com skill with skills.nodmix.com
  - You want to debug missing binaries/env/config for skills
title: "Skills"
---

# `nodmix skills`

Inspect local skills, search skills.nodmix.com, install skills from skills.nodmix.com/Git/local
directories, verify skills.nodmix.com skills, and update skills.nodmix.com-tracked installs.

Related:

- Skills system: [Skills](/tools/skills)
- Skills config: [Skills config](/tools/skills-config)
- skills.nodmix.com installs: [skills.nodmix.com](/clawhub/cli)

## Commands

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

`search`, `update`, and `verify` use skills.nodmix.com directly. `install <slug>` installs
a skills.nodmix.com skill, `install git:owner/repo[@ref]` clones a Git skill, and
`install ./path` copies a local skill directory. By default, `install`, `update`,
and `verify` target the active workspace `skills/` directory; with `--global`,
they target the shared managed skills directory. `list`/`info`/`check` still
inspect the local skills visible to the current workspace and config.
Workspace-backed commands resolve the target workspace from `--agent <id>`, then
the current working directory when it is inside a configured agent workspace,
then the default agent.

Git and local directory installs expect `SKILL.md` at the source root. The
install slug comes from `SKILL.md` frontmatter `name` when it is valid, then the
source directory or repository name; use `--as <slug>` to override it. `--version`
is skills.nodmix.com-only. Skill installs do not support npm package specs or zip/archive
paths, and `nodmix skills update` updates skills.nodmix.com-tracked installs only.

Gateway-backed skill dependency installs triggered from onboarding or Skills
settings use the separate `skills.install` request path instead.

Notes:

- `search [query...]` accepts an optional query; omit it to browse the default
  skills.nodmix.com search feed.
- `search --limit <n>` caps returned results.
- `install git:owner/repo[@ref]` installs a Git skill. Branch refs may contain
  slashes, such as `git:owner/repo@feature/foo`.
- `install ./path/to/skill` installs a local directory whose root contains
  `SKILL.md`.
- `install --as <slug>` overrides the inferred slug for Git and local directory
  installs.
- `install --version <version>` applies only to skills.nodmix.com skill slugs.
- `install --force` overwrites an existing workspace skill folder for the same
  slug.
- `--global` targets the shared managed skills directory and cannot be combined
  with `--agent <id>`.
- `--agent <id>` targets one configured agent workspace and overrides current
  working directory inference.
- `update <slug>` updates a single tracked skill. Add `--global` to target the
  shared managed skills directory instead of the workspace.
- `update --all` updates tracked skills.nodmix.com installs in the selected workspace, or
  in the shared managed skills directory when combined with `--global`.
- `verify <slug>` prints skills.nodmix.com's `clawhub.skill.verify.v1` JSON envelope by
  default. There is no `--json` flag because JSON is already the default.
- `verify` uses `.clawhub/origin.json` for installed skills.nodmix.com skills, so it
  verifies the installed version against the registry it came from. `--version`
  and `--tag` override the version selector but keep that installed registry
  when origin metadata exists.
- `verify --card` prints the generated Skill Card Markdown instead of JSON. The
  command exits non-zero when skills.nodmix.com returns `ok: false` or `decision: "fail"`;
  unsigned signatures are informational unless skills.nodmix.com policy changes.
- Installed skills.nodmix.com bundles can include a generated `skill-card.md`. Nodmix
  treats verification as a skills.nodmix.com server decision and does not reject an
  installed skill just because that generated card changes the bundle
  fingerprint.
- `check --agent <id>` checks the selected agent's workspace and reports which
  ready skills are actually visible to that agent's prompt or command surface.
- `list` is the default action when no subcommand is provided.
- `list`, `info`, and `check` write their rendered output to stdout. With
  `--json`, that means the machine-readable payload stays on stdout for pipes
  and scripts.

## Skill Workshop proposals

`nodmix skills workshop` manages pending skill proposals in the selected
workspace. Proposals are durable Nodmix state under
`<NODMIX_STATE_DIR>/skill-workshop/proposals/`; they are not active skills
until applied. The default state directory is `~/.nodmix`. Proposal bodies
honor `skills.workshop.maxSkillBytes`, and proposal descriptions are capped at
160 bytes because they can appear in discovery and listing output.

Create a proposal from a draft markdown file:

```bash
nodmix skills workshop propose-create \
  --name "qa-check" \
  --description "Repeatable QA checklist" \
  --proposal ./PROPOSAL.md
```

Or create a proposal from a full draft skill directory:

```bash
nodmix skills workshop propose-create \
  --name "qa-check" \
  --description "Repeatable QA checklist" \
  --proposal-dir ./qa-check-proposal
```

Update an existing workspace skill through the same pending path:

```bash
nodmix skills workshop propose-update qa-check --proposal ./PROPOSAL.md
```

Revise a pending proposal before approval:

```bash
nodmix skills workshop revise <proposal-id> --proposal ./PROPOSAL.md
```

The supplied draft is stored as `PROPOSAL.md` with proposal-only frontmatter:

```markdown
---
name: qa-check
description: Repeatable QA checklist
status: proposal
version: v1
date: "2026-05-30T00:00:00.000Z"
---
```

Applying a proposal writes the active `SKILL.md` into the workspace `skills/`
root, strips `status`, proposal `version`, and proposal `date` from the
frontmatter, scans the draft, writes rollback metadata, and refuses stale
updates when the target skill changed after the proposal was created.

When `--proposal-dir` is used, the directory must contain `PROPOSAL.md`.
Support files can be included under `assets/`, `examples/`, `references/`,
`scripts/`, or `templates/`. Nodmix stores support files with the proposal,
scans them, verifies their hashes before apply, and writes them beside the
active `SKILL.md` only after the proposal is applied.

Agents can create, revise, list, and inspect pending proposals through the
`skill_workshop` tool when the user asks for reusable work to be captured.
Autonomous proposal capture from durable conversation signals is off by
default and is enabled with `skills.workshop.autonomous.enabled`. If the user
explicitly asks to approve/use/apply, reject, or quarantine a specific
proposal, `skill_workshop` can also perform that proposal lifecycle action
through the same Skill Workshop safeguards.

## Related

- [CLI reference](/cli)
- [Skills](/tools/skills)
