AI Agent Skills, Subagents, MCP, and Plugins in Claude Code: Which to Choose

Right now in Claude Code there are five ways to do the same code review: a slash command, a skill, a subagent, a plugin, or simply a prompt in chat. And none of these ways is better than another by default—the choice depends on the task, the token budget, and who besides you will use it.

This guide is what I would have given myself a year ago. A tree of 4 questions, a ready-made “task → layer” matrix, and 5 common mistakes that burn tokens for every other vibe coder I work with.

About working with the service—in the Ailoot documentation.

What are skills, subagents, MCP, and plugins in one sentence?#

Before choosing, let's distinguish the terms. All four layers have one goal—to extend what Claude can do out of the box. But each layer has its own nature.

Skill is a directory with a SKILL.md file that describes when and how to apply a specific methodology. Anthropic compares a skill to instructions for a new employee: you don't dictate every step to them every day; you give them a procedure.

Subagent is a separate Claude session with its own context, launched from the main conversation. It has one key feature: isolation. A subagent can read 30 files, produce a summary, and return only that to the main chat. The main conversation's context stays clean.

MCP (Model Context Protocol) is an open standard from Anthropic for connecting Claude to external systems. In a blog post on November 13, 2025, Anthropic explained the distinction as clearly as possible:

Plugin is someone else's ready-made set of skills, subagents, hooks, and commands, packaged in a marketplace. Install it with a single line using /plugin install, and you get everything at once. If a skill is your own procedure, a plugin is a procedure purchased from another company.

In short, skills are recipes, subagents are specialized colleagues, and MCP provides external tools through which Claude can reach services and data. The token cost varies: a skill is the cheapest (it loads when triggered), while MCP is considerably more expensive (each connected server constantly takes up space in the context window).

Why 4 layers if you can use one CLAUDE.md?#

In the project described, CLAUDE.md is a large map of rules: where things go, how to publish, what agreements are in place. Without this file, Claude would start each new session from scratch.

But CLAUDE.md has a ceiling. Let me explain with three situations in which it stops working.

Situation 1: a rule only works sometimes. CLAUDE.md says, “always run npm run build before git push.” Claude reads it at the start of the session, nods, starts writing code after 25 messages, and forgets. I've caught myself pushing without a build three times already; those pushes failed in production. A correctly configured and tested hook can run a deterministic build check and reject the covered operation. Its coverage depends on the event and tool path: a Claude Code hook does not by itself intercept every push from another terminal or application. Verify that a deliberately failing build blocks the actual path you use.

Situation 2: a 15-step process that repeats. In the example described, every guide goes through 14 stages: research → structure → MDX → 7 parallel QA checks → production publishing → IndexNow. If I write a prompt each time saying “run Stage 1, then 2, then 3,” I'll burn tokens before I even get started. That's why this entire workflow is packaged in the build-guide skill—a 34 KB set of instructions launched with the phrase “let's make a new guide for the project.”

Situation 3: a task that devours context. To check an already published guide for freshness, Claude has to read a 30 KB livestream transcript, 20 retrospectives of 5 KB each, and compare them with the current site. If I do this in the main chat, by the end of the review I have 200K tokens of junk in my context. A subagent does the same work, returns only a 300-word summary to the main conversation, and closes.

Situation 4: I want the team to get the same templates I have. A ready-made set of rules for frontend design, hooks for publishing through Coolify, MCP for Playwright checks. That's a plugin: I package my setup, publish it in the marketplace, and a colleague installs it with a single line.

CLAUDE.md covers the basics: “how we do things here.” The 4 layers on top cover what CLAUDE.md physically cannot: repetition through triggers, context isolation, access to the outside world, and sharing.

When do you need a skill rather than CLAUDE.md?#

The test for a skill is simple: you catch yourself copying the same long prompt from your notes into chat. The third time is already a signal.

