Week 11: Claude Code Power Features — Hooks, Subagents & MCP

1. Hooks

A hook is a shell command that runs automatically around a specific event — before or after a tool call, at session start, and similar points — configured in project settings rather than something you have to remember to ask for every time. Hooks run unconditionally per your configuration, which is exactly what makes them good for enforcing rules Claude might otherwise forget to apply consistently.

a hook that auto-formats after every file edit

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npx prettier --write ." }]
      }
    ]
  }
}

This runs the formatter after every file edit, automatically — no need to ask Claude to remember to format, and no risk of it skipping that step under time pressure the way a human (or an unhooked agent) might.

Hooks can also block, not just react

A PreToolUse hook can inspect a proposed command and refuse to let it run at all — a hard, code-level guardrail rather than relying on Claude's own judgment. This is Week 7's "your code decides whether the call is allowed" principle, now enforced at the tool-execution boundary itself.

2. Custom Slash Commands & Subagents

A slash command is a saved, reusable prompt — Week 5's template idea, built directly into the tool and invoked with /name instead of retyped from a notes file every time.

a custom command — .claude/commands/review.md

Review the changes in the current diff for:
1. Bugs or edge cases the tests don't cover
2. Anything that doesn't follow this project's CLAUDE.md conventions
3. Missing error handling

Report findings as a short list. Don't suggest style nitpicks.

A subagent goes further: a specialized sub-assistant with its own system prompt, its own restricted set of tools, and its own separate context, that the main session can delegate a task to. This keeps a large side-task — reviewing 20 files, say — from cluttering the main conversation's context window with detail the main session doesn't need to carry forward.

Ties directly back to Week 1's context window

Delegating a big exploratory sub-task to a subagent, which reports back a summary rather than every detail it read, is a concrete answer to the "context fills up" problem — the main session only carries the conclusion forward, not the full working-through.

3. MCP Servers

MCP (Model Context Protocol) is a standard way to connect Claude Code — and other Claude surfaces — to external tools and data sources: a database, a ticketing system, a browser, an internal API. Each MCP server exposes tools in exactly the same shape as Week 7's tool-use mechanics; MCP is really a standardized way to plug in more of them without writing custom integration code yourself.

connecting an MCP server, conceptually

{
  "mcpServers": {
    "project-tracker": {
      "command": "npx",
      "args": ["-y", "@some-vendor/project-tracker-mcp"]
    }
  }
}

# Once connected, Claude Code can call tools this server exposes —
# e.g. "look up ticket #482" — the same tool-use loop from Week 7,
# just with tools someone else built instead of ones you defined.

This is exactly why the trust question from Week 7 matters even more here: an MCP server you connect runs with your permissions and can act on your behalf, so vetting what a third-party server actually does — and only granting it the access it genuinely needs — is a real security decision, not a formality.

MCP is the ecosystem layer

You'll see MCP again in Week 13 as the common tool ecosystem across different agent frameworks — an agent built one place can use MCP servers built somewhere else entirely, the same way a website works in any browser regardless of who wrote the browser.

4. Putting It Together

These three features compose. A realistic workflow might combine all of them without any single piece being complicated on its own:

a workflow that uses all three

# 1. You run /review (a slash command) on a diff before opening a PR
# 2. Claude Code's PostToolUse hook auto-runs the linter after any fix
#    it makes based on that review, with no need to ask
# 3. Part of the review references "check if this matches the ticket" —
#    an MCP-connected ticketing tool fetches the actual ticket details
#    Claude needs to answer that
#
# None of these three pieces is complicated alone. Together, they turn
# a manual, multi-step routine into one command.

The right way to adopt these is incrementally: start with Claude Code's defaults, and add a hook, a command, or an MCP server only once you've hit a specific, real friction point it solves — not by front-loading configuration for workflows you don't have yet.

Next week is where this pays off

Week 12 applies everything from Weeks 10–11 to workflows that actually look like real engineering work — a TDD loop, a large refactor, a full PR cycle — rather than isolated feature demos.

5. Hands-on Exercise

Hands-on

Add one hook, one custom command, and evaluate one MCP server

Configure real project tooling, not a toy example.

Part 1 — A real hook:

Add a PostToolUse hook to a real project that runs your linter or formatter after edits.
Trigger a small edit through Claude Code and confirm the hook actually fires.

Part 2 — A reusable slash command:

Write a custom slash command for a task you do repeatedly (a review checklist, a commit-message format, a specific kind of code check).
Run it at least twice on different inputs to confirm it's genuinely reusable.

Hint

Good first slash commands mirror something you'd otherwise type out fully every single time — if you can't think of one, look back at Week 5's template exercise for a candidate.

Part 3 — Evaluate one MCP server:

Find one MCP server relevant to a tool you actually use (a project management tool, a database, a documentation source).
Before connecting it, write down: what tools does it expose, and what's the worst thing it could do with the access it's requesting? Only connect it if you're comfortable with the answer.

6. Knowledge Check

Four quick questions. Expand each to check your answer.

What makes a hook different from just asking Claude to remember to do something every time?

A hook runs unconditionally based on your configuration — it isn't dependent on Claude remembering or choosing to do it. This makes it reliable for enforcing rules (like always formatting after an edit) that shouldn't be left to chance.

When would you reach for a subagent instead of just asking the main session to do a big sub-task directly?

When the sub-task involves a lot of exploratory detail (reading many files, a large review) that would clutter the main conversation's context. A subagent handles that work in its own separate context and reports back a summary, keeping the main session's context clean.

How does an MCP server relate to the tool-use mechanics from Week 7?

MCP is a standardized way to expose tools in the same shape covered in Week 7 — it's not a fundamentally different mechanism, just a common protocol that lets you plug in tools someone else built (a database connector, a ticketing integration) instead of writing custom tool code yourself.

Why does connecting an MCP server deserve the same security scrutiny as any tool from Week 7?

An MCP server runs with your permissions and can act on your behalf using whatever access it's granted. A third-party server you haven't vetted could expose more capability than you intend — the same "treat tool access as a real trust decision" principle applies, not just to tools you write yourself.