Second Brain

This is the official Claude Code tutorial part 2, where I cover more advanced concepts that help you get even more out of Claude Code. If you haven't read part one, I’d highly recommend it before you read this article. This builds directly on those fundamentals.

Part one went mega viral, but if you missed it, read it first here:

I've been a SWE for 7 years, between Amazon, Disney, and Capital One. The code I've shipped touches millions of users. Part one covered the basics that most people get wrong, but this post goes deeper into the systems underneath Claude Code that separate competent usage from exceptional usage.

There are 3 main capabilities that most people still don’t know how to use effectively, which are: skills, subagents, and MCP connectors. All of these capabilities are in the documentation, the only 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 me weeks to figure out, while some through trial and error. Hopefully it saves you some time.

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 (spoiler alert: they don’t). According to a detailed comparison from Qodo's engineering team, 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." The system applies internal safeguards that silently reduce your effective context. I cover why context is so important in part 1.

While you could get pissed at Cursor for having these limitations, you have to understand that different tools are optimized for different workflows. 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. So for larger projects I would recommend using Claude Code directly. Claude Code delivers the full 200K consistently.

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.

A skill is a markdown file that teaches Claude how to do something specific to your work. When you ask Claude something that matches a skill's purpose, it automatically applies it. The structure is dead simple.

Create a folder with a

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

Every

starts with YAML frontmatter:

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:

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. It’s awkward to write in this format at first (since writing normally-sounding English sentences is your usual), but the difference in quality is noticeable.

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 that is relevant, which means that 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

. Claude will read it only when needed.

Also important to note that 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)

A subagent is a separate Claude instance with its own context window, system prompt, and tool permissions. This is where Claude Code's architecture really differentiates itself. When Claude delegates to a subagent, that subagent operates independently and returns a summary to the main conversation.

It’s important to remember that 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, which means your main conversation stays clean.

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

Just like you need a custom skill, I would highly recommend creating your own 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).

An exemplar structure:

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:

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 commands. For an implementation agent, include write, edit, and bash commands.

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:

Main agent identifies a task suitable for delegation
Main agent invokes subagent with a specific prompt describing the task
Subagent executes in its own context window
Subagent returns a summary of findings/actions to main agent
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:

Main Agent

|── Delegates research to Explore subagent │ └── Returns: "Found 3 relevant files:

" |── 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 → 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,