I currently have 7 directories in ~/.claude/skills/, including build-guide, build-reel-script, update-config, simplify, and keybindings-help. The most heavily used is build-guide (this guide was written using it). Inside is 34 KB of methodology: which stages to go through, which multi-agent QA checks to run, which gate conditions should stop the process, and which artifacts to save in /tmp/.

When not to make a skill.

• A rule like “answer in the user's preferred language” belongs in CLAUDE.md, not in a skill. A skill loads when triggered, but this rule should always apply.
• A one-time instruction like “run the refactoring now” belongs in chat, not in a skill.
• A task that needs a separate context can use a subagent; if it also follows a recurring procedure, keep that methodology in a skill.

The main anti-pattern. The most common mistake vibe coders make is cramming a procedure into a subagent when it should be a skill. A subagent costs more tokens (it has its own context), starts more slowly, and is often overkill. If the task fits into 1,500–2,000 words of methodology without reading external files, it's a skill.

How to structure a skill, what to put in the frontmatter, and which trigger phrases work—in the guide Claude Code Skills in 2026: How to Build a Personal Skills Library.

When do you need a subagent rather than a skill?#

A skill stores the methodology; a subagent does the work. They're different layers, often confused because both are launched “from chat.”

A subagent makes sense only for context isolation. The main Claude session has a budget of 200,000 tokens (or 1 million in beta). If you ask it in the main chat to read 30 files and analyze each one, you'll burn half the window on intermediate reading. A subagent does all the same work in a separate session and returns only the result to the main chat.

A concrete project example. Every guide goes through several parallel QA checks: style, quotes and facts against primary sources, structure for search engines, and integrity of internal and external links. Each check draws on its own context: a glossary of rules, WebFetch on dozens of URLs, and greps through the text.

If I ran all these checks in one chat, the context would eat me alive before the first one was finished. Running subagents in parallel with run_in_background: true solves this: they work in the background, the main chat moves on, and after 4–6 minutes I get compact reports and apply the changes.

A second example—heavy research. When I choose a topic for a new guide, 4 subagents gather signals in parallel:

• V1 - forums and communities over 14 days
• V2 - social networks
• V3 - video platforms + Anthropic blog
• V4 - SEO gaps

Each returns 30–40 items with virality scores. I collect them into a pool, weight them across 9 dimensions, and choose a winner. Without subagents, this stage stretches into 2–3 hours of burning the main context.

When not to make a subagent.

• A task that doesn't require reading files or using WebFetch belongs in the main chat.
• A repeatable procedure belongs in a skill, but may run inside a subagent when isolation is useful.
• External access needs an authorized tool such as MCP or a CLI; a subagent can use that tool when delegated the task.

The main anti-pattern. Creating a subagent named backend-engineer or qa in the hope that Claude will figure out when to use it. Specific subagents (such as migration-test-writer or api-route-reviewer) provide much better quality than generic ones. The more precise the subagent's name and instructions, the more accurately Claude will choose the right one.

How to create subagents for specific tasks, frontmatter syntax, and 5 ready-made examples—in the guide Claude Code Subagents in 2026: A Step-by-Step Guide.

When do you need MCP rather than a skill or subagent?#

Anthropic gave the shortest formula for the difference in a blog post: MCP connects Claude to data; skills teach Claude what to do with that data.

For example, a GitHub issue-review skill needs the issue content. Provide it through an authorized MCP tool, a CLI, or supplied text. The skill then defines how to review it and structure the findings; MCP access alone does not prescribe that procedure.

My specific MCP stack.

• Playwright MCP - visual QA for every guide. Open the page on desktop and mobile, check the container width and whether the blocks have rendered.
• Stitch MCP - access to the design system, generating components in the brand style.
• vidIQ MCP - trend analysis and checking ideas for virality.
• Railway MCP - managing deployment infrastructure.

Each of these 4 is a bridge to an external system. Without MCP, I'd either write my own wrapper code or switch to a browser. With MCP, everything happens inside the Claude session.

Token cost. MCP is the most expensive layer. Each connected server constantly takes up space in the context window: tool declarations, argument schemas, and descriptions. I have 4 MCP servers—that's about 8–12K tokens in every new session before I've asked anything.

