Claude Skills: The 3-Level System That Turns Claude into a Domain Expert (Without Retraining)

Look, I’ve been using Claude Code daily for months. I know what it does well and what it doesn’t. And for a long time, every time I started a new session on a specific project, I’d spend the first ten minutes explaining context: the framework, team conventions, the stack, client constraints.

Tedious. Repetitive. Unnecessary.

Then I discovered Skills. And it changed how I think about Claude as a tool.

The Problem Skills Solves

Before getting into how they work, I need you to understand what Skills are NOT. The confusion between Skills, MCP, and Projects is real and worth clarifying:

• Projects = persistent context between sessions. Your history, your files, your memory.
• MCP = external connections. Databases, APIs, OS tools.
• Skills = procedural knowledge. How to do something, not where to store it or what to connect to.

It’s the difference between giving someone access to your CRM (MCP), reminding them who you are (Project), and teaching them exactly how your company handles contract renewals step by step (Skill).

Skills encapsulates the workflow, not the data or the connections.

The Progressive Disclosure Architecture: 3 Levels

Here’s what makes the Skills design interesting. It doesn’t load everything at once. It uses a 3-level system that keeps token costs low while enabling unlimited customization:

Level 1 — Metadata (~100 tokens)

The index. Describes what the Skill does, what it’s for, when to use it. Claude reads this to know if this Skill is relevant to the current task. Fast and cheap.

Level 2 — Instructions (<5,000 tokens)

The actual instruction manual. Steps, conventions, business rules, patterns Claude should follow. Only loaded when the Skill is relevant.

Level 3 — Resources (unlimited)

Scripts, templates, examples, extensive documentation. Loaded on-demand when context requires it. No size limit.

This design isn’t accidental. It’s efficient by architecture, not by chance.

The Anatomy of a SKILL.md

Every Skill lives in a SKILL.md file. The structure combines YAML frontmatter with markdown:

The frontmatter defines when it activates. The instructions define how to proceed. Resource references load additional material when needed.

Official Skills vs. Custom Skills

Anthropic shipped 4 official Skills: PowerPoint, Excel, Word, and PDF. They’re the obvious starting point if you work with office documents daily. You’ll find them at agentskills.io, which has become the open standard for the ecosystem.

But where Skills gets really interesting is with custom Skills, especially for teams.

Think about it: how much institutional knowledge lives only in people’s heads at your company? How to structure a budget for a new client, what code conventions the team follows, how to write a technical proposal, what checklist to run before deploying to production.

All that knowledge today gets transmitted through Slack, informal onboarding, or simply gets lost when someone leaves. A Skill encapsulates it, makes it reproducible, and makes it available to Claude in any session.

How Skills and MCP Work Together

This combination is where things get good. In 2026, most real workflows need both layers:

• MCP gives Claude access to your database, your GitHub repo, your ticketing system.
• Skill tells Claude exactly how to use that access following your team’s conventions.

Concrete example: an MCP connects Claude to your Supabase instance. The Skill explains that at your company migrations always include the rollback, that audit fields (created_at, updated_at, deleted_at) are mandatory in any new table, and that column names strictly follow snake_case.

The MCP is the plumbing. The Skill is your company’s plumber manual.

Where to Start: Your First Custom Skill

Don’t try to build the perfect Skill from day one. Here’s the process I’d suggest:

Step 1: Identify the repetitive task you explain to Claude most often. That’s your candidate.

Step 2: Create a basic SKILL.md with just the frontmatter and main steps. No resources yet.

Step 3: Test it in a real session. Does Claude follow the process you expected? Are there missing or poorly explained steps?

Step 4: Iterate. Only add resources when you notice Claude needs more context to complete a step.

The Skill documentation improves with use, just like any internal company process.

The Real Difference

When I started using Skills, the first thing I noticed wasn’t that Claude was smarter. It was that I had to think less about how to ask for things and could focus on what I wanted to achieve.

That difference sounds small. It isn’t.

A team that encapsulates their procedural knowledge in Skills has Claude working with team conventions by default, not by accident. And that, in a real project with multiple developers and months of history, makes an enormous difference.

Concrete action: Go to agentskills.io this week. Explore the official Skills to see the format in action. Then take the most repetitive workflow in your current project and write your first SKILL.md. It doesn’t have to be perfect — it just has to exist.