Hey {{first_name | there}},

We've spent two weeks building the foundation: what extensions are, why placement matters more than quantity, and how to stop your CLAUDE.md from doing jobs it was never meant to do.

Today we close the loop.

The question I hear most from senior engineers is: "When something could be a Skill, an MCP, or a Hook — how do I actually decide?"

That judgment call is the whole game. Let's make it explicit. 👇

Before I give you the framework, one thing changed this week that makes Part 3 more relevant than I expected.

Anthropic shipped MCP Tool Search — a lazy loading mechanism for MCP servers. Instead of registering every tool at session start, Claude now discovers and loads tools on demand. In testing, this reduces context overhead by up to 95% on large MCP setups. A five-server configuration that previously consumed ~55,000 tokens before your first message now lands at a fraction of that.

This matters for the decision framework below, because one of the classic arguments against MCP — it bloats your context — just got a lot weaker.

Here's the three-question framework I use:

→ Question 1: Is this a behavior or a connection?

Skills are for procedural knowledge — things you want Claude to know how to do. MCPs are for external connectivity — things you want Claude to reach out and touch. A skill that tells Claude "always write tests before implementation" is guidance. An MCP that connects to your GitHub repo is infrastructure. If you're reaching for an MCP to encode behavior rather than to connect a tool, stop and ask if a skill would do the job cheaper.

→ Question 2: Must it happen, or should it happen?

Hooks are for hard requirements — things that cannot be skipped, cannot be argued with, cannot be undone. If a junior engineer forgets to run your formatter, a hook catches it. If a file gets committed with a secret in it, a hook blocks it. Skills are for best practices — things you want Claude to follow but that leave room for context and judgment. If the answer is "this absolutely cannot be skipped," write a hook. If the answer is "this is the right approach in most cases," write a skill.

→ Question 3: Is this mine, ours, or everyone's?

This is the placement question from Part 2, but with a decision attached. If it only makes sense in one repo, keep it local. If it's emerged from two or more teams solving the same problem the same way, promote it to the marketplace. If it touches every engineer regardless of project — coding standards, security patterns, company-wide naming conventions — it belongs in CLAUDE.md or a shared root-level skill. The difference is who suffers when it's absent.The full decision hierarchy at a glance:

Where teams go wrong: They conflate the first three. MCPs get used to encode behavior. Hooks get written for things that are actually preferences, not requirements. Skills get made for things that should be hooks. The framework is only useful if you're honest about which category you're actually in.

One more unlock: Senior engineers use Claude to help make these calls. Not just to build the extension — to decide what kind of extension it should be. Describe the problem and ask: "Should this be a skill, a hook, or an MCP?" is a legitimate question with a real answer, and Claude's response will usually surface a tradeoff you hadn't considered.

Use /context after loading a fresh MCP to see how much context it actually costs now with Tool Search active. The number is probably lower than you think.

What it does: Run /powerup inside any Claude Code session to get animated, interactive lessons on Claude Code features — walkthroughs of context management, extension placement, hook syntax, and more, built directly into the CLI.

Why I'm flagging it: This shipped on April 1st and I almost missed it. It's not just a docs summary — it's an interactive training layer built into the tool itself. If you have a new engineer ramping up on Claude Code, this is the fastest onramp you have available. More importantly, it's how you'll find features you didn't know existed.

Worth 30 minutes of your time if: you've been meaning to get your team up to speed on Claude Code best practices without writing a 10-page internal wiki. Let /powerup do the first pass.

→ No install needed. Just open a Claude Code session and run it.

P.S. That's a wrap on the Extensions series — but the questions it raised are ones I'll keep circling back to. Hit reply with this: what's the most expensive mistake you've made with extensions so far — placement, type, or scope? I'm collecting field reports for a future issue on the failure modes teams actually hit in production.

The Context Loop publishes every Thursday for engineers and AI leads building with Claude. Forward this to one person on your team who's been solving the same problem twice.

Next issue: The context window just got bigger — 300k output tokens on the Batches API is live. What that actually unlocks for long-running Claude tasks, and how to architect around it.