Skip to content

skills (Vercel Labs)

This is a tool reference

What a tool or project is, who makes it, and what it is for, whether someone else wrote it or I did. Everything I have learned about it lives elsewhere and links back here.

skills1 installs agent skills - directories holding a SKILL.md and whatever references and scripts it reads - from a git repository into the agent harnesses on your machine. It is run as npx skills add <owner>/<repo>, and it is the installer that federated-knowledge-skills writes its SKILL.md frontmatter to be discovered by.

Author Vercel, under the vercel-labs organisation
Licence Apache-2.0
Language TypeScript
Distribution npm, as skills; ordinarily invoked through npx
Source github.com/vercel-labs/skills
Directory skills.sh
Version read 1.7.0, commit 7407f38, 2026-09-17

What it is

Two things share the name, and separating them early saves confusion. The CLI is the part that does the work: it clones a repository, finds the skills in it, and writes each one into every agent directory you selected. The directory at skills.sh is a leaderboard of publicly installed skills, ranked by install counts the CLI reports back2. The first is a local tool; the second is a website the first feeds. An install event names the repository and the skills taken from it; DO_NOT_TRACK=1 switches the reporting off, at the cost of the pre-install security audit lookup, which is guarded by the same flag. What the event carries in full, and where the built-in private-repository exclusion does not hold, is the investigation.

A skill is discovered, never declared. There is no manifest, no registry entry and no packaging step: a directory containing a SKILL.md whose YAML frontmatter carries a name and a description is a skill, and a repository is however many of those it happens to hold. Anything else in the directory travels with it.

The consequence worth holding onto is that publishing is not a step. A repository becomes installable by containing skills, which also means a repository becomes mis-installable the same way: a SKILL.md missing a required field is skipped with a warning rather than rejected, so a skill can be invisible to the installer whilst looking entirely correct in the editor.

What it installs into

One canonical copy per skill, with a symlink from each agent's own directory, or independent copies under --copy. Project scope writes to ./<agent>/skills/ and is the default; -g writes to the equivalent under the home directory. Around thirty harnesses are recognised, .claude/skills and .opencode/skills amongst them.

Installation is recorded in a skills-lock.json in the project, holding each skill's source and a content hash, which is what skills update later compares against.

Where the skills come from

The source argument accepts GitHub shorthand, a full GitHub, GitLab or Azure Repos URL, any git URL, or a local path. A fragment pins a revision and an @ selects a single skill, so owner/repo#v1.2.0@some-skill is one skill at one tag.

Private repositories use the same command as public ones. The CLI reuses whatever authentication is already configured for the URL, trying ordinary git credentials, then gh repo clone, then SSH; GITHUB_TOKEN and GH_TOKEN are read if set but are not required. It deliberately never runs gh auth token or reads the stored GitHub CLI credential into its own process, which is the right shape: the credential stays where its owner put it.

The following pages link to this page: