Claude Code Plugins, Skills, Subagents and Commands: Which to Use

Use a skill when you want Claude to follow a procedure or know some reference material, loaded only when it is relevant or when you type /name. Use a subagent when a side job would flood your conversation: it works in its own context window with its own tools and hands back a summary. A command is the older single-file form of a skill and does the same thing. A plugin is not a fourth kind of extension at all; it is a package that bundles skills, subagents, hooks and MCP servers so they install as one unit. Hooks and MCP servers are the remaining two extension points: hooks run something every time an event happens, and MCP servers connect Claude to systems it cannot otherwise reach. Anthropic’s overview of extending Claude Code↗ (opens in a new tab) sorts them the same way. Below, each in a paragraph, then side by side, then a decision flow.

Skills: instructions that load when needed

A skill is a folder with a SKILL.md file: a name, a description, and instructions in Markdown, plus any scripts or reference files. Claude sees only the name and description until the skill is used, then loads the body into your conversation, where it stays. You can start one yourself as /name, or Claude can load it when your request matches the description. Skills can be reference (your API style guide) or action (your release checklist). Building one step by step is covered in how to create a Claude skill.

Commands: skills in their older form

Custom slash commands used to be their own feature. The Claude Code skills documentation↗ (opens in a new tab) now says they have been merged into skills: a file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way. Existing command files keep working and accept the same frontmatter apart from name and paths. If both exist with one name, the skill wins. So “commands vs skills” is no longer a real choice: write new ones as skills, because only a skill folder can carry supporting files.

Subagents: a separate worker with its own context

A subagent is a Markdown file in .claude/agents/ or ~/.claude/agents/ whose body is a system prompt, with frontmatter for its description, its tools and its model. According to the subagents documentation↗ (opens in a new tab), each runs in its own context window with its own permissions, and only its result comes back to the main conversation. Claude delegates when a task matches the description; you can also name the subagent in a request, or @-mention it to guarantee it runs. Its requests count toward the same usage limits as your session. Ready-made definitions are in Claude Code subagent examples, and how delegation works is in Claude Code Task tool vs subagents.

Plugins: the package

A plugin is a directory with a manifest at .claude-plugin/plugin.json and component folders beside it: skills/, agents/, hooks/hooks.json, .mcp.json. The plugins overview↗ (opens in a new tab) is explicit that skills, subagents, hooks and MCP servers all work without a plugin; you reach for one when you want several of them to travel together, to install the same setup in many repositories, or to publish versioned releases through a marketplace. Plugin skills are namespaced, so a review skill in my-plugin runs as /my-plugin:review and cannot clash with yours.

/plugin                                          # browse and install
/plugin install commit-commands@claude-plugins-official
claude --plugin-dir ./my-plugin                  # load a folder for one session

An enabled plugin is part of every session, not only the ones where you use it: the descriptions of its skills and agents sit in context on every turn, its MCP servers run, its hooks fire, and whatever it runs, it runs as you. Install the ones you use and read them first.

Hooks and MCP servers, briefly

• A hook is a handler registered in a settings file that Claude Code runs at a lifecycle event, such as after every edit or when Claude is about to stop. It can be a shell command, an HTTP request, an MCP tool call, a prompt or a subagent. It fires every time; Claude does not decide. That makes hooks the place for rules that must hold, as the hooks guide↗ (opens in a new tab) puts it. A worked example: Claude Code hooks that update a board.
• An MCP server gives Claude tools for a system it cannot reach on its own: a database, an error tracker, a task board. The server handles the connection and sign-in. Servers are added with claude mcp add at local, project or user scope; see MCP vs Claude skills for how the two divide the work.

Side by side

              Skill               Subagent             Command           Plugin
What it is    instructions and    a worker with its    one-file skill    a package of the
              reference files     own prompt, tools    (older format)    others, plus hooks
                                  and model                              and MCP servers
Lives in      .claude/skills/     .claude/agents/      .claude/commands/ installed from a
              <name>/SKILL.md     <name>.md            <name>.md         marketplace or
                                                                         --plugin-dir
Started by    you (/name) or      Claude, by its       you, typing       enabling it; its
              Claude, by its      description, or you  /name             parts start as
              description         by name or @                           they normally do
Context       body joins your     its own window;      same as a skill   whatever its parts
              conversation        only a summary                         add, every turn
                                  returns
Tools         yours; allowed-     only what its        yours             its parts'
              tools pre-approves  tools list grants
Shared by     committing it, or   committing it, or    committing it     a marketplace
              a plugin            a plugin

The one line that matters most is context. A skill adds to your main conversation; a subagent uses a separate window, so the reading it does never lands in yours. That is the whole reason to prefer one over the other for a given job, and it is why the two combine: a subagent can preload skills through its skills field, and a skill can run inside a subagent with context: fork.

When names clash

• Skills: enterprise beats personal, personal beats project. A project skill with the same name as a bundled one replaces it.
• Subagents: managed, then the --agents flag, then project, then user, then plugin.
• Plugin skills and agents are namespaced by the plugin, so they sit beside yours rather than replacing them.
• Hooks do not override at all: every registered hook fires for its event, whatever file it came from.

A decision flow

• Claude gets a convention or command wrong twice: write it in CLAUDE.md, not in any of these.
• You keep pasting the same procedure or checklist into chat: make it a skill.
• The procedure has side effects, such as a deploy: a skill with disable-model-invocation: true, so only you start it.
• A side task floods the conversation with search results, logs or test output: a subagent.
• A worker must be unable to do something, such as edit files: a subagent whose tools list leaves those tools out.
• Something must happen every single time, such as formatting after each edit or blocking a command: a hook.
• Claude needs data or actions in another system: an MCP server, usually with a skill that says how to use it well.
• A second repository, or a teammate, needs the same setup: package it as a plugin.

Most teams add them in roughly that order and never need all of them. Start with CLAUDE.md and one skill, and add the next piece when a specific problem asks for it.

Where the record of the work goes

None of these is a place to keep track of work. A subagent’s context disappears when it finishes, a skill holds procedure rather than state, and a plugin is configuration. What was done, what is left and who did it belongs on a board. Connect fenbs over MCP once and every piece above can use it: a skill can file a bug with fenbs_create_item, a subagent limited to reading and commenting can record results with fenbs_comment, and a hook can remind Claude to update the task before it stops. The board checks each call against the connection’s role and scopes and records it under the assistant’s name, so extensions change how Claude works without changing what it may do on the board.