Skills vs Slash Commands, Subagents, Hooks, and MCP: Which to Use?

Use a skill for a reusable procedure or body of knowledge Claude should load on demand; use CLAUDE.md for short facts every session needs; use a hook for anything that must happen every time; use a subagent when a task needs its own context window; use an MCP server to connect Claude to a live external system; and use a plugin to package any of these for distribution. Custom slash commands still work, but they have been merged into skills, so new manual commands should be written as skills.

The rest of this guide puts all seven side by side and gives concrete rules for choosing.

Comparison table: skills, commands, subagents, hooks, MCP, CLAUDE.md, plugins

Feature	What it is	Where it lives	Loaded	Who triggers it	Best for
Skill	Folder with SKILL.md, optional scripts and references	.claude/skills/<name>/	Metadata always; body on invocation	Claude (automatic) or you (/name)	Procedures, checklists, domain playbooks
Slash command	Single Markdown file	.claude/commands/<name>.md	When you type it	You	Legacy shortcuts; now merged into skills
Subagent	Separate agent with its own prompt, tools, and context	.claude/agents/<name>.md	When delegated to	Claude or you	Isolated research, parallel work, scoped tools
Hook	Command run on a lifecycle event	settings.json	On every matching event	Claude Code itself	Guaranteed enforcement and automation
MCP server	Process exposing tools and resources	.mcp.json or settings	Tools available from session start	Claude calls tools	Live access to external systems
CLAUDE.md	Markdown memory file	Repo root, subdirs, ~/.claude/	Every session	Always on	Facts needed in most sessions
Plugin	Bundle of skills, agents, hooks, MCP config	Installed from a marketplace	Per component	Per component	Distributing a toolkit

The key distinction is when context is paid for. CLAUDE.md costs tokens in every session. A skill costs about 100 tokens for its description until it is used. A subagent’s work happens in a separate context and only its result returns. A hook costs nothing in context because it runs outside the model.

Skills vs slash commands

Custom slash commands (.claude/commands/*.md) have been merged into skills. Both create /name. If a skill and a command share a name, the skill wins. Skills add three things commands never had:

• Supporting files: references, scripts, and templates next to SKILL.md.
• Automatic invocation: Claude can load a skill when your request matches its description. A command only runs when typed.
• Extra frontmatter: context: fork, paths, allowed-tools, model, and the rest.

To get command-like behavior from a skill, make it manual-only:

---
name: deploy-staging
description: Deploys the current branch to staging and posts the URL. Use only when explicitly invoked.
disable-model-invocation: true
argument-hint: "[service]"
---

Deploy $ARGUMENTS to staging:
1. Run `make test`. Stop if anything fails.
2. Run `./scripts/deploy.sh staging $ARGUMENTS`.
3. Print the preview URL from the script output.

Existing command files keep working, so migrate only when you want a skill-only feature.

Skills vs subagents

A skill adds instructions to the current conversation. A subagent is a separate Claude with its own system prompt, tool restrictions, and context window, and only its final answer comes back.

Question	Skill	Subagent
Does it see the conversation so far?	Yes	No, only the task it is handed
Does its work fill your main context?	Yes	No, only the result returns
Can it run in parallel with other work?	No	Yes
Can it have a restricted tool set?	Pre-approve with allowed-tools, block with disallowed-tools	Yes, its own tool list

The two combine in two directions:

• A skill can run inside a subagent. Set context: fork (and optionally agent: to pick the subagent type) and the skill executes in isolation. This suits a skill that reads 50 files to produce a one-page summary.
• A subagent can preload skills. A subagent definition in .claude/agents/ can list skills in a skills field so it starts with that knowledge.

---
name: security-reviewer
description: Reviews diffs for security issues. Use proactively after changes to auth, payments, or input handling.
tools: Read, Grep, Glob, Bash
skills: owasp-review
---

You are a security reviewer. Apply the owasp-review checklist to the diff you are given and report findings by severity.

Rule of thumb: use a skill when the procedure needs your conversation context; use a subagent when the work is self-contained and would otherwise flood your context. subagent-design covers the subagent side in detail.

Skills vs hooks

Skills are advice. Claude follows them when they are loaded, and they rely on the model’s judgment. Hooks are code that Claude Code runs on events such as before or after a tool call, at session start, or when Claude stops, regardless of what the model decides.

• “Always run Prettier after editing a file” is a hook.
• “Never write to .env” is a hook (or a permission rule).
• “When reviewing a PR, check these 12 things in this order” is a skill.

If a rule must never be skipped, a skill is the wrong container. Skills can declare hooks in frontmatter that apply while the skill is active, which is useful when a procedure needs a guardrail only during that procedure. For project-wide automation, see hooks-automation, and for permission rules, permissions-policy.

Skills vs MCP servers

An MCP server is a running process that gives Claude tools: query this database, create this ticket, read this design file. A skill is knowledge: how to do something well.

They are complementary. An MCP server for your issue tracker lets Claude create tickets; a skill teaches Claude your triage rules, labels, and severity definitions. One quick test: if the capability needs credentials, a network connection, or state, it is an MCP server. If it is a procedure you could write down, it is a skill.

Skills are also light on context: a skill costs only its description until it is used, so documenting a procedure as a skill is cheaper than wrapping it in a server that exposes tools just to return instructions. If you are building a server, mcp-server-builder walks through it.

Skills vs CLAUDE.md

Both are Markdown instructions. The difference is loading:

	CLAUDE.md	Skill
Loaded	Every session, in full	Description always; body on demand
Size budget	Keep it short	Body up to about 500 lines, plus unlimited references
Can bundle scripts	No	Yes
Best content	Build commands, repo map, conventions	Procedures for specific tasks

When CLAUDE.md grows past what every session needs, the task-specific sections should become skills. A 200-line “how we do releases” section is paying rent in every debugging session. memory-file-architect helps with that split.

Skills vs plugins

A plugin is not an alternative to a skill; it is a package. A plugin directory can contain skills/, agents/, hooks/, and .mcp.json, and it is distributed through a marketplace:

/plugin marketplace add your-org/claude-plugins
/plugin install backend-toolkit@your-org

Plugin skills are namespaced, so /backend-toolkit:migration-review never collides with a personal migration-review. Use a plugin when you want to version and distribute several components together across many repositories. For a single repo, committing .claude/skills/ is simpler. See Share skills with your team.

How to choose: a decision list

Work through these in order and stop at the first yes:

1. Must it happen every time, with no exceptions? Use a hook or permission rule.
2. Does Claude need live access to an external system? Use an MCP server, optionally with a skill for the procedure.
3. Is it a fact needed in most sessions? Put it in CLAUDE.md, briefly.
4. Is it a task that would flood context or can run in parallel? Use a subagent, or a skill with context: fork.
5. Is it a repeatable procedure or domain knowledge? Use a skill.
6. Only a shortcut you type yourself? Use a skill with disable-model-invocation: true.
7. Do several of these need to ship together to many repos? Wrap them in a plugin.

A worked example: one workflow, four features

Consider “safe database changes” for a team:

• CLAUDE.md: one line saying migrations live in db/migrations and run with make migrate.
• Skill: schema-migrations with the lock-safe DDL rules and review checklist.
• Hook: a PreToolUse hook that blocks make migrate against production hosts.
• MCP server: a read-only Postgres connection so Claude can check table sizes before judging a migration.

Each piece does the job it is suited for, and none duplicates another.

Next steps

• Understand skills first: What are Claude Code skills?
• Build a skill: Write your first Claude Code skill
• Package and distribute: Share skills with your team
• Related skills: subagent-design, hooks-automation, mcp-server-builder, plugin-marketplace-publisher
• Browse the claude-code category