This means we connect MCP only if it's actually needed in most sessions. If you use Sentry MCP once a week, it's better to enable it on demand with the --mcp sentry flag rather than keep it in the permanent list.

When not to use MCP.

• Methodology for “how to work with data” belongs in a skill, not MCP.
• A long reading task may benefit from a subagent; if some files or records are external, that subagent may also need MCP access.
• Publishing with one command calls for a hook or plugin, not MCP.

The main anti-pattern. Building an MCP server for something better handled by a skill. I saw an example in a public discussion: the author wrote an MCP server that provides “code review instructions.” But that isn't access to the outside world; it's a procedure. A skill does the same thing for 10 times fewer tokens.

A resource contention incident. I once had Playwright MCP hang with the error “Browser is already in use”—I had a Chrome window open at the same time, and MCP couldn't take control of the browser. This is an important lesson: an MCP server uses shared system resources. If the resource is contested (a browser, port, or file), think about isolation from the start.

A ready-made guide to connecting 7 working MCPs is in Claude Code MCP Servers in 2026: 7 Ready-to-Use Setups.

When do you need a plugin rather than a skill or subagent?#

Skills, subagents, and MCP are about your methodology. A plugin is someone else's ready-made methodology that you import into your setup.

In October 2025, Anthropic launched Claude Code Plugins, an official distribution mechanism. A plugin is a directory that can contain:

• its own slash commands
• its own skills
• its own subagents
• its own hooks
• its own MCP configs
• its own output styles

All of this is packaged into one bundle with plugin.json. Installation is one line in ~/.claude/settings.json or the command /plugin install <name>.

My specific plugin stack.

• frontend-design from the official claude-plugins-official—67 styles, 96 palettes, 57 font pairs, 13 frameworks. When I make a new block for the site or an email template, I load this plugin and get the entire library at once.
• playwright from the same official marketplace—a set of skills plus MCP configs for browser testing.
• telegram—a ready-made set for managing a Telegram account from Claude Code (policy, allowlist, pairing).
• trailofbits/skills—a set of security skills from Trail of Bits, a company I trust on security matters.

All 4 are three lines in settings.json. Without plugins, I'd spend hours building the same library by hand.

When not to use a plugin.

• If the methodology is entirely yours and doesn't scale to others, keep it as a skill.
• If you don't yet know who will use it, try it on yourself as a skill first.
• If you need to quickly put three files on a new machine, cp ~/.claude/skills/X /new/machine/.claude/skills/ will do.

The main anti-pattern. Using a plugin as a replacement for CLAUDE.md—for example, a plugin with rules on “how we do things in this project.” A plugin is designed for distribution and reuse. If rules are specific to one repository, they belong in CLAUDE.md, not a plugin.

Looking ahead to 2026: Anthropic is clearly moving toward a team marketplace for plugins. That means companies will be able to publish their internal methodologies as plugins, version them, and update them for all employees with one command. For a solo entrepreneur, that means: install what's ready and don't reinvent it.

Decision tree: 4 questions to ask before every task#

Question 1: is there a repeatable procedure worth keeping?

If yes, package the methodology as a skill in a SKILL.md file with a clear description of when to use it. This supplies the procedure; it does not itself provide external access or a separate context.

Question 2: should the work have a separate context or a focused delegated role?

If yes, use a subagent. Give it a precise task and tools. The same task can follow a skill’s methodology inside that isolated context.

Question 3: does the task need a tool or access to external data?

If yes, provide authorized access through MCP or another appropriate tool, such as an already configured CLI. A skill describes how to use that access; a subagent can be the actor using it.

Question 4: should this setup be distributed and maintained as a package?

If yes, use a plugin to distribute the relevant skills, agent definitions, hooks, or MCP configuration. The package can be your own or supplied by another author.

Combined example: a recurring GitHub issue review. A skill defines the review procedure and result format. A configured GitHub MCP or CLI supplies authorized issue access. A subagent can read a long issue thread in its own context and return findings. A plugin can distribute that combination to the team. All four answers can be “yes”; none cancels another.

