Questions about Claude skills, answered directly
Twelve questions that come before the reference: what a skill is not, where the files go, why one never fires, how to test one, and what changes between claude.ai, the API and Claude Code. Each answer opens with the short version and then says why it is true.
Are Claude skills the same thing as MCP servers?
No. A skill is a folder of written instructions that an agent reads when a task matches its description. An MCP server is a running process that exposes new tools over a protocol. Skills change how the agent works with what it already has. MCP changes what it can reach.
Where do Claude skills live on disk?
A skill is a directory whose name matches the name in its frontmatter, containing SKILL.md and any optional scripts, references and assets. Where that directory sits decides its scope: alongside a project for one repository, in your user configuration for every session you run.
How do you install a Claude skill?
It depends on where you use Claude. In Claude Code you copy the skill directory into ~/.claude/skills/ or a project's .claude/skills/, with no upload step. In claude.ai you upload the folder as a ZIP file, and with the Claude API you upload it through the Skills endpoints. A skill installed on one surface does not appear on the others.
Why does my skill never trigger?
Almost always the description. Only the name and description are loaded at startup, so that one field is the entire basis on which the agent decides a task matches. A description that says what the skill is, without saying when to use it, gives the agent nothing to match against.
Should this go in a skill or in the project instructions?
Project instructions are read on every task in that project. A skill is read only when a task matches its description. Put the things that are always true in the project instructions, and the things that are true for one kind of work in a skill.
How much context does an installed skill use?
Around 100 tokens each while idle, because only the name and description are loaded at startup. The body of SKILL.md is loaded when the skill activates, and the recommendation is to keep that under 5,000 tokens. Files under scripts, references and assets are read only when a task needs them.
Can a Claude skill run code?
A skill can carry executable code under scripts/, and the agent may run it when the task calls for it. The skill does not run on its own and has no background process. It is the agent that executes, under whatever permissions your setup gives it.
How do you share skills across a team?
Keep them in the repository they apply to and let version control do the distribution. Everyone who clones gets the same skills at the same revision, changes arrive through review like any other change, and there is no separate copy to drift.
How are skills different from slash commands and plugins in Claude Code?
In Claude Code, custom slash commands have been merged into skills: a file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy. A plugin is a different layer. It packages skills with agents, hooks and MCP servers so they install as one unit, and its skills run as /plugin-name:skill-name.
Do skills work the same in claude.ai, the API and Claude Code?
The SKILL.md format is shared, but each product installs skills its own way. claude.ai takes a zip upload for one user, the Claude API takes uploads for a whole workspace, and Claude Code reads folders from disk. A skill uploaded to claude.ai is not available through the API, or the other way round.
What does allowed-tools do in a skill's frontmatter?
It lists tools a skill may use without a permission prompt. The specification defines it as a space-separated string of pre-approved tools and marks it experimental. In Claude Code the approval lasts only for the turn that invokes the skill, and it restricts nothing: unlisted tools stay available under your usual permission settings.
How do you test whether a skill actually works?
Check two things separately: whether the skill triggers on the requests it should, and whether its output is what you wanted. Run a few realistic prompts in a fresh session with the skill available, then again with it switched off, and compare. Triggering only shows that the skill was found, not that it helped.