skills.sh: Install Skills Across AI Coding Agents

If you use more than one coding agent, copying the same instructions into separate Claude Code, Codex, Cursor, and OpenCode directories gets untidy quickly. Each copy can drift, and it becomes hard to tell which version an agent is following.

skills.sh provides a directory for discovering agent skills. Its open-source skills CLI handles the practical part: selecting skills from a repository, installing them for one or several agents, and updating or removing them later.

Quick answer #

Start by listing the skills in a repository without installing anything:

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

Then install one skill for the agents that should use it:

npx skills add vercel-labs/agent-skills \
  --skill web-design-guidelines \
  --agent claude-code \
  --agent codex

To make that specific skill available to every agent target supported by the CLI, use a quoted wildcard so the shell does not expand it:

npx skills add vercel-labs/agent-skills \
  --skill web-design-guidelines \
  --agent '*'

There is also a much broader command:

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

--all means all discovered skills and all agents, with no confirmation prompts. It is convenient for a repository you own and have reviewed. It is usually too broad for trying an unfamiliar public collection.

What gets installed #

An agent skill is a directory containing at least a SKILL.md file. That file has a name, a description that helps an agent decide when to activate it, and the instructions to follow. A skill can also contain executable scripts, reference material, and assets. The complete structure is documented in the Agent Skills specification.

The skills CLI understands the project and global directories used by dozens of coding agents. For example, it targets .agents/skills/ for a project-level Codex installation and .claude/skills/ for Claude Code. It can create symlinks from those agent directories to one canonical copy of the skill. This keeps the instructions consistent and lets one update serve multiple agents.

Use --copy when symlinks are unsuitable for the filesystem or deployment environment. Copies are independent, so keeping every agent on the same version becomes your responsibility.

Choose project or global scope deliberately #

The default installation is project-local. Run the command from the project root when a skill encodes repository conventions, framework versions, or a workflow the team should be able to inspect.

Add --global (or -g) only for a personal workflow that should apply across projects:

npx skills add vercel-labs/agent-skills \
  --skill web-design-guidelines \
  --agent codex \
  --global

Project-local skills are easier to review alongside the code they affect. Global skills reduce repetition, but they can also make two developers get different agent behavior from the same repository. Document any global skill that a shared workflow depends on.

Treat the directory as discovery, not proof of quality #

The skills.sh leaderboard is based on anonymous installation telemetry from the CLI. An install count can show interest, but it does not demonstrate that a skill improves task results, is current, or fits your project.

Before installing a public skill:

1. Open its source repository and read SKILL.md in full.
2. Inspect referenced files and every script the skill may execute.
3. Check its license, recent maintenance, dependencies, network access, and compatibility notes.
4. Look for instructions that conflict with your project versions or existing AGENTS.md rules.
5. Try it on one project and one repeatable task before making it global or installing it for every agent.

skills.sh says it runs routine security audits, but it also states that it cannot guarantee every listed skill. That is the right boundary to assume. A skill is instruction and sometimes code from another repository, not a sandbox or a trust decision.

The CLI’s anonymous telemetry can be disabled for a command with the documented environment variable:

DISABLE_TELEMETRY=1 npx skills add vercel-labs/agent-skills --list

More skills do not necessarily make an agent better #

Installing a skill does not increase the base model’s underlying capability. It gives the model additional instructions and resources. Useful instructions can make a specialized workflow more reliable; irrelevant or stale ones can consume context, constrain a good approach, or conflict with the repository.

The early evidence is mixed. A recent software-engineering skills benchmark reported only a 1.2% average improvement across 49 public skills. Thirty-nine showed no pass-rate improvement, while three reduced it. A broader SkillsBench study found a substantial average gain across several domains, but also found negative results on some tasks and better performance from focused skills than from comprehensive documentation.

Both are recent preprints rather than a final verdict. The practical lesson is still useful: evaluate a skill against the same task without it. Keep it when the result is more correct, repeatable, or maintainable—not merely because the agent produced a longer answer.

Use the smallest mechanism that solves the problem #

This distinction prevents a skill library from becoming a second, less visible configuration system. Skills are most useful for procedural knowledge that an agent should load only when a matching task appears. Durable repository-wide commands and boundaries belong in a focused instruction file; see what to put in AGENTS.md and CLAUDE.md for the evidence and a compact template.

Keep installed skills maintainable #

The CLI provides ordinary lifecycle commands:

# Show project and global skills
npx skills list

# Update one installed skill
npx skills update web-design-guidelines

# Remove it
npx skills remove web-design-guidelines

Review upstream changes before updating a skill used in production or across a team. If reproducibility matters, record the source and reviewed revision in the project documentation just as you would for another development tool.

The sensible default is narrow: install one reviewed skill in one project for the agents that need it. Expand to --agent '*', global scope, or --all only after the workflow has earned that reach.