Claude Code Skills vs Slash Commands vs Hooks: When to Use Each
Use Skills for reusable, document-driven workflows ('how to write a migration for this project'). Use slash commands for quick interactive actions triggered explicitly (/clear, /compact, /memory). Use hooks for automatic side-effects that should happen every time a tool fires (auto-format on file write, inject git status on every prompt).
The three mechanisms overlap in capability but have very different strengths. The confusion comes from the fact that all three can automate behavior — but they differ in when they trigger, how they're configured, and how much of Claude's reasoning they involve.
Skills are documents. They're Markdown files that Claude reads and follows. Skills are great for encoding multi-step workflows that require judgment — workflows where the exact steps depend on the specific situation, where examples matter, where context from your project is essential. Skills require explicit invocation (or Claude recognizes the task matches a skill).
Slash commands are interactive shortcuts. Built-in slash commands (/clear, /compact, /memory, /help) trigger Claude Code's internal functionality. Custom slash commands are not yet a fully separate mechanism — they're typically implemented via skills with a matching name. Use slash commands when you want a one-keystroke trigger for something you do frequently in interactive sessions.
Hooks are automated side-effects. They're shell commands that Claude Code runs when specific events occur (before/after tool use, on session start/stop, on every prompt). Hooks don't involve Claude's reasoning — they're pure shell scripts. Use hooks when you want something to happen automatically, unconditionally, every time an event fires, regardless of what Claude is working on.
Decision framework: Is the action conditional on Claude's judgment? → Skill. Is it an interactive command you trigger explicitly? → Slash command (implemented as skill). Does it need to happen automatically every time an event fires? → Hook. Is it a project-wide context fact? → CLAUDE.md. Is it a permission or tool configuration? → settings.json.
The most powerful setups combine all three: CLAUDE.md provides project context, Skills encode team workflows, Hooks enforce quality gates (auto-format, auto-test), and settings.json controls what tools are available. Each layer has a clear responsibility.
Examples
| Mechanism | Trigger | Reasoning | Example use case |
|---------------|--------------------|-----------|-------------------------------------------|
| CLAUDE.md | Every session | Yes | "We use Zod for validation" |
| Skill | Explicit/proactive | Yes | "Write a DB migration" |
| Slash command | User types /name | Varies | /clear, /compact, /help |
| Hook | Tool event fires | No | Auto-format after every file write |
| settings.json | Config only | No | Allow npm commands, pin model |// settings.json — fires automatically after every Write/Edit
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"command": "npx prettier --write $CLAUDE_TOOL_OUTPUT_PATH 2>/dev/null || true"
}
]
}
}# Skill: Security Review
## Description
Conduct a security-focused code review. Use when asked to review code for vulnerabilities,
authentication issues, injection risks, or secrets exposure.
## Checklist
1. Check for SQL injection: are all queries parameterized?
2. Check for XSS: is user input escaped before rendering?
3. Check for secrets: are any API keys or passwords hardcoded?
4. Check auth: are all routes protected with the auth middleware?
5. Check CSRF: are state-changing endpoints protected?
6. Check rate limiting: are public endpoints rate-limited?
## Output format
Report issues as:
- **[SEVERITY]** Description — file:line — suggested fixTips
- →If you find yourself writing the same prompt at the start of every session, it belongs in CLAUDE.md or a skill — not your head.
- →If you want something to happen without thinking about it, use a hook. If you want Claude to apply judgment, use a skill.
- →Hooks execute shell commands, not Claude prompts — they're fast, cheap, and reliable but not intelligent. Don't try to encode complex logic in hook commands.
- →A 'slash command' you type in interactive mode can be backed by a skill — create `.claude/skills/review.md` and type 'use the review skill' or just '/skill review'.
- →Test hooks in isolation before relying on them — run the hook command manually in your shell to confirm it works before trusting it in Claude's pipeline.
- →When in doubt, use a skill. Skills are the most flexible mechanism and can be refined iteratively without changing configuration files.
FAQ
Can hooks call Claude to process tool output intelligently?+
Hooks are shell commands, not Claude prompts — they run independently of the Claude session. If you need Claude to reason about tool output, that's a workflow to encode in a skill or handled via the PostToolUse hook result (hooks can return structured data that modifies what Claude sees, but this is advanced usage).
What's the difference between a PreToolUse hook and permissions?+
Permissions (in settings.json allow/deny lists) block or allow specific tool calls based on pattern matching — it's access control. PreToolUse hooks can run arbitrary shell logic before a tool fires and return a result that influences whether the tool runs. Hooks are more flexible but also more complex to write.
Are there limits on the number of skills I can have?+
No hard limit, but practical limits apply from context: Claude reads all skill descriptions at session start. If you have 50 skills, the descriptions alone consume significant context. Keep your active skill library to 10-15 skills and archive unused ones.