What are Skills?
Skills are like commands, but they activate automatically based on context rather than requiring you to type a slash command. They're markdown files stored in .claude/skills/ directories.
You can also trigger skills by simply asking for what they do — say "deploy my app" and if there's a deploy skill, Claude will load and follow its instructions without you needing to know the slash command.
The key difference from commands is the description field in the frontmatter — it acts as a trigger. It contains keywords and phrases that Claude matches against your conversation.
How Skills Work
---
description: Deploy applications to Vercel. Use when the user says
"deploy", "deploy to Vercel", "push to production", "deploy my app",
or "go live".
---
# Deploy to Vercel
1. Check if Vercel CLI is installed
2. Run `npx vercel --prod`
3. Display the deployment URLIf you say "deploy my app" in conversation, Claude recognises this matches the skill's description and automatically loads the skill's instructions.
Skills vs Commands
| Commands | Skills | |
|---|---|---|
| Stored in | .claude/commands/ | .claude/skills/ |
| Triggered by | You type /name (explicit) | Claude decides automatically, or you just ask (implicit) |
| Use case | "I want to run this now" | "Claude should do this whenever relevant" |
Skills and commands often come in pairs within a plugin — the same capability available both ways. A Vercel plugin might have both a /deploy command and a deploy skill, so you can either type /deploy or just say "deploy my app."
How do skills differ from commands?
When to Use Skills
Skills are best for low-cost, high-frequency operations that should happen automatically:
- Formatting PR descriptions when you create a PR
- Suggesting test patterns when you write a new function
- Auto-applying code style rules when editing specific file types
Cost warning: Skills activate automatically, which means they can fire when you don't expect them. An expensive multi-agent skill (like a full code review) should be a command, not a skill — you want deliberate control over when it runs. Reserve skills for lightweight, cheap operations.
Why should expensive multi-agent workflows be commands rather than skills?
Skill Design Tips
Write clear trigger descriptions
Bad: "Helps with deployment"
Good: "Deploy applications to Vercel. Use when the user says 'deploy', 'push to production', or 'go live'."
The description needs to give Claude enough signal to match accurately. List specific trigger phrases.
What makes a good skill trigger description?
Keep skills focused
A skill should do one thing. If you find yourself writing a multi-phase skill with subagent orchestration, it should probably be a command instead.
Consider false positives
If your skill triggers on common words, it'll activate when you don't want it. "Use when the user mentions 'code'" is too broad. "Use when the user asks to 'review this PR' or 'check my pull request'" is specific enough.
- Making expensive operations skills. A skill that launches parallel agents every time you mention "bug" will drain your API budget fast. Expensive operations should be commands.
- Using vague trigger descriptions.
"Helps with code"matches almost everything. Be precise: list the exact phrases that should trigger. Ask yourself: "Would I be annoyed if this activated right now?" - Duplicating skill and command with different instructions. If you have both a
/deploycommand and a deploy skill with different instructions, results will be inconsistent. Point both at the same logic.
Key Takeaway
Skills are autopilot behaviours — the same as commands mechanically (markdown files with instructions), but activated by context matching or natural conversation rather than explicit invocation. Use them sparingly for lightweight, frequently-needed operations.