vercel-labs/skills: one CLI to install agent skills across Claude Code, Codex, Cursor and OpenCode

The problem: every agent wants its own skills directory

Claude Code, Codex, Cursor and OpenCode all read skill or instruction files, but they do not agree on where those files live, and none of them ships a package manager for them. The practical result is that a team writes guidance once, then copies it by hand into each tool's directory, and the copies drift. vercel-labs/skills exists to collapse that into a single command. The README describes it as "the CLI for the open agent skills ecosystem", and the supported agent list in the repository starts with OpenCode, Claude Code, Codex and Cursor before pointing at a longer table. This is a tool for people who already maintain prompt or skill content in a repository and want the same content available in whatever agent a teammate happens to run. It is not a skill authoring format, and it is not an agent. The value is entirely in the fetch, resolve and place steps.

How skills resolves a source and places files

The mechanism is a resolver plus a writer. On the resolve side, the CLI accepts a GitHub shorthand like owner/repo, a full GitHub URL, a direct path to a skill inside a repo, a GitLab URL, any git URL including SSH, or a local path. The README also notes that direct download URLs are tried after well-known discovery, and those may point at a single SKILL.md or at a .zip, .tar, .tar.gz or .tgz archive, with or without a file extension in the URL. On the write side, installation scope is either project (the default, into ./<agent>/skills/) or global with -g (into ~/<agent>/skills/). The interactive installer offers two methods: symlink, which the README recommends and describes as creating links from each agent to a canonical copy, and copy, for cases where symlinks are not supported. That symlink default is the interesting design decision. It means one canonical copy and cheap updates, but it also means the agent directory is not self-contained, so anything that archives or containers the project without following links will miss the skill content.

Installing the skills CLI and running a first add

There is no global install step in the README. The documented entry point is npx, so the first command you run is also the install. This lists the skills inside a public repository without writing anything to disk, which is the safest way to see the naming convention before committing to an install.

npx skills add vercel-labs/agent-skills --list

Once you know the skill names, install one into a specific agent. The README's non-interactive example targets Claude Code globally and skips confirmation prompts, which is the shape you would use in CI.

npx skills add vercel-labs/agent-skills --skill frontend-design -g -a claude-code -y

After that, npx skills list (alias ls) should show the installed skill. If you want to try a skill without installing it at all, the README's use command writes the selected skill files to a temporary directory and prints only the generated prompt to stdout, so it can be piped straight into an agent.

npx skills use vercel-labs/agent-skills@web-design-guidelines | claude

Adding --agent claude-code to that same command instead starts one supported agent interactively with the generated prompt. Note the quoting rule in the README: skill names containing spaces must be quoted, as in --skill "Convex Best Practices".

Private repositories and the credential path

The README is unusually explicit here, and it is worth reading before you point the CLI at anything internal. Public and private repositories use the same command; the CLI relies on authentication already configured for the URL. For GitHub HTTPS and shorthand sources, it first uses normal Git credentials, then falls back to gh repo clone if GitHub CLI is authenticated, then SSH. The README states that it does not execute gh auth token and does not copy the stored GitHub CLI credential into the Node.js process. For GitHub tree lookups it tries the API anonymously, then an explicitly supplied environment token, then gh api, and the credential is never printed to or read by skills. GITHUB_TOKEN and GH_TOKEN can be set explicitly for GitHub API access, including private repository downloads and update checks, but they are optional when Git, GitHub CLI or SSH auth is already configured. The trade-off is that authentication behaviour depends on the developer's machine state. A CI runner with no credential helper and no gh login will behave differently from a laptop that has both, and the README does not document a way to force one path.

Size caps and the trust question

The default limits are the most concrete constraint in the documentation: downloads are capped at 10 MiB, extracted content at 25 MiB, and archives at 1000 files. They can be raised with SKILLS_DOWNLOAD_MAX_BYTES, SKILLS_EXTRACT_MAX_BYTES and SKILLS_EXTRACT_MAX_FILES, and the README frames that as something to do "when you trust the source". That framing is correct and worth taking literally. Installing a skill means fetching third-party content and placing it where a coding agent will read and act on it, and the CLI's own defaults treat that as a boundary rather than a formality. There is no signature check, no allowlist and no documented review step in the README. If your threat model requires an approval gate before agent instructions change, this tool does not provide one; you would have to wrap it in your own review of the resolved files. The flip side is that the caps will also reject legitimately large skill bundles, and raising the environment variables removes the only guardrail the tool ships with.

Where skills is the wrong choice

If your skills already live in a package registry with versioned releases and lockfiles, this CLI adds a second, Git-shaped distribution path rather than replacing yours. The README's source formats are Git URLs, local paths and direct download URLs; there is no mention of npm, PyPI or an OCI registry as a source type. It is also a poor fit if you need one agent's skill directory to be fully self-contained for container images or air-gapped builds, because the recommended install method is a symlink to a canonical copy. And it is the wrong tool if you want the CLI to manage the content of skills. The README documents add, use, list, find and remove. Authoring, validation and versioning of the SKILL.md files themselves happen in the source repository, on your side. The CLI is a transport layer, and it behaves like one.

A real alternative: writing files into agent directories yourself

The obvious alternative is a shell script or a Makefile target that clones your skills repo and copies files into each agent's directory. The difference is in the resolution and placement logic, not in the copying. A hand-rolled script has to reimplement source parsing (shorthand, full URL, subdirectory path, SSH), the credential fallback chain described above, the per-agent destination mapping across the supported agent list, and the symlink versus copy decision. The skills CLI also carries a find command for searching skills interactively or by keyword, and update checks that the README says fall back to an authenticated Git clone when API access fails. Against that, a script is auditable in a way a downloaded CLI is not, and it can enforce your own review step before anything reaches an agent directory. If your team uses exactly one agent and one internal skills repo, the script is probably enough. The CLI earns its place when the agent list grows past one or two.

Maintenance, licence and what to verify before adopting

The repository is not archived, and the last push was on 2026-08-18, which is recent enough that the project is being changed rather than left to sit. Releases v1.5.21 through v1.5.23 landed between 2026-07-30 and 2026-08-18, and package.json in the repository shows version 1.5.26, so the published package moves faster than the release list shown here. The licence is MIT. That is permissive, and it means you can vendor or modify the CLI, but it also means the project offers no warranty and no support commitment, so the operational risk sits with you. The repository ships a ThirdPartyNoticeText.txt and a build script that regenerates licenses, which suggests dependency licence tracking is handled deliberately; if you redistribute the built CLI, that file is the one to read. On upgrade cost, the CLI is consumed through npx rather than a pinned global install, so running npx skills add without pinning a version means you get whatever is current. For reproducible installs, pin the package version in the npx invocation and check whether the resolved skill files changed between runs.

Editorial conclusion

Adopt vercel-labs/skills if you already keep agent instructions in Git and want one command to fan them out to Claude Code, Codex, Cursor, OpenCode or the other supported agents, and if you are comfortable running npx against third-party repositories. Skip it if you need a review gate before skills land in agent directories, if your skills live behind a registry rather than a Git URL, or if you cannot accept that downloads are capped at 10 MiB and extracted content at 25 MiB by default. Before rolling it out to a team, run npx skills add vercel-labs/agent-skills --list against a real repository, then install one skill with -a claude-code -g -y and inspect whether the CLI symlinked or copied files into ~/claude-code/skills/.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes