What to Choose: Command, Skill, Subagent, MCP, or Hook

By this point, the section has covered each extension mechanism individually. This article has one purpose: to give you a tool for choosing between them in any given situation. A wrong choice doesn't break the system immediately, but the debt accumulates — commands stuffed with logic they can't handle; subagents where a skill would have sufficed; hooks that try to "reason." A well-designed customization stack means each mechanism does only what it was built to do.

Five Mechanisms: Key Differences

Output style is not in this table — it is not a functionality extension mechanism, but a configuration of agent behavior (tone, format, role). If the goal is to change what Claude does, see the table. If the goal is to change how Claude responds — that's an output style.

Decision Tree

flowchart TD
    A[New extension task] --> B{Lifecycle event?}
    B -->|Yes| C[Hook]
    B -->|No| D{External system?}
    D -->|Yes| E[MCP-server]
    D -->|No| F{Context isolation needed?}
    F -->|Yes| G[Subagent]
    F -->|No| H{Portable expertise?}
    H -->|Yes| I[Skill]
    H -->|No| K[Slash-command]

The tree is read top-to-bottom for any new task. If the answer to the first question is "yes," nothing else matters: you need a Hook.

Walkthrough by Concrete Scenario

#### "I want to trigger a standard code review with a single command"

→ Slash command. The classic template pattern: /review injects a prompt with criteria into the context, and $ARGUMENTS accepts a file name or specification. No logic needed, no isolation either.

# .claude/commands/review.md
---
description: Standard code review for a file or directory
---
Perform a code review for `$ARGUMENTS`.
Check: readability, potential bugs, conformance to project style.
Return a list of findings with line references.

The typical mistake is writing conditional logic into the command file ("if TypeScript, check types; if Python, check docstrings"). A command can't do that — it's a template, not a script. Conditional logic belongs in Skills.

#### "I want Claude to know our deployment procedure"

→ Skill. A deployment procedure is portable expertise: a SKILL.md with the steps plus any helper scripts alongside it. The skill loads only when needed (progressive disclosure) and doesn't occupy context the rest of the time.

The mistake is adding these instructions to CLAUDE.md. If they're only needed during deployment, not on every question about the codebase — they're dead weight in every session.

#### "I need to check 20 configuration files in parallel"

→ Subagent. Each file gets its own agent with an isolated context. The main session receives only the final summary. Without subagents, the entire exchange about 20 files would live in a single window, consuming a significant portion of the context window.

The anti-pattern is launching a subagent for a task that a single tool call can handle. A subagent is an expensive mechanism. For small tasks — use a skill or a direct request.

#### "I want Claude to run SQL queries against our database"

→ MCP server. This is the only right answer. MCP adds a tool — either a ready-made postgres server from the official registry or a custom one — that Claude can invoke at any point in the session. Neither a skill, a command, nor a subagent provides a direct connection to an external system.

#### "I want to automatically run prettier after every file edit"

→ Hook on PostToolUse (the Write event). This is a deterministic action that must always happen, without model involvement. A Hook is the only mechanism that guarantees execution regardless of Claude's decisions.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs prettier --write"
          }
        ]
      }
    ]
  }
}

The mistake is implementing this via a subagent or a skill. The model might "forget" to invoke the skill. A hook runs deterministically.

Overlaps: Where the Choice Isn't Obvious

Skill vs Slash command. Start with a command. When scripts, conditions, and helper files appear — graduate to a skill. That's the natural growth path.

Skill vs Subagent. One question: is context isolation needed? If the task is large and shouldn't "pollute" the main session — use a subagent. If you just need expertise that Claude applies right here — use a skill.

Hook vs Subagent. Hook — when something must happen deterministically and always. Subagent — when AI logic is needed to process the result. Example: auto-formatting → hook; code quality analysis with recommendations → subagent.

MCP vs Skill + Bash. Sometimes it's enough to add a bash script that runs curl inside a skill. MCP is justified when you need a persistent, interactive connection to a system with multiple operations: reading, writing, managing state. For a one-off external API call, a script inside a skill is often enough.

A Plugin Is Not a Sixth Mechanism

A Plugin is not another extension type — it's a way to package multiple mechanisms into a single installable unit. Once a customization stack has grown (commands + skills + hooks + MCP), a plugin lets you version and distribute it as one artifact — with a single plugin.json for the whole team.

See also

• Slash commands: built-in and custom — frontmatter details and $ARGUMENTS syntax
• Skills — portable expertise — SKILL.md, progressive disclosure, helper files
• Subagents and context isolation — when context isolation is critical
• Hooks — lifecycle events — PreToolUse, PostToolUse, Stop, SessionStart
• Model Context Protocol: architecture and fundamentals — MCP primitives: tools, resources, prompts
• Connecting MCP servers in Claude Code — claude mcp add and scopes
• Plugins and marketplace — packaging a stack into a single artifact
• Output styles and the status line — customizing agent behavior, not its capabilities
• CLAUDE.md and the memory system — where to put project context that isn't a skill