Slurping the Claude Code Word Soup
Making sense of how Claude Code controls context length and uses progressive disclosure
It’s 2 AM in Madrid, and I’m staring at my screen, convinced that Anthropic’s documentation is confusing me. I cannot decide. Is it the same thing called differently or the hype of words. It is a salty word soup for me now.
Skills. Commands. Subagents. Plugins. MCP servers. CLAUDE.md. AGENTS.md.
“These are all just… prompts?” I mutter to myself, feeling that particular brand of frustration that comes from suspecting you’re missing something obvious while simultaneously wondering if the emperor has no clothes.
Markdown Mania
Here’s what broke my brain initially: Skills are markdown files. Commands are markdown files. Subagents are markdown files. Even CLAUDE.md is just… markdown.
Then I remembered about progressive disclosure from design school, and suddenly the whole architecture made sense.
See, Claude has a context window—a limit to how much it can hold in its working memory at once. The classic stateless nature of our dear LLMs. If you dump everything into CLAUDE.md (your project context, your coding standards, your deployment procedures, your debugging workflows, your API documentation), Claude’s brain gets cluttered. It’s like walking into a conversation where someone immediately tells you their entire life story. Overwhelming. Wasteful.
Anthrophic has a great blog on this here .
Progressive disclosure means Claude only loads what it needs, when it needs it.
CLAUDE.md stays lean—just the essentials about your project. The stuff that’s always relevant.
Skills wait quietly in the background. Each has a description. When you mention something that matches a skill’s description, Claude thinks “Oh, this is about API testing” and loads just that skill. Not all of them. Just the relevant one. Skill invocation still does not work as great as it should.
It’s like your brain. You don’t constantly think about how to ride a bicycle. But the moment you see a bike, that knowledge surfaces. Automatic. Efficient. Exactly when needed.
Progressive Disclosure handles the problem of context management and is the reason we have Skills, Claude.md, Commands, Subagents. They are all different invocation strategies to optimise Context Length. MCP (or Model Context Protocol) helps us get external information into the context which a LLM might not have.
Lets see an example from kitchen.
The Kitchen Epiphany
CLAUDE.md is your kitchen’s recipe book.
Always on the counter. Everyone reads it. Says things like “We only use organic ingredients” and “Oven preheats to 350°F.” Project essentials. Always loaded. Non-negotiable.
Skills are specialized knowledge cards.
Stack of cards nearby. Each says “How to make risotto” or “How to dice onions.” Claude scans the descriptions, picks relevant cards automatically. You don’t tell the chef which card, the chef sees you’re making risotto and grabs that card.
Commands are bookmarks in your recipe book.
Flip directly to the marked page when you want that specific recipe. Manual. Explicit. You choose exactly what you want, when you want it.
Subagents are calling in specialists.
Your regular chef (Sonnet) is great, but this needs a pastry expert (Opus). They work separately, in their own space, bring back results. Different skill level. Different conversation entirely.
Hooks are kitchen timers.
Go off automatically at specific moments. “Before serving, check temperature.” “After prep, clean station.” Event-driven. Nobody presses buttons. They just trigger.
MCP is the phone to your suppliers.
Need fresh tomatoes? Not a recipe, not instructions, an actual call that brings back real tomatoes. Real connections to real external systems.
Plugins are meal kit delivery like HelloFresh
Everything pre-packaged. Share with your team. One installation, everyone gets the same setup.
Three Distinctions That Actually Matter
After days of confusion, here’s what I figured out:
1. Words vs. Actions
Most things—Skills, Commands, Subagents, CLAUDE.md—are instructions. Text. Directions.
But MCP and Hooks? Actual programs that execute. Real database queries. Actual API calls. Running code.
If you’re thinking “I need to query my database” and you’re trying to do it with a Skill… you’re bringing instructions to a gunfight. You need MCP. You can tell Claude to use an MCP in the skill though.
2. One Conversation vs. Many
Skills, Commands, Hooks—all happen in YOUR chat with Claude. Same context. Same memory. One continuous dialogue.
Subagents spawn separate Claude instances. Different conversation. Different models (Sonnet vs Opus). Isolated context. Can work in parallel.
Like asking your friend a follow-up question versus calling a different friend who specializes in that topic.
3. Automatic vs. Manual
Skills auto-load when descriptions match. Claude decides.
Commands need you to type /command-name. You decide.
Both are text, but one is Claude reading your mind, the other is you giving specific orders.
Two Real Examples
Example 1: Company Documentation System
You’re building a system that references coding standards when reviewing pull requests.
Start with a Skill because coding standards are static. They don’t change daily. Put the standards in a skill description: “Use when reviewing code for style compliance.”
Add MCP only if standards live in a constantly-updating database. Most don’t need this.
Skip Subagents unless the review requires deep architectural analysis beyond pattern matching.
Structure:
.claude/skills/
├── python-style-guide/SKILL.md
├── api-conventions/SKILL.md
└── security-patterns/SKILL.md
Someone opens a PR → Relevant skills auto-load → Claude checks standards → Reports issues.
Example 2: Marketing Copy Reviewer
You need Claude to check marketing copy against brand voice guidelines.
Version 1 (Simple): Skill with brand voice patterns. “Use active voice. Keep sentences under 20 words. Always emphasize user benefits.” Works offline.
Version 2 (Smarter): Skill + MCP. Skill has patterns, MCP queries approved copy database: “This phrasing worked well in last campaign. Use similar structure.”
Version 3 (Interactive): Skill + MCP + Subagent. Subagent asks questions: “Who’s the target audience?” Then adapts recommendations using skill patterns and historical data.
Three versions. Three architectures. Each appropriate for its stage.
My Five-Question Framework
When building, I ask:
1. Is this static knowledge or dynamic data?
- Static (docs, patterns, rules) → Skill
- Dynamic (database, live API) → MCP
2. Do I want convenience or control?
- Convenience (let Claude decide) → Skill
- Control (I decide when) → Command
3. Does this need deep thinking?
- Standard → Sonnet in main conversation
- Deep analysis → Opus via Subagent
4. Should this happen automatically?
- Yes → Hook
- No → Skill or Command
5. Am I sharing this?
- Just me → Individual files
- Team → Bundle as Plugin
Five questions. Most confusion dissolved.
The Compressed Mental Model
After all this, here’s what stuck:
CLAUDE.md → “Here’s my project”
Skills → “Here’s what you might need”
Commands → “Here’s what I’ll ask for”
Subagents → “Here’s when to call experts”
MCP → “Here’s how to get real data”
Hooks → “Here’s what happens automatically”
Plugins → “Here’s everything, packaged”
Seven components. Seven jobs. That’s it.
Where This Leaves Us
It’s 4 AM now. The tea is cold now. But I’ve got Claude Code humming along, building things I couldn’t have built a year ago. It is a weird feeling. I am still understanding it
The word soup became a recipe. And now, when I look at that stack of markdown files, I don’t see confusion. I see an elegant system for managing complexity.
Where to get your skills from? Here are some places I peek :
If you are working on a big code base Every’s compound-engineering-plugin is gold. My only crib with it is that it eats away quite a lot of token to do simple stuff.
Also, if I am not clear about something is use Claude’s AskUserQuestion Tool so Claude and I are on the same page.
Also, you may ask, what is a tool now? Tool is anything that an agent runs say to get weather or external information. MCP is a tool, accessing an API is a tool call… A tool is a function Claude can call during a conversation. Built-in tools in Claude Code are : bash, view, create_file, web_search.
Hope this shines light as it did for me. It’s almost morning now.
Are you looking for a partner to experiment with new technologies or solve interesting problems in creative ways using design and technology? I run Studio-021 and we might be able to help you “Build that thing”.