Mastering Claude Code (Part 3): Skills & Subagents — Building Automated AI Workflows

If you’ve been following along with this series, you’ve learned how to set up Claude Code and work with scheduled tasks. Now we’re diving into the real productivity unlock: skills and subagents. These are the difference between Claude being a helpful pair programmer and Claude being a fully automated part of your development workflow.

I discovered the power of these features while automating my code review process. Instead of manually asking Claude to review every pull request, I created a skill that runs automatically when I tag it, and a subagent that handles the detailed analysis. The time savings alone made it worth learning this stuff properly.

Skills: Your Reusable, Auto-Invoked Helpers

Think of a skill as a supercharged slash command with memory and auto-invocation. While slash commands require you to manually type /command, skills can trigger automatically based on context clues in your project.

What Skills Actually Are

A skill is essentially a lightweight automation with:

• Custom instructions that define what it does
• Optional scripts (SKILL.md with embedded code blocks) that execute specific tasks
• Auto-invocation logic that fires when certain conditions match
• Project isolation so skills know about your codebase structure

The key difference from a slash command: you don’t have to remember to invoke it. Set up a skill, and it starts working for you in the background.

Where Skills Live

Skills are stored in two places:

1. Personal skills: ~/.claude/skills/ — available across all your projects
2. Project skills: .claude/skills/ — specific to your current repo

I keep my generic helpers (like “check brand voice” or “format JSON”) in personal skills, and project-specific ones (like “validate our API schema”) in the project folder.

Building a Code Review Skill

Let me walk you through creating your first skill. I’ll use a code review skill as the example since it’s immediately useful.

Create a file at .claude/skills/code-reviewer/SKILL.md:

---
id: code-reviewer
name: Code Reviewer
description: Automatically reviews code files for style, performance, and best practices
triggers:
  - pattern: "review:"
    description: "Prefix comments or commit messages with 'review:' to trigger"
  - fileExtension: ".js"
    description: "Auto-runs on JavaScript files when explicitly requested"
---

# Code Review Skill

You are an expert code reviewer specializing in catching bugs, performance issues, and maintainability problems.

When reviewing code, focus on:
1. **Logic errors** that could cause bugs
2. **Performance bottlenecks** like inefficient loops or unnecessary re-renders
3. **Readability** — would another developer understand this in 6 months?
4. **Best practices** for the language/framework in question
5. **Security issues** like unvalidated input or hardcoded secrets