5 layer-selection mistakes vibe coders make#

I see these 5 patterns once a week among the vibe coders I work with. Every other one makes at least one of them in their first week.

Mistake 1: subagent instead of skill.

Symptom: an author made a subagent for “writing a new blog post.” Every time they run the subagent, it loads, reads 2 KB of methodology, generates a post, and closes. After a week, the author notices that each run burns an extra 5K tokens loading the subagent.

What should happen: “how to write a post” is a methodology—that's a skill. The trigger is the phrase “new blog post.” The skill loads into the main chat and doesn't open a separate session. It's 3–5 times cheaper.

Mistake 2: MCP server instead of skill.

Symptom: an author wrote an MCP server that provides instructions on “how to do code review.” Tool declarations, argument schema descriptions, and documentation keep occupying context. Each request wastes 2–3K tokens on nothing.

What should happen: “how to do code review” is a procedure, not access to an external system. Use a skill. MCP is justified only if you need live access—for example, to Sentry to retrieve the latest errors.

Mistake 3: plugin instead of CLAUDE.md.

Symptom: an author packaged project rules (“always use strict TypeScript mode,” “don't use any dashes,” “use pnpm only, not npm”) into a plugin and installed it. Each new session now loads a plugin that duplicates what should be in CLAUDE.md.

What should happen: rules for one project belong in that project's CLAUDE.md. A plugin is for a methodology that scales to several people or repositories.

Mistake 4: trying to make a skill through a hook.

Symptom: an author saw that a hook runs automatically on an event (for example, before saving a file). They decided to make a “skill through a hook” so Claude would automatically apply the methodology on every edit. They got an endless trigger loop, burned context, and unpredictable behavior.

What should happen: a hook is deterministic code that runs a command, formats the result, or blocks an operation. A hook doesn't load a skill or invoke Claude. If you need to “always apply methodology X,” use either a skill with a trigger or an entry in CLAUDE.md.

Mistake 5: an extra layer when nothing is needed at all.

Symptom: an author hears about skills, reads guides, decides “I need to package this methodology,” and spends an evening creating a skill for a task that comes up once a month.

What should happen: a one-time task belongs in chat, ad hoc. A skill is justified only if you do this more than once a day. Otherwise, it's overengineering that then has to be maintained.

Across these examples, check the needs independently: procedure, context or role isolation, tool access, and distribution. Add each layer that has a concrete purpose; combine them when a task needs more than one.

Fragmentation: where Claude Code is headed in 2026#

What this means over the next six months to a year.

First: skills are becoming the main layer for procedural tasks. Anthropic is clearly betting on this layer as the cheapest and most predictable. If you don't understand why you'd need a skill in 2026, study it first. All the other layers will revolve around it.

Second: subagents are becoming specialized. The main story for subagents is context isolation for heavy tasks. Generic subagents like qa-engineer will disappear; specific ones like migration-test-writer and api-route-reviewer will remain.

Third: Anthropic's new announcements over 14 days—the /workflows command (May 28, 2026) for orchestrating dozens of subagents, and the Agent SDK billing split starting June 15—mean programmatic usage is moving to a separate pool. This is a signal that Anthropic is building infrastructure for automated systems of 10+ agents, rather than individual sessions.

For a vibe coder in 2026, this means one simple thing: the four layers will last at least another six months, then some will merge. But the four-question decision tree will still work after the merger—it's about the nature of the task, not the specific name of the layer.

Ready-made matrix: 10 typical tasks → the right layer#

The main rule for using this table is not to try to “do all 10 at once.” Most solo vibe coders get by with CLAUDE.md + 5–7 skills + 2–4 MCP servers. Subagents and plugins are added as a project grows.

What's next: how to build your workspace in Claude Code#

These five layers don't sit one after another; they fit inside one another. CLAUDE.md is the project's foundation, and the other four are connected as tasks grow.

Get to know Ailoot.