npx skills: One Command, 90+ AI Agents

If you have installed an agent skill in the last few months, there is a good chance you typed npx skills add to do it. The command comes from vercel-labs/skills, a CLI that resolves a skill from GitHub, GitLab, a bare git URL or a folder on your disk, then writes it into whichever coding agents you actually run. Vercel open-sourced it in January 2026. By 11 September 2026 the repo sat at 31,223 stars with 145 contributors, and v1.5.25 had shipped three days earlier.

What follows is a plain description of what the tool does, where it puts things, and one awkward finding Vercel published about its own product.

Key Takeaways:

• npx skills add <source> installs a skill into every agent you pick, from one command.
• The README's own table lists more than 90 --agent targets, and each has a different directory convention.
• The default install is a symlink to a single canonical copy, not a per-agent duplicate.
• It is MIT licensed, and the CLI deliberately avoids reading your GitHub CLI token into its own process.

Two Vercel repos, and people keep citing the wrong one

The confusion is understandable, because both repos are enormous and both have "skills" in the name.

vercel-labs/skills is the CLI. That is the thing npx skills runs. vercel-labs/agent-skills is something else entirely: Vercel's own collection of skills, the payload rather than the installer, created on 8 December 2025 and sitting at 31,045 stars. When the docs show npx skills add vercel-labs/agent-skills, the first half is the tool and the second half is a package it happens to be fetching. Swap them in a citation and you have described a package manager as a package.

The repo itself is busy in the way infrastructure gets busy once people depend on it: 499 commits, 44 tagged releases, 850 open issues and 343 open pull requests on the day I looked. It requires Node.js 22.20 or newer. The description Vercel gives it is six words long, and accurate.

What skills add actually writes to your disk

Run it with no flags inside a project and the CLI puts files under ./<agent>/skills/, scoped to that repo, committed alongside your code so a teammate cloning it gets the same skills. Pass -g and it goes to a user-level directory instead, available in every project on that machine.

Then there is the question of how the files get there, and the answer is the part most people miss. The default is not a copy. The CLI keeps one canonical copy of the skill and symlinks each agent's directory at it, so updating the skill once updates it for Claude Code, Codex and Cursor simultaneously. Pass --copy and you get independent duplicates instead, which is what you want on a filesystem where symlinks are awkward and exactly what you do not want if you plan to keep the skill current.

Both choices are machine-local, which is the quiet constraint underneath all of this. A globally installed skill lives in your home directory on the laptop you installed it from; the symlink graph, the canonical copy, the agent config pointing at it are all state on one physical machine. That is fine right up until the work has to happen while the lid is shut, or on a second machine, or somewhere your laptop is not. Zentor is a hosted cloud AI computer built for that gap: a persistent machine with its own filesystem that runs alongside your local install rather than replacing it, so the skill you added this morning has somewhere to live that does not sleep when you do.

Ninety-odd agents, and why none of them agree on a path

The README's headline says the CLI supports OpenCode, Claude Code, Codex and Cursor plus "75 more". Counting the --agent identifiers in the supported-agents table gives 91 distinct targets as of September 2026, because several rows bundle multiple agents that share one convention.

That table rewards a slow read, because it is a snapshot of how badly the ecosystem has fragmented. Claude Code reads .claude/skills/ in a project and ~/.claude/skills/ globally. Codex reads .agents/skills/ in the project but ~/.codex/skills/ globally, so the two scopes do not even share a convention inside one agent. Cursor uses .agents/skills/ and ~/.cursor/skills/. Cline, Dexto, Kimi Code CLI, Loaf, Sarvam Code, Warp and Zed all share a single row because they all agreed on .agents/skills/. Eve has no global path at all; it is project-only.

A neutral installer is a reasonable response to that mess. If you have ever hand-copied a SKILL.md into four agents and got the Codex global path wrong, you already know why 3.3 million installs have gone to find-skills, the top entry on the skills.sh leaderboard.

Sources other than GitHub

skills add takes the owner/repo shorthand, but it resolves rather more than that. A full GitHub URL works. So does a URL pointing at one subdirectory of a repo, which lets you install a single skill out of a collection without pulling the rest. GitLab URLs work, as does any git URL including SSH, and a plain local path for skills you are still writing.

It will also accept a direct download URL that is not a git host at all, pointing either at a single valid SKILL.md or at a .zip, .tar, .tar.gz or .tgz archive; the URL does not need a file extension for this to work. Since that is a remote-content path, the CLI caps it: 10 MiB for the download, 25 MiB extracted, 1,000 files per archive, all three overridable through environment variables when you trust the source. Caps you have to consciously raise beat caps that were never there.