Format your response as:
- **Issues** (critical, numbered)
- **Suggestions** (nice-to-haves)
- **Praise** (what's working well)

Be concise. The developer will ask follow-ups if they want details.

That’s it. Once this skill exists, you can reference it like /review-code or tag files with “review:” in comments, and Claude will automatically apply this review framework.

Skills vs Slash Commands

The practical difference:

You’d use /help to ask a quick question. You’d use a skill to enforce code standards across every pull request.

Real Examples I Actually Use

1. Brand Voice Checker

I created a personal skill that ensures all my writing — docs, comments, error messages — matches my brand voice. It catches “please use X” instead of my natural “just use X” tone.

# Brand Voice Checker

Check all text for consistency with zenolab's voice:
- Direct and conversational (no corporate speak)
- Action-oriented (show, don't explain)
- Inclusive (avoid jargon, or explain it)
- Optimistic but realistic

Flag any text that feels corporate, passive, or gatekeeping.

2. Doc Generator

When I add a new public function, a skill automatically suggests documentation structure. Instead of remembering the exact format for function docs, Claude just… generates it.

3. Test Writer

Before running tests, a skill reviews my functions and suggests test cases I might have missed. It’s caught edge cases I would’ve overlooked.

Subagents: Your Specialized AI Team

Here’s where things get really powerful. A subagent is a specialized AI assistant with its own isolated context, custom system prompt, and knowledge of your project structure. Instead of one Claude helping with everything, you have a team: a code reviewer, a test engineer, a documentation specialist.

What Subagents Are

Subagents are full Claude instances that:

• Run in isolated contexts (no access to other subagents’ conversations)
• Have custom system prompts tailored to their role
• Can be delegated to automatically by the main agent
• Maintain their own memory and conversation history
• Report back to the main agent with findings

The magic is in the delegation. Your main agent doesn’t have to do everything—it can hand off specialized work to the right subagent.

Where Subagents Live

Subagents are stored in .claude/agents/:

.claude/agents/
├── code-reviewer.md
├── test-engineer.md
└── documentation-writer.md

Each file is a markdown document that defines the subagent’s role, instructions, and behavior.

Building a Code Reviewer Subagent

Create .claude/agents/code-reviewer.md:

---
id: code-reviewer
name: Code Reviewer
role: Senior code reviewer specializing in code quality
---

# Code Reviewer Subagent

You are a senior code reviewer with 10+ years of experience. Your job is to provide thorough, actionable code reviews.

## Your Process

1. **Read the code** completely before commenting
2. **Understand the context** — what problem does this solve?
3. **Identify patterns** — is this similar to code elsewhere in the codebase?
4. **Review systematically**:
   - Does it do what it's supposed to do?
   - Is it secure?
   - Is it performant?
   - Is it maintainable?
   - Does it follow our conventions?

## Output Format

Structure your review as:
1. **Summary** (one sentence on overall quality)
2. **Critical issues** (must fix before merge)
3. **Improvements** (should fix)
4. **Nice-to-haves** (consider for future)
5. **Approved** or **Request changes**

Be professional, specific, and kind. Criticize the code, not the person.

And create a test engineer subagent at .claude/agents/test-engineer.md:

---
id: test-engineer
name: Test Engineer
role: Specialized test strategy and implementation expert
---

# Test Engineer Subagent

You are a test engineer responsible for ensuring code is thoroughly tested and maintainable.

## Your Responsibility

When given code, you:
1. Analyze what could break
2. Identify edge cases
3. Suggest test cases in order of importance
4. Write sample test code for critical paths
5. Flag areas that are hard to test (potential design issues)

## Testing Philosophy

- **Unit tests** for business logic
- **Integration tests** for workflows
- **Edge cases** first (off-by-one, empty, null, max values)
- **Happy path** is assumed to work
- **Error scenarios** matter as much as success

Suggest the minimum viable test coverage that catches 90% of bugs.

How the Main Agent Delegates

This is where it gets elegant. Once subagents are defined, the main Claude Code instance can automatically delegate:

When I run `/review-code`, the main agent:
1. Passes the code to the code-reviewer subagent
2. Simultaneously asks the test-engineer to suggest test cases
3. Collects both reports
4. Synthesizes them into a single, comprehensive review

You don’t have to explicitly call the subagents every time. The main agent is smart enough to know when to delegate.

When to Use Subagents vs Skills

Use skills when you need:

• Simple, reusable instructions
• Auto-invocation without explicit delegation
• Lightweight automation
• Consistent formatting or checks

Use subagents when you need:

• Deep specialization (code review, testing, documentation)
• Complex, multi-step processes
• Isolation (the subagent shouldn’t see other conversations)
• Custom expertise and judgment

I use a skill for “enforce naming conventions” but a subagent for “comprehensive code review” because review requires nuanced judgment.

A Real Automated Code Review Pipeline

Here’s how I’ve set this up:

1. I push a PR and tag it with /review
2. The main agent receives the request
3. It automatically delegates to code-reviewer subagent (analyzes code quality)
4. It delegates to test-engineer subagent (suggests test gaps)
5. It uses the brand-voice skill to check docs and comments
6. All results are compiled into a single PR comment

The whole thing takes ~30 seconds and catches issues I’d miss in a manual review.

The Next Level

You now have the tools to automate huge swaths of your development workflow. But we’re not done yet. In Part 4, we’ll talk about the MCP Protocol — how to connect Claude Code to external tools and services, turning it into the central hub of your entire development environment.

For now, spend some time creating a skill and a subagent for your own workflow. Start simple. Once you see the time savings, you’ll understand why I’m this enthusiastic about it.