These five mechanisms aren't five competing options. They plug into different points of the agentic loop, solve different problems, and are often combined. The cost of picking the wrong one is usually either wasted context or something that should have happened not happening.
One-line answer
Answer
Choose by purpose: reusable knowledge and workflows go in a Skill; mandatory actions that must happen every time go in a Hook; connecting external tools and data is MCP; needing isolated context or parallelism means a Subagent; and only when you want to package and distribute the whole setup to other repos or teams do you reach for a Plugin — Plugins are a packaging layer, not a fifth standalone capability.
Steps
- Start with the decision table.OfficialThe official features-overview doc lays out each mechanism's role and its use cases; here it is as a comparison table (the "Not for" column is a reverse reminder from Our take):
Mechanism What it is Use it for Not for (use instead) Skill A markdown file holding knowledge, checklists, or workflows; invoke it with /name, and Claude can also auto-load it when relevantThe same prompt you keep pasting, API style guides, triggerable flows like /deployActions that "must happen every single time" (→ Hook); connecting external systems (→ MCP) Hook A script / HTTP request / prompt / subagent that always executes on lifecycle events (e.g. PostToolUse, SessionStart) Auto-lint after edits, blocking dangerous commands, a notification when the session ends — deterministic actions that need no model reasoning Flows where Claude has to judge how to act (→ Skill) MCP An open protocol for connecting external services, with servers providing tools and data access Querying a database, reading issues, posting to Slack, driving a browser — systems Claude otherwise can't see Knowledge about "how to use those tools well" (→ Skill; the two often pair up) Subagent An isolated worker with its own context window; when done, only a summary comes back to the main session Research that reads dozens of files, parallel tasks, keeping a side task from flooding the main context Content you want to reuse across sessions (→ Skill); multiple sessions talking to each other (→ agent teams) Plugin A packaging layer: bundles skills, hooks, subagents, and MCP servers into one installable unit; skills get a namespace ( /my-plugin:review)A second repo needs the same setup, or you're distributing to a team or the community Personal single-project config (just put it in .claude/)OfficialAnd don't forget the even more basic sixth option: "always do X" rules you must follow every time belong in CLAUDE.md — it's loaded in full at the start of every session, no trigger required.
- Self-check against the official trigger signals.OfficialThe official advice is not to set up every mechanism up front, but to add each one when its signal shows up: Claude gets the same convention wrong twice → write it into CLAUDE.md; you paste the same runbook for the third time → save it as a Skill; you keep copying data from the browser that Claude can't see → connect MCP; a side task's output floods the conversation → hand it to a Subagent; you want something to "happen automatically every time" → write a Hook; a second repo needs the same setup → package it as a Plugin.
- Two easy-to-confuse pairs — memorize the discriminators.OfficialSkill vs Hook: a Hook fires deterministically on its event (guaranteed), while a Skill relies on Claude understanding and following it (results can drift) — so guardrails must be Hooks. Writing "never edit .env" in CLAUDE.md or a Skill is only a request; a PreToolUse hook that blocks it is enforcement. Skill vs Subagent: a Skill is "loadable content", a Subagent is "an isolated execution environment", and the two compose — a skill can run in isolated context via
context: fork, and a subagent can preload skills through itsskills:field. - Do the context math before you decide.OfficialEach mechanism has a different context cost: CLAUDE.md is in every request, in full; a Skill keeps only its description resident and loads the full text on use; MCP loads only tool names, fetching schemas when used; a Subagent is fully isolated; a Hook runs externally and costs nothing unless it returns output. The scarcer your context (see the cost of installing too many MCP servers), the more heavy content should move into Skills, Subagents, and Hooks.
- Combine — don't single-pick.OfficialReal setups are usually combinations: MCP connects the database + a Skill records your schema and query habits; an
/auditSkill dispatches three parallel Subagents for security, performance, and style; a post-edit Hook runs lint and feeds the results back into context. For a deep dive into each mechanism, see lessons D7 Skills, D8 Hooks, D9 MCP, D10 Subagents, D14 Plugins.
Copy-paste prompt
I want to add a capability to Claude Code: <describe your need, e.g. "run eslint automatically after every file edit", "hand Claude the team's release checklist", "let Claude query our PostgreSQL">.
Following the official decision logic, tell me whether this should be a Skill, Hook, MCP,
Subagent, or Plugin (or a combination), explain why,
then generate the configuration directly:
- Skills go in .claude/skills/<name>/SKILL.md
- Hooks go under the "hooks" key in .claude/settings.json
- For MCP, give me the claude mcp add command
- Subagents go in .claude/agents/<name>.md
Finally, explain when this configuration gets loaded and how much context it consumes.
Sources & last verified
- Officialfeatures-overview (Extend Claude Code — decision table / trigger signals / context costs), fetched 2026-08-05.
- Officialskills, fetched 2026-08-05.
- Officialhooks-guide, fetched 2026-08-05.
- Officialmcp, fetched 2026-08-05.
- Officialsub-agents, fetched 2026-08-05.
- Officialplugins, fetched 2026-08-05.
- Last verified: 2026-08-05 · volatility:high (tied to Claude Code's current mechanism boundaries; as of version 2.1.222).