Hey {{first_name | there}},

Last week I teased that centralizing your Claude extensions into a company-wide marketplace is "quietly killing your context window."

That was a shortcut. Let me give you the precise version — because the real answer is more useful and a little more interesting.

Let's get into it. 👇

In Part 1, I said centralizing everything into a company-wide marketplace is killing your context window. A few of you pushed back — and you were right to.

The full picture: only active extensions consume context. An extension sitting in your marketplace does nothing to your token count until it's loaded. So the problem was never centralization itself.

The problem is misplacement — putting something in the wrong context layer so it either never gets used, or gets used everywhere when it should only apply somewhere.

Most teams default to one of two failure modes:

They dump everything into CLAUDE.md — which loads every session whether it's relevant or not. Or they go the other way and build a sprawling internal marketplace where nothing is discoverable and junior engineers don't know what's safe to use.

The fix isn't less structure. It's a clearer hierarchy.

There's also one extension type that actually does bloat context regardless of how carefully you place it: custom MCPs. Because of how they register and expose tools, a poorly scoped custom MCP can consume significantly more context than a skill doing the same job. If your team is reaching for a custom MCP early, that's worth a second look.

Here's the placement hierarchy to work through before you build anything:

→ Start with CLAUDE.md
Dump it here first. Coding standards, architectural decisions, naming conventions, common gotchas. Anything that should shape every session in this project without needing to be triggered. This is where senior engineers encode how Claude should behave on your team — not what it can do, but how it works.

→ Move file-specific rules to .claude/rules/
If a rule only applies when Claude is touching a specific file type or directory, it doesn't belong in CLAUDE.md. Path-specific rules in .claude/rules/ only load when Claude works with matching files. Same always-on behavior, none of the noise.

→ Ask: memory or skill?
Once something has proven its value in CLAUDE.md, ask a simple question: should this be structured as a memory (persistent context Claude references) or a skill (a workflow someone can manually trigger)? Claude can help you make this call — describe what the instruction does and ask whether it's better left as a memory or distilled into a skill.

→ Keep project-specific skills in the project
If you build a skill that's tightly coupled to a repo — its conventions, its architecture, its specific failure modes — leave it in .claude/skills/ inside that project. It stays active in the right context and out of everyone else's way.

→ Promote to the marketplace when it earns it
You don't need to wait for a second engineer to ask for a skill before you promote it. If you know while building it that it's not repo-specific, move it to the internal marketplace immediately. Judgment call. Trust it.

→ When two teams solve the same problem differently
Don't auto-merge. Have a short conversation between the people who built both versions. This often surfaces a genuine difference in approach that warrants keeping both — and it's one of the best cross-team collaboration opportunities you'll find.

The goal isn't a smaller extension library. It's a library where everything is in the right place — active in the contexts where it matters, invisible everywhere else.

Use /context in Claude Code to see the token cost of what's currently loaded. It's the fastest way to spot what's taking up space it hasn't earned.

Remember when the news was about what happened, not how to feel about it? 1440's Daily Digest is bringing that back. Every morning, they sift through 100+ sources to deliver a concise, unbiased briefing — no pundits, no paywalls, no politics. Just the facts, all in five minutes. For free.

Read the newsletter trusted by 4.5 million fact-seekers.

What it does: Run /context inside any Claude Code session and you get a breakdown of exactly what's consuming your context window — every active extension, memory, and loaded file, with token counts.

Why I'm flagging it: Most engineers have no idea what's actually loaded. This command makes the invisible visible — and usually surfaces at least one thing that has no business being active in that session.

Worth 30 minutes of your time if: you've been feeling like Claude is slower or less focused than it used to be, or if your team has been adding extensions without a placement strategy.

→ No install needed. Just run it.

P.S. Hit reply with this: what's living in your CLAUDE.md right now that probably shouldn't be? I'm collecting examples for a future issue on encoding gotchas — the ones that save junior engineers from the mistakes seniors have already paid for.

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: Part 3 of 3 — How senior engineers choose the right extension for the right situation, and why encoding that judgment is the real unlock for AI reliability on teams.