The commands around add matter more than they look. npx skills list shows what is already installed, npx skills remove takes it back out, and npx skills update is what keeps the symlinked canonical copy current after the upstream author ships a change. That last one is the reason the symlink default is worth defending: with --copy you have four independent copies and no single thing to update.

Skills have also started shipping as a companion to other software rather than as standalone repos. The desktop knowledge-base app nashsu/llm_wiki publishes nashsu/llm_wiki_skill as a separate repo whose entire job is to teach Claude Code and Codex how to query the app's local API. One npx skills add and your coding agent knows how to search a knowledge base running on the same machine. That pattern, a skill as the adapter between two tools, is quietly the most interesting thing the CLI enabled.

Useful flags in practice: --list shows what a repo contains without installing anything, --skill takes specific names (quote them if they contain spaces), -a targets particular agents, and -y skips the prompts, which is what makes the thing usable in CI.

Private repos, and what the CLI does not do with your token

For a private repo the command is identical; the CLI reuses whatever authentication that URL already has. On GitHub HTTPS or shorthand it tries your normal git credential helper first, falls back to gh repo clone if the GitHub CLI is authenticated, then tries SSH.

The interesting detail is a negative one. The README states that the CLI does not run gh auth token and does not copy the stored GitHub CLI credential into its Node process; when it needs a GitHub API lookup it shells out to gh api and lets the GitHub CLI apply its own authentication, receiving only the response back. GITHUB_TOKEN and GH_TOKEN are honoured if you set them explicitly, and are otherwise unnecessary.

Writing that down in a README suggests someone thought about blast radius, and it sharpens a question worth asking before any of this: which machine are those credentials sitting on? Running an agent with your own SSH key loaded, as you, on your daily-driver laptop, is a different security posture from giving it a separate machine with its own credentials. That separation is one of the things you get from Zentor without building it yourself, because the agent's environment is not your login session.

Vercel published an eval saying AGENTS.md beat skills

This part does not show up in the enthusiastic coverage. Vercel's own blog carries a post titled "AGENTS.md outperforms skills in our agent evals", and it ranks on page one for vercel skills right alongside the launch announcement.

Take it for what it is: one vendor's evals on one set of tasks, published by the company that built the installer. It does not mean skills are useless. It does mean the honest framing for npx skills is distribution, not capability. The CLI solved the problem of getting a markdown file into 91 agents' worth of incompatible directory layouts. Whether that markdown file was the right container for the instruction in the first place is a separate argument, and Vercel is publicly on both sides of it.

For the longer version of that argument, we have written about what agent skills actually are and about how Anthropic frames its own skills format. The format churn is real: OpenAI has already deprecated its Codex skills path once.

So should you use it?

Yes, if you install skills from more than one source into more than one agent. The symlink model alone justifies it, because the alternative is four copies that drift apart quietly.

Where it stops helping is anything stateful. npx skills installs instructions; it does not give those instructions a machine to run on, a schedule, or a lifetime longer than your terminal session. A skill meant to check something every morning needs a computer that is awake every morning, and the ecosystem has no answer for that because it is not an installer problem. That is the line Zentor sits on: a hosted machine where the agent keeps its own filesystem between sessions, so installed skills survive a closed laptop instead of waiting for one to open.

You can also just try the thing before deciding. npx skills find searches the registry interactively, and npx skills use <source> runs one skill without installing anything at all, printing the generated prompt to stdout or handing it straight to an agent with --agent. That is about as low-commitment as evaluation gets.

FAQ

Is the npx skills CLI free and open source?

Yes. vercel-labs/skills is MIT licensed, and npx fetches it from npm without a permanent install. No account or key is involved in skills add itself. You will need Node.js 22.20 or newer.

Does it work with Cursor and Codex?

Both, and roughly 89 others. Codex is one of the four agents named in the README headline. Note the path asymmetry: Codex reads .agents/skills/ at the project level but ~/.codex/skills/ globally, which the CLI handles for you and which is easy to get wrong by hand.

What is the difference between skills add and skills use?

add installs a skill into your agents' directories and leaves it there. use resolves the same sources, writes the files to a temporary directory, and prints only the generated prompt to stdout; pass --agent and it starts a supported agent interactively with that prompt instead. Reach for use when evaluating a skill, add when keeping it.

Can I install just one skill from a big collection?

Two ways. Pass --skill <name>, repeatable for several, or point the command directly at the subdirectory URL of that skill inside the repo.

Where do the files go by default?

Into the project, at ./<agent>/skills/, as symlinks to one canonical copy. Add -g for the user-level directory instead, or --copy to duplicate files per agent rather than symlink them.