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

The deepest treasure cave of them all! 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 a code reviewer subagent, saved in the file .claude/agents/code-reviewer.md:

---
name: code-reviewer
description: Reviews code for bugs and security issues. Use after every code change.
tools: Read, Grep, Glob
---

You are an experienced code reviewer. You look for logic errors,
security holes, and violations of good practice. Be concise -
report only real problems.

The frontmatter at the top must start on the very first line, and it has two required fields. name is the agent's name - Claude Code simply skips a file without it. description tells Claude when to reach for this crewmate, and it drives the delegation decision. The optional tools sets the limits: a reviewer holding only Read, Grep and Glob 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

The easiest way to sign on a new crewmate is to ask for one - tell Claude in a session, and it writes the file in .claude/agents/ itself:

Create a code-reviewer subagent in .claude/agents/ that only reads code and reports bugs

In newer versions of Claude Code the /agents command no longer opens a wizard; it only reminds you of this route. 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>:

# Example: invoking a skill named "deploy"
/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. A skill itself is a folder with a SKILL.md file: a project skill lives in .claude/skills/<name>/SKILL.md, a personal one in ~/.claude/skills/<name>/SKILL.md, and the folder name becomes the command, so .claude/skills/deploy/SKILL.md gives you /deploy.

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:

# Add an MCP server from the terminal
claude mcp add <name> -- <command>

# Example: an MCP server over HTTP
claude 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, a double dash, and the command that launches it. The double dash separates Claude's own options from the server's command, so the server's flags (such as -y in npx -y) are not mistaken for Claude's options. 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:

/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. The prompt goes before the flag, because --mcp-config takes several files at once and would treat everything after it as another configuration file:

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

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; you create them by asking Claude or by hand 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!

---
name: code-reviewer
description: Specialist crewmate that reviews code for bugs, security, and quality. Read-only.
tools: Read, Grep, Glob
---

You are the ship's code-review specialist.

When the captain delegates a review:
1. Read the relevant files and grasp the intent.
2. Hunt for bugs, security holes, and performance problems.
3. Check naming, error handling, and type safety.

Report findings with severity, location, the problem, and a fix.
You hold read-only tools - you inspect the cargo but never change it.