How to Verify a Claude Code Skill Install Command (2026)

The install command that doesn't exist

Look up almost any Claude Code skill and the first thing you're handed is a command to paste:

claude skill add pdf-processor

Paste it, get an error. The command isn't real. It has never been in Anthropic's documentation. I re-read the official skills page on July 17, 2026 before writing this, and there's no claude skill add, no claude skills install, no CLI subcommand that fetches a skill from anywhere. The Claude Code CLI doesn't install skills. You do, with mkdir.

That fake command now sits in skill directories, README badges, and most "top 50 Claude Code skills" posts. I found it across a directory I help maintain: generated once by a model, copied for months, never run by anyone. Us included, for longer than I'd like.

A wrong command is a cheap failure. You lose thirty seconds and figure it out. The habit is what costs you. If you'll paste an install command without checking it, you'll paste the next one, and some of those write files, pre-approve tool permissions, or execute shell before Claude reads a single word.

Claimed command, is it real, what to run instead

The pattern worth noticing: everything real is either a filesystem operation you perform yourself, or a slash command typed inside Claude Code. Nothing real looks like npm install for skills. When a command has that shape, that's your tell.

What a real skill install looks like

A skill is a directory with a SKILL.md in it. Where you put the directory decides who can use it. The docs list four locations.

Personal, at ~/.claude/skills/<skill-name>/SKILL.md, available across all your projects. The whole install is:

mkdir -p ~/.claude/skills/summarize-changes

Then write SKILL.md inside it. The directory name becomes the command, so that one gives you /summarize-changes.

Project, at .claude/skills/<skill-name>/SKILL.md, scoped to one repo and committed to version control. This is how a team shares a skill: not through a registry, through git.

Plugin, where a marketplace hands you a bundle. Add the marketplace, then install:

/plugin marketplace add anthropics/claude-plugins-official
/plugin install skill-creator@claude-plugins-official

Plugin skills get namespaced as plugin-name:skill-name, so they can't collide with yours. The marketplace layer has its own trust questions, and we work through those separately in Claude Code plugin marketplaces.

Enterprise, deployed through managed settings by whoever runs your org.

When names collide, enterprise wins over personal, and personal wins over project. Worth knowing before you spend an afternoon debugging why your project's code-review skill seems to be ignoring you.

One detail that saves confusion: Claude Code watches those directories. Drop a new skill into ~/.claude/skills/ mid-session and it's live, no restart. If you created a top-level skills directory that didn't exist when the session started, that one needs a restart so the watcher picks it up.

The check, before you run anything

This takes about a minute and catches everything above.

1. Check the docs page, not a summary of it. Open code.claude.com/docs/en/skills and search that page for the literal command string. Search snippets, AI answers, and a directory's install field all sit downstream of that page, which means they can all be wrong together. If the string isn't on the page, the command isn't official. This step kills claude skill add in about four seconds.

2. Check the repo exists and has a pulse. Fabricated skills come with fabricated repos, or repos that 404, or repos with a single commit dated the same day as the blog post that recommends them. Open it. Look at the commit history and the issues tab.

3. Read the frontmatter before the body. Every SKILL.md opens with YAML between --- markers. Read that block first. It's where the skill declares what it's allowed to do, and it's short enough that there's no excuse.

4. Read allowed-tools carefully. This field pre-approves tools so Claude can use them without prompting you. A skill with allowed-tools: Bash(git add ) Bash(git commit ) is doing something reasonable. A skill claiming broad Bash access to summarize text is not. The docs say it plainly: review project skills before trusting a repository, since a skill can grant itself broad tool access.

