There are three Claude Code capabilities that most people still don’t know how to use effectively: skills, subagents, and MCP connectors. All of these are in the documentation. The problem is that the documentation doesn’t tell you how these pieces fit together in practice, or which configurations actually matter for real work.

What follows is everything I’ve learned about these systems after using them daily to build production software. Some of this took weeks to figure out through trial and error. Hopefully it saves you some time.

The Context Window Problem

Before we get into the advanced features, there’s something fundamental that affects everything else. If you’re using multiple AI coding tools, you’ve probably assumed they all handle context the same way.

They don’t.

According to AI Coding Assistant Context Window Comparison by Qodo Engineering, Claude Code provides a “more dependable and explicit 200K-token context window,” while Cursor’s “practical usage often falls short of the theoretical 200K limit” due to “internal truncation for performance or cost management.”

I’m not saying this to bash Cursor. Different tools are optimized for different workflows. But if you’re working on large, interconnected codebases where you need the model to understand how your authentication system connects to your API routes and how that connects to your database schema, that context matters.

This is also why the features I’m about to cover work so well in Claude Code specifically. Skills, subagents, and MCP connections all benefit from having predictable context to work with.

Skills: Teaching Claude Your Specific Workflows

The structure is dead simple:

1. Create a folder with a SKILL.md file: ~/.claude/skills/your-skill-name/SKILL.md
2. Or for project-specific skills you want to share with your team: .claude/skills/your-skill-name/SKILL.md

Every SKILL.md starts with YAML frontmatter:

1
2

name: code-review-standards
description: Apply our team's code review standards when reviewing PRs or suggesting improvements. Use when reviewing code, discussing best practices, or when the user asks for feedback on implementation.

The description is critical. Claude uses it to decide when to apply the skill. Be specific about the trigger conditions. You can also explicitly tell Claude to “utilize x skill” and it will do so. But the goal is for Claude to recognize when it needs to utilize the skill on its own accord.

Below the frontmatter, write the actual instructions in markdown. Here’s a minimal example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

---
name: commit-messages
description: Generate commit messages following our team's conventions. Use when creating commits or when the user asks for help with commit messages.
---

# Commit Message Format

All commits follow conventional commits:
- feat: new feature
- fix: bug fix
- refactor: code change that neither fixes nor adds
- docs: documentation only
- test: adding or updating tests

Format: `type(scope): description`

Example: `feat(auth): add password reset flow`

Keep the description under 50 characters. If more context is needed, add a blank line and then the body.

How Skills Stay Lightweight

The key architectural principle is progressive disclosure. Claude pre-loads only the name and description of every installed skill at startup (roughly 100 tokens each). The full instructions only load when Claude determines the skill is relevant.

This means you can have dozens of skills available without bloating your context.

You can add supporting files to your skill folder. If you have extensive reference material, put it in a separate file and reference it in SKILL.md. Claude will read it only when needed.

Skills Beyond Code

Skills aren’t limited to just code. I’ve seen engineers build skills for:

• Database query patterns specific to their schema
• API documentation formats their company uses
• Meeting notes templates
• Even personal workflows like meal planning or travel booking

The pattern works for anything where you find yourself repeatedly explaining the same context or preferences to Claude.

To see what skills are currently loaded, ask Claude directly: “What skills do you have available?” It will list them. Or go settings, capabilities, scroll down and you’ll see skills.

Subagents: Parallel Processing With Isolated Context

This is where Claude Code’s architecture really differentiates itself.

Context degradation happens around 45% of your context window. Subagents let you offload complex research or implementation tasks to a fresh context, then bring back only the relevant results. Your main conversation stays clean.

Built-in Subagents

Claude Code includes three built-in subagents:

Explore: A fast, read-only agent for searching and analyzing codebases. Claude delegates here when it needs to understand your code without making changes. When used correctly, Claude specifies thoroughness: quick, medium, or very thorough.

Plan: A research agent used during plan mode to gather context before presenting a plan. It investigates your codebase and returns findings so Claude can make informed architectural decisions.

General-purpose: A capable agent for complex, multi-step tasks requiring both exploration and action. Claude delegates here when the task needs multiple dependent steps or complex reasoning.

Creating Custom Subagents

Run /agents in Claude Code to see all available subagents and create new ones.

To create one manually, add a markdown file to ~/.claude/agents/ (user-level, available in all projects) or .claude/agents/ (project-level, shared with your team).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

---
name: security-reviewer
description: Reviews code for security vulnerabilities. Invoke when checking for auth issues, injection risks, or data exposure.
tools: Read, Grep, Glob
---

You are a security-focused code reviewer. When analyzing code:

