Subagents, Skills, and MCP - The Newest Power of Claude Code

The deepest treasure cave of them all, @name! You are about to meet the features that are the freshest additions to Claude Code: subagents, skills, and the MCP protocol. These are what turn a single navigator into a whole well-drilled crew.

Subagents

A subagent is a specialized agent with its own system prompt and its own toolset, one that Claude can delegate focused tasks to. Picture sending a separate deckhand off to a specific job - one reviews the code, another writes the tests, and both can be working at the same time. It is not a second installation of Claude Code on another computer, and it is not a graphical plugin for the VS Code editor: a subagent lives inside your session, and it still runs on a full AI model, just with a narrower brief.

Where do subagents live?

You define them in markdown files in the

.claude/agents/<name>.md

directory. Each file carries its own system prompt and its own list of available tools - there is no "agents" section in

package.json

to fill in, and no

CLAUDE_AGENTS

environment variable anywhere in the picture. Writing your own crewmate is very much something you can do.

Here is what a code reviewer subagent looks like:

1# .claude/agents/code-reviewer.md
2---
3description: Reviews code for bugs and security issues
4tools: Read, Grep, Bash
5---
6
7You are an experienced code reviewer. You look for logic errors,
8security holes, and violations of good practice. Be concise -
9report only real problems.

The frontmatter at the top decides when Claude reaches for this crewmate and how much rope it gets:

description

drives the delegation decision, and

tools

limits what the agent may touch. A reviewer holding only

Read

and

Grep

can inspect the cargo but never rewrite it. A

test-writer.md

sitting in the same folder would also get

Edit

and

Write

, because producing test files is exactly its duty.

Why bother?

• Specialization - a separate agent (e.g.

  code-reviewer

  ,

  test-writer

  ) concentrates on one thing
• Parallelism - several tasks can be carried out at once
• A cleaner context - a subagent's work never clutters the main conversation

Managing subagents

Once a few crewmates are on the roster you need a way to see them and shape them. Inside a running session, one command covers the lot:

1/agents

It lets you create, browse, and edit your subagents. Claude then decides on its own when to hand a task to the right specialist - say "review my latest changes" and

code-reviewer

steps up. You can also summon one by name: "use the code-reviewer agent on @src/auth.ts".

Skills

Skills are reusable, model-invoked capabilities. They behave like ready-made procedures that Claude can run at the right moment. You invoke one - or Claude invokes it for you - via

/<skill-name>

:

1# Example: invoking a skill named "deploy"
2/deploy

So a skill called

deploy

is fired with

/deploy

, exactly like a slash command. There is no

--skill

flag to pass at startup, and nothing to hand-edit inside

node_modules

- if the skill exists, it is one slash away. Skills earn their keep on repeatable workflows: the same run of steps you perform over and over again.

MCP - Model Context Protocol

MCP (Model Context Protocol) is a standard that connects Claude to external tools and data - GitHub, databases, Slack, a browser, Sentry, and plenty more. It is like bolting extra instruments onto the compass so the navigator can see further than your own files. It is not a compression format that shrinks the Claude model, it does not delete your conversation context, and it is certainly not a programming language out to replace TypeScript. It is a connection standard, nothing else.

Adding an MCP server

There are two ways to attach a server to your ship. The quickest is a single terminal command that registers it for you:

1# Add an MCP server from the terminal
2claude mcp add <name> <command>
3
4# Example: an MCP server over HTTP
5claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

Read that first line as four parts in order:

claude

, then

mcp

, then

add

, then

<name> <command>

- the name you will refer to the server by, followed by the command that launches it. Alternatively you can declare your MCP servers in an

.mcp.json

file inside the project, which is the better call when the whole crew shares one repository.

Managing MCP servers

Servers come and go, and some of them need authenticating before they will talk to you at all. In a session:

1/mcp

This command shows the connected MCP servers and lets you manage them - see what is attached, log in, or disconnect. You can also load an MCP configuration at startup with the

--mcp-config

flag:

1claude --mcp-config ./mcp-servers.json "Check the latest errors in Sentry"

With that one line Claude boots up already wired to your servers, so the first thing it does is reach through MCP for real data instead of guessing from memory.

Why MCP?

Thanks to MCP, Claude Code can, for instance:

• read and comment on issues and PRs on GitHub
• query your database
• pull errors from Sentry
• drive a browser

How does it all play together?

Picture the task "add a feature and make sure it works":

1. The main Claude plans the change (Plan Mode from the previous exercise)
2. It implements the code, reading and editing files
3. It delegates the review to the

   code-reviewer

   subagent
4. It runs a skill for the repeatable workflow (deployment, for example)
5. Through MCP it checks Sentry for errors that showed up after the change

The whole crew pulls on the same rope - and that is exactly what modern vibecoding with Claude Code looks like.

Summary

Subagents - specialized agents in

.claude/agents/<name>.md

, managed with

/agents

Skills - reusable capabilities invoked via

/<skill-name>

MCP - a connection to GitHub, databases, Slack, Sentry;

claude mcp add

or

.mcp.json

Managing MCP - the

/mcp

command, the

--mcp-config

flag Synergy - planning + implementation + a reviewer subagent + a skill + MCP

In the last exercise you will meet hooks, headless mode, and the complete vibecoding workflow!

Open the sandpack below and study real crew files: a read-only reviewer, a test writer, and a cheat sheet for delegating work to them.

See you on deck!