5. Grep for shell injection blocks. A SKILL.md line like ` !git diff HEAD isn't documentation of a command. It runs, before Claude sees the content, and its output gets pasted into the prompt. Same for fenced blocks opened with ``! . This is a documented feature and a good one, but it means a SKILL.md is executable content, not prose. Search any skill you didn't write for ` ! ` and read every hit.

6. Prefer reading the file over piping it to a shell. If a skill's install instructions route through curl … | bash, you've been asked to run code you haven't read, to install a file whose entire purpose is to be read. Decline.

The permission trap under all of this

allowed-tools doesn't restrict anything. It's a permission grant, not a sandbox. The docs are explicit that every tool remains callable and your permission settings still govern the ones not listed. A skill can't lock itself down by listing three tools. It can only widen what happens silently.

For project skills, allowed-tools takes effect once you accept the workspace trust dialog for that folder, the same as permission rules in .claude/settings.json. So the trust dialog on a cloned repo isn't a formality about opening files. It's the moment you decide whether that repo's skills get to run tools without asking you again. Read .claude/skills/ before you click through it. If you're evaluating an unfamiliar repo, our guide to auditing an agent skill before installing it walks the same ground in more depth.

If you want the shell injection behavior off entirely for user, project, plugin, and additional-directory skills, "disableSkillShellExecution": true in settings replaces each command with a policy notice instead of running it. Bundled and managed skills aren't affected. That setting is most useful in managed settings, where users can't override it. Most people don't need it. Anyone running skills from repos they don't control probably does. We've written more on reducing the risk of community skills.

Why the fake command spread

It's not mysterious. Someone's model was asked to fill an install_command field for a skill directory. It had no real value to put there, and a plausible-looking string satisfies a schema exactly as well as a true one. So it wrote claude skill add <name>, which is what the command would obviously be called if it existed.

Then a second directory scraped the first. A blog post cited the second. A third model, trained or retrieved on all of it, now answers the question confidently and consistently. The consistency is the trap. Five sources agreeing means nothing when four of them copied the first, and the first was guessing.

This is why "check the primary source" beats "check multiple sources" for anything mechanical like a command string, a flag, or an API parameter. Counting how many sites agree tells you how widely something got copied. Whether it runs is a separate question, and only the docs page answers it.

Skills follow the Agent Skills open standard, which is part of why this gets muddled. The standard spans multiple tools, tools ship their own CLIs on top of it, and npx skills add vercel-labs/agent-skills is a real command from a real project that supports Claude Code among dozens of other agents. It's just not Anthropic's. A directory that flattens "works with Claude Code" into "official Claude Code command" produces exactly the confusion we're in. If the difference between these layers is fuzzy, skills vs MCP servers vs plugins sorts it out.

FAQ

Will claude skill add become real later?

Maybe, and it wouldn't retroactively excuse anything. The commands that exist today are the four locations plus /plugin. If Anthropic ships a fetch-and-install verb, it'll be on the docs page, and the check in this article will confirm it in four seconds. That's the point of having a check instead of a memory.

Is npx skills add safe?

It's a real tool from Vercel Labs, and "real" and "safe" are separate questions. It fetches skill files from a repo you name. The safety depends on the repo, not the CLI. Whatever it downloads still ends up as a SKILL.md on your disk with frontmatter you should read. Use it if it fits your workflow. Don't let a working install command substitute for reading what it installed.

Do I need to restart Claude Code after adding a skill?

No, for the common case. Claude Code watches ~/.claude/skills/, your project's .claude/skills/, and .claude/skills/ inside an --add-dir directory. Adding, editing, or removing a skill takes effect in the current session. Two exceptions: creating a top-level skills directory that didn't exist at session start needs a restart, and a skill folder that's also a plugin needs /reload-plugins` for changes to its hooks, agents, or MCP config.

A directory lists a skill with an install command but no repo link. What now?

Treat the entry as unverified and move on. A skill with no source is a description of a file that may not exist. There's nothing to read, nothing to audit, and no author to hold responsible for what the frontmatter grants. The install command is the least trustworthy field on that page and the only one most people read. If you want a way to think about which authors get less scrutiny, author trust tiers is the framework we use.