Claude Skills: Context is King

Because explaining your architecture conventions for the forty-seventh time this week gets old.

If you've spent any meaningful time with AI assistants, you've experienced the Groundhog Day problem. New session, fresh optimism, familiar explanation: "So, my diagrams use this colour scheme, and we prefer left-to-right flow, and databases are always cylinders..."

The AI nods along (metaphorically) and produces something useful. Then you close the session.

Next day, same dance. You're not collaborating. You're speed-dating the same colleague who keeps getting their memory wiped between rounds.

The MCP Problem (It's a Token Problem)

Model Context Protocol is genuinely powerful. It lets AI assistants interact with tools, read files, execute commands. Actually do things rather than just talk about doing things.

But here's the thing. MCP is expensive. Not in pounds and pence necessarily, but in context window real estate.

Jason Zhou demonstrated this nicely: a standard Chrome browser MCP tool consumes roughly 4,000 tokens just to be available. Not to do anything. Just to sit there, ready. Connect a Zapier MCP directly and you're loading definitions for thousands of tools into your context window, regardless of whether you need them.

Context windows are a public good. You're sharing that space with system prompts, conversation history, the actual user request, and whatever the model needs to reason through your problem. Burning 4,000 tokens on tool definitions you might not use is like paying rent on a spare office "just in case."

Translation: MCP without discipline is powerful but wasteful, leading to context rot.

Skills: Progressive Disclosure for the Win

Claude skills solve this with what Cole Medin calls "progressive disclosure." Instead of loading everything upfront, skills work in three levels:

The skill's description tells Claude when to use it. The full instructions only load if Claude decides the skill is relevant. Resources (scripts, templates, reference docs) load only when explicitly needed.

That Chrome browser capability? Jason reduced it from 4,000 tokens to 95. That's not a marginal improvement. That's the difference between "I can have three tools" and "I can have dozens."

You're not choosing between capabilities anymore. You're choosing which capabilities to describe. The actual implementation loads when needed.

My Draw.io Skill: Building Context Through Conversation

Anyways, enough theory. Back to the point.

I do a lot of architecture diagrams. AWS, Azure, the occasional multi-cloud monstrosity that makes sense on a whiteboard and nowhere else. And I got tired of Claude generating wildly inconsistent visuals every session. One day blue means compute, the next day blue means storage. The colour scheme shifted based on whatever the model felt like that particular inference, if it even produced a working drawio xml file in the first place.

So I built a draw.io skill. But I didn't start by writing instructions. I started by having conversations.

Building Context Before You Build Skills

This was the 'aha' moment for me. You don't just ask Claude for a diagram and hope for the best. You build context first.

Discuss what you have. Talk through your architecture. Explain the components, the relationships, the quirks. "We've got a VPC with public and private subnets. Lambda in private, ALB in public. RDS in its own subnet group. The usual."

Provide examples. Got a diagram you like? Share it. Got code snippets showing the infrastructure? Even better. Reference architectures from AWS docs? Chuck them in. Claude learns from what you show it, not just what you tell it.

Have the conversation. This is where it clicks. Claude will ask follow-up questions: "What about connections between components? Solid or dashed? Arrow styles? Font sizes?" Every "oh, and also..." becomes explicit knowledge that would otherwise live only in your head.

Then request the output. Once Claude understands what you're building and how you want it visualised, then ask for the diagram. The context is already there. The output will be better.

Is this more effort than just typing "draw me an AWS architecture"? Yes. Does it produce vastly better results? Also yes.

Here's a snippet from my skill's output conventions:

<!-- AWS Lambda icon with standard styling -->
<mxCell id="lambda-1" value="Lambda" 
  style="sketch=0;outlineConnect=0;fontColor=#232F3E;fillColor=#ED7100;
  strokeColor=#ffffff;shape=mxgraph.aws4.resourceIcon;
  resIcon=mxgraph.aws4.lambda;" 
  vertex="1" parent="1">
  <mxGeometry x="100" y="100" width="78" height="78" as="geometry" />
</mxCell>

Every time Claude generates a diagram now, Lambda functions are orange (#ED7100), positioned consistently, labelled the same way. Not because I remembered to tell it. Because the skill remembered for me.

From Good Output to Reusable Skill

Here's the other workflow that works brilliantly. Sometimes you don't start with a skill in mind. You're just iterating on a task, going back and forth until Claude produces something genuinely good.

When that happens, don't just save the output. Ask Claude to distil the conversation into a skill.

Be specific: "Take what we just built and turn it into a reusable skill. Make it generic so it works for other diagrams, not just this one."

Claude's seen the conversation. It knows what worked. It can extract the patterns, the conventions, the decisions you made along the way. You get a skill that captures the process, not just the result.

This is the feedback loop: conversation → good output → distilled skill → better starting point next time.

Why Opus 4.5 Matters Here

Opus 4.5 is the first model I've been able to get complex draw.io XML out of consistently. The XML format is fiddly. Unique IDs for every element, parent-child relationships, precise geometry coordinates, style strings that look like someone sneezed on a CSS file.

Smaller models struggle. Sonnet 4.5 works with some back-and-forth. Haiku needed multiple iterations to fix XML syntax issues before producing anything usable, even with the skill. Not a criticism; it's the right model for simpler tasks. But for complex structured output, Opus earns its inference cost.

The skill lets me distil what Opus produces. I iterate with the heavyweight model until the output is right, then capture those patterns in the skill. Future requests (even with cheaper models) can follow the established conventions.

Building Your Own: The Skill Creator Approach

Claude has a built-in skill creator skill. Here's one I made earlier.

The process follows a sensible pattern:

1. Understand the skill with concrete examples - What will you actually use this for? What triggers it?
2. Plan the reusable contents - Scripts, references, assets. What would help if you had to do this repeatedly?
3. Initialise the skill - Create the directory structure
4. Edit the SKILL.md - Write instructions for another Claude instance
5. Package and iterate - Test it, refine it, repeat

The skill creator includes an initialisation script:

scripts/init_skill.py <skill-name> --path <output-directory>

This generates the structure:

skill-name/
├── SKILL.md          # Required: frontmatter + instructions
├── scripts/          # Optional: executable code
├── references/       # Optional: docs loaded as needed
└── assets/           # Optional: templates, icons, fonts

The key insight from the skill creator documentation: "Challenge each piece of information: Does Claude really need this explanation? Does this paragraph justify its token cost?"

Context is finite. Be ruthless.

Context is King - Treat It That Way

Here's the pattern that's worked for me:

1. Discuss what you're building - Talk through the architecture, the problem, the constraints. Don't assume Claude knows.
2. Provide examples - Code snippets, reference architectures, existing diagrams. Show, don't just tell.
3. Have the conversation - Let Claude ask questions. Answer them. The back-and-forth surfaces assumptions you didn't know you had.
4. Build the context, then request - Once Claude understands, ask for the output. The quality difference is night and day.
5. Distil good outputs into skills - When something works, capture it. Ask Claude to make it generic and reusable.
6. Iterate with real tasks - Use the skill. Notice where it struggles. Update.

The skill is a tool to augment your workflow, not replace your thinking. You still need to know what good looks like. The skill just helps Claude get there faster.

My draw.io skill doesn't make me an architect. It makes my architecture diagrams consistent. Which frees me to think about the actual architecture rather than remembering which shade of purple means "security."

Migration Options for Other Models

Not every model supports skills natively. Yet. Anthropic have made this an open standard, so hopefully that changes.

In the meantime, Projects potentially offer a workaround. You can feed skill content into a project's context, giving the model persistent access to your conventions and preferences. The downside: you're back to loading everything upfront rather than progressively. It works, but you lose the token efficiency that makes skills practical at scale.

More testing needed here. The dream is seamless skill portability across models. The reality is currently more nuanced.

It depends. Those who know me will understand.

Resources and Credit Where It's Due

I've put my skills up on GitHub if you want to see how they're structured or use them as a starting point:

github.com/scarr05/claude-skills-pub - Draw.io skill, blog writer skill, and the voice profiles I use to keep outputs consistent.

The ideas in this post were heavily influenced by two creators doing excellent work on AI agent workflows:

• Cole Medin - 1 His "Second Brain" concept for using Claude Code with Obsidian crystallised how I think about skills as a memory layer. The progressive disclosure framing is his, and it's the right mental model.
• Jason Zhou - 2 3 His MCPorter work and the 4,000 → 95 token demonstration made the efficiency argument concrete. Sometimes you need to see the numbers to believe them.

Both are worth following if you're building workflows around AI agents. The signal-to-noise ratio is unusually good.

What's Coming

This is the first post in a series. I'm building toward something more ambitious:

• Part 2: The Draw.io Skill in Detail - Maintaining visual consistency across architecture diagrams
• Part 3: IaC Visualisation - Feed in Terraform, CloudFormation, or Bicep, see what you're about to deploy before hitting apply
• Part 4: Live Inventory to Architecture - Pull from an AWS account (even clickops deployments), generate inventory reports, Well-Architected reviews, and diagrams with validated visual elements

The goal is a workflow where architecture documentation stays current because generating it is cheaper than maintaining it manually. Diagrams that match reality because they're derived from reality.

Ambitious? Probably. But I've proven stupider ideas could work before.

Claude helped turn my rambling notes into something that doesn't read like a toddler writing on the wall with ketchup. The ideas are mine. The coherent sentence structure is a team effort.

If you're already using Claude skills, I'd genuinely like to hear what you've built. The best ideas usually come from seeing how other people work.