1. Check for authentication and authorization gaps
2. Look for injection vulnerabilities (SQL, command, XSS)
3. Identify sensitive data exposure risks
4. Flag insecure dependencies

Provide specific file and line references for each finding. Categorize by severity: critical, high, medium, low.

The tools field controls what the subagent can do. For a read-only reviewer, restrict to Read, Grep, and Glob. For an implementation agent, include Write, Edit, and Bash.

How Subagents Communicate

This is the part most people miss. Subagents don’t share context directly with each other since they’re operating in isolation. Communication happens through the delegation and return pattern:

1. Main agent identifies a task suitable for delegation
2. Main agent invokes subagent with a specific prompt describing the task
3. Subagent executes in its own context window
4. Subagent returns a summary of findings/actions to main agent
5. Main agent incorporates the summary and continues

The summary is the key. A well-designed subagent doesn’t dump its entire context back. This is why subagent descriptions and system prompts need to be explicit about output format.

For complex workflows, you can chain subagents. The main agent orchestrates:

1
2
3
4
5
6
7

Main Agent
 |-- Delegates research to Explore subagent
 |   └── Returns: "Found 3 relevant files: auth.py, middleware.py, routes.py"
 |-- Delegates implementation to custom implementer subagent
 |   └── Returns: "Added password reset endpoint, updated 2 files"
 └── Delegates testing to custom test-runner subagent
     └── Returns: "All 12 tests passing, coverage at 94%"

Each subagent gets fresh context for its specific task. The main agent only holds the summaries, not the full exploration history. This prevents the context pollution that kills long coding sessions.

One important constraint: subagents cannot spawn other subagents. This prevents infinite nesting and keeps the architecture predictable.

Practical Subagent Patterns

Large refactoring: Have the main agent identify all files that need changes, then spin up a subagent for each logical group. Each subagent handles its scope and returns a summary. The main agent never needs to hold the full context of every file simultaneously.

Code review pipeline: Create three subagents (style-checker, security-scanner, test-coverage) and run them in parallel against a PR. Each returns findings in a consistent format. The main agent synthesizes into a single review.

Research tasks: When you need to understand an unfamiliar part of the codebase, delegate to Explore with specific questions. It returns a distilled map of relevant files and patterns, keeping your main context focused on the actual implementation work.

MCP Connectors: Never Leave Claude

You don’t have to go into GitHub. You don’t have to go into Slack, Gmail, Drive. You can get Claude to talk to all of those through the Claude interface via an MCP server.

1
2
3
4
5
6
7
8
9

# HTTP transport (recommended for remote servers)
claude mcp add --transport http <name> <url>

# Example: Connect to Notion
claude mcp add --transport http notion https://mcp.notion.com/mcp

# With authentication
claude mcp add --transport http github https://api.github.com/mcp \
  --header "Authorization: Bearer your-token"

What MCP Has Done for Me

Some examples from the last 6 months:

• Implement features from issue trackers: “Add the feature described in JIRA issue ENG-4521”
• Query databases: “Find users who signed up in the last week from our PostgreSQL database”
• Integrate designs: “Update our email template based on the new Figma designs”
• Automate workflows: “Create Gmail drafts inviting these users to a feedback session”
• Summarize Slack threads: “What did the team decide in the #engineering channel about the API redesign?”

The power isn’t any single integration. A workflow that used to require five context switches (check the issue tracker, look at the design, review the Slack discussion, implement the code, update the ticket) now happens in one continuous session.

Recommended MCP Servers

• GitHub: Repository management, issues, PRs, code search
• Slack: Channel history, thread summaries, message search
• Google Drive: Document access for reference during implementation
• PostgreSQL/databases: Direct queries without leaving Claude
• Linear/Jira: Issue tracking integration

Third-party MCP servers aren’t verified by Anthropic, so be careful. For sensitive integrations, review the server’s source code or use official connectors from the service providers.

The Compound Effect

Here’s where this all comes together. A skill that knows your codebase patterns + a subagent that handles testing + MCP connections to your issue tracker = a system that is unmatched.

The skill encodes your team’s conventions. You don’t need to worry about explaining context every time. The subagents keep your main conversation clean while handling complex subtasks. The MCP connections eliminate the context switching that fragments your attention.

The engineers I’ve watched who get the most from Claude Code aren’t using it for one-off tasks. They’re treating it as a system to multiply their work capabilities. They invest time configuring skills, defining subagents, connecting services. That investment pays dividends on every subsequent task.

If you’re scared of where to start, just start with one skill for something you explain repeatedly. Or create just a singular agent. Test and go from there. No need to overwhelm yourself with trying everything at once.