--- title: "skills.sh: Install Skills Across AI Coding Agents" seoTitle: "skills.sh Guide: Install Skills Across Coding Agents" navTitle: "skills.sh guide" description: "Use the skills.sh CLI to install and maintain agent skills for Codex, Claude Code, and other coding agents without duplicating instructions." slug: skills-sh-install-skills-ai-coding-agents redirects: - skills-sh date: 2026-08-05 updated: 2026-08-05 author: Chatcode category: guide featured: true order: 6 keywords: - skills sh - npx skills - install skills for AI agents - manage agent skills faq: - q: "Can skills.sh install one skill for both Codex and Claude Code?" a: "Yes. Pass both agent names to the skills CLI, for example `--agent codex --agent claude-code`. The CLI installs a canonical copy and can link it into each agent's expected skills directory." - q: "How do I install a skill for every supported agent?" a: "Use `--agent '*'` with a specific `--skill`. The broader `--all` option installs every discovered skill for every agent without prompts, so review the source before using it." - q: "Are skills from skills.sh safe to install?" a: "Not automatically. skills.sh runs security audits but explicitly does not guarantee every skill's quality or safety. Read SKILL.md, scripts, references, dependencies, and requested access before installation." --- 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](https://skills.sh/) provides a directory for discovering agent skills. Its open-source [`skills` CLI](https://github.com/vercel-labs/skills) 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: ```bash npx skills add vercel-labs/agent-skills --list ``` Then install one skill for the agents that should use it: ```bash 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: ```bash npx skills add vercel-labs/agent-skills \ --skill web-design-guidelines \ --agent '*' ``` There is also a much broader command: ```bash 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](https://agentskills.io/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: ```bash 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](https://skills.sh/docs#how-are-you-securing-skills). 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: ```bash 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](https://arxiv.org/abs/2603.15401) 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](https://arxiv.org/abs/2602.12670) 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 | Need | Better starting point | | --- | --- | | Repeatable, tool-specific procedure with supporting files | A focused project skill | | Personal workflow used across many repositories | One reviewed global skill | | Rules every contributor and agent must always follow | Versioned project instructions such as `AGENTS.md` | | One unusual task | A direct prompt with the necessary context | | A deterministic policy or check | A script, test, formatter, or CI rule | | Old, generic, or conflicting guidance | No skill until the guidance is corrected | 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](/articles/agents-md-claude-md-best-practices) for the evidence and a compact template. ## Keep installed skills maintainable The CLI provides ordinary lifecycle commands: ```bash # 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.