skills-manager-cli skill
Drive the Skills Manager CLI (`skm`) to initialize the hub, adopt unmanaged skills, list/enable/disable skills per AI tool, and doctor/fix symlink sync. Use whenever the user or an agent needs to manage skills from a terminal, SSH session, CI job, or headless machine; when a skill is missing in Claude Code, Codex, Cursor, Gemini, OpenCode, or any other supported tool; when asked to run skm / Skills Manager CLI; or when setting up Skills Manager without the GUI. Do not use for `npx skills` / skills.sh search (different CLI), for writing SKILL.md content (skill-creator), or for marketplace browse/install (not in skm).
Is the skills-manager-cli skill safe?
Clean: nothing in its files matched our rules. We read 3 files in the folder on 2026-09-28.
No findings.
Install the skills-manager-cli skill
A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.
git clone --depth 1 https://github.com/jiweiyeah/Skills-Manager.git /tmp/Skills-Manager mkdir -p ~/.claude/skills cp -r /tmp/Skills-Manager/skills/skills-manager-cli ~/.claude/skills/skills-manager-cli
In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub
The instructions your agent would load
SKILL.md as published, without the frontmatter. Read it on GitHub
Skills Manager CLI (skm)
New here? This skill drives skm, the command-line tool that ships with Skills Manager — a desktop app (macOS / Windows / Linux) that installs one copy of a skill into a central hub and symlinks it into every AI coding tool you use (Claude Code, Codex, Cursor, Gemini, and ~30 more), so you write a skill once and it shows up everywhere.
If you found this skill on ClawHub but don't have Skills Manager yet, that is the missing piece: skm is not a standalone binary you npm install. Get it by installing the app from the official website (then Settings → Command Line Tool, or run skm init), or grab a skm-.tar.gz / .zip from the GitHub Releases page. Source and docs: .
skm is the terminal front-end of Skills Manager. It reads and writes the same ~/.skills-manager/config.json and the same hub/tool symlinks as the desktop app, so GUI and CLI are interchangeable.
It does not create, edit, search, translate, tag, or marketplace-install skills. Those stay in the GUI (or you write files into the hub yourself, then skm enable).
Preconditions
at install: the Skills Manager app (Settings → Command Line Tool), or a release archive skm-.tar.gz / .zip from GitHub Releases. Do not fall back to npx skills — that is a different, unrelated CLI.
- Resolve the binary. Prefer skm on PATH. If missing, say so and point
should be updated from Settings or a matching release.
- Confirm with skm --version. A stale binary from an older app release
says so, run skm init --json once — it is idempotent and will not clobber an existing config. skm init and Settings → Install CLI also copy this companion skill into the hub and enable it for every currently active tool, so you usually do not need to install it by hand.
- Every command except init requires an initialized config. If stderr
Hub path is fixed at ~/.skills-manager/skills (%USERPROFILE%\.skills-manager\skills on Windows). save() always rewrites skills_dir to that default; there is no supported way to pick another hub from the CLI.
Agent conventions
These exist because skm is designed to be called by agents, not just humans.
Data is one JSON document on stdout. Errors go to stderr as {"error":"..."} when the command was in JSON mode, otherwise error: .... A command can print a result on stdout and still exit 1 (fix with failed repairs) — parse stdout, then trust the exit code.
- Prefer --json on init, list, doctor, fix, and adopt (apply).
enabled '' for '' (or disabled). Failure is error: ... on stderr, exit 1.
- enable / disable have no --json. Success is a one-line
blocks on [y/N]. Pass --yes when applying. --json also skips the prompt (and therefore applies) — still pass --yes so the intent is obvious in the command line.
- Never wait on a TTY prompt. adopt without --yes and without --json
candidates exist it prints nothing. Preview with skm adopt --dry-run (human text), then apply with skm adopt --yes --json.
- skm adopt --json --dry-run is not a machine-readable preview: if
.issues_count, not the exit code.
- doctor --json exits 0 even when there are issues. Gate on
{"applied": false, "issues_found": N, ...}. Apply with skm fix --yes --json.
- fix without --yes does not repair. JSON then looks like
an advisory lock on config.json and fail fast if another skm is mid-write. Retry once. The desktop app does not take this lock.
- Write commands (init, adopt, enable, disable, fix --yes) take
Pick the tool they named, or the host agent (see Which tool).
- Do not enable a skill for every detected tool unless the user asked.
JSON shapes, exit codes, and the dry-run/apply matrix live in references/json.md. Read that before parsing output or writing a script.
Command map
and accept an exact id, an exact instanceid, or a unique** prefix (claude → claude-code). Ambiguous prefixes error and list the matches — do not guess, rerun with a longer token. Exact tool id wins before prefix (trae is Trae, not Trae CN). Full ids and collision notes: references/tools.md.
Workflows
First-run on a machine with no GUI
command -v skm
skm init --json
skm adopt --dry-run
skm adopt --yes --json
skm list --json
skm doctor --jsoninit on an already-initialized config returns {"already_initialized": true, ...} and does nothing else. If config.json exists but cannot be parsed, init refuses to overwrite it — move or fix the file, then retry.
Make an existing hub skill available to a tool
skm list --json # find id / instance_id
skm enable <skill> --for <tool>
skm list --tool <tool> --json # confirm enabled_forEnabled state is derived from the link on disk, not stored as a separate flag. enable creates the symlink (Windows: symlink → junction → tracked copy). disable removes that link; the hub copy stays.
If the same skill id exists in both global and the active project, a bare id is ambiguous. Use the instance_id from list: global: or project::.
Add a brand-new skill (CLI cannot scaffold it)
description. A directory is a skill if it contains SKILL.md, skill.md, or meta.json.
- Write ~/.skills-manager/skills//SKILL.md with YAML name +
- skm enable --for
- skm list --tool --json to confirm.
Do not copy the folder into ~/.claude/skills (or any other tool dir) yourself — that bypasses the hub and adopt will later see it as an unmanaged real directory.
Adopt skills that already live in a tool directory
adopt looks at active tools (enabled + detected) for real directories that are not symlinks/junctions and not hidden. It moves each one into the hub, then puts a link back at the original path.
merged — they may differ).
- Duplicate hub names are skipped and left in place (contents are not
tool.
- Preview first (--dry-run), then apply (--yes --json).
- After apply, list should show the new ids as enabled for the source
Diagnose "the skill is not showing up in Claude / Codex / …"
skm doctor --json
skm list --tool <tool> --jsonRead the results in this order:
CLI does not re-detect existing tools on every call; a tool installed after init may still show not installed until the GUI redetects or the config is updated. Do not try to invent a custom tool from skm.
- Binary missing or not on PATH → install, reopen the shell.
- config_initialized false → skm init --json.
- Tool detected: false → the tool's config dir is not on this machine.
page, or say so.
- Tool enabled: false → CLI cannot flip that flag. Use the GUI Tools