How Claude Skills Work: What They Are, When You Actually Need Them

Claude Skills launched in October 2025 and the docs make them sound complicated. They are not. A Skill is a folder of instructions that Claude reads on demand to do a specific thing well. That is the whole idea.

But the docs do not tell you when you should bother building one. Or when a good prompt is enough. Or when you need something more powerful like a full MCP server. This post is that missing piece.

I have built seven production Skills for client work over the last six months. Some save hours a week. Some are overkill for what they do. Here is what I learned.

What a Skill actually is

A Skill is a folder with three things:

1. A SKILL.md file describing what it does and when Claude should use it
2. Optional reference files Claude reads when the Skill is active
3. Optional scripts Claude can run

When you start a Claude conversation, Claude scans your loaded Skills and sees the metadata at the top of each SKILL.md (name + description). It does not load the full content yet. When your prompt matches a Skill, Claude opens that Skill's SKILL.md and uses the instructions inside. If the SKILL.md points to reference files or scripts, Claude reads or runs them.

Think of it as progressive disclosure. Claude has thousands of potential skills available. It only loads the one relevant to what you are doing right now. Context window stays clean. Instructions stay specific.

The concrete example

I have a Skill called invoice-extractor. When I drop an invoice PDF into Claude, it recognizes the task, pulls up the Skill, and runs a Python script that extracts vendor, line items, tax, and total into a structured JSON. Then it formats a clean markdown summary.

Without the Skill: I type a 300-word prompt every time explaining how to extract invoices, what fields to look for, how to format output, and how to handle weird edge cases.

With the Skill: I drop the PDF, Claude finds the Skill, the Skill loads, the work happens. 30 seconds of user effort, not 5.

That is the whole promise. Consistency and reuse, without stuffing the context window.

When you should build a Skill

Three signals that a task deserves a Skill.

1. You do the same task more than 10 times a month. Anything rarer and the setup cost of the Skill is not worth it. Just paste a prompt.

2. The task has specific rules you keep forgetting to include. If you keep going back and fixing Claude's output because it missed a constraint, that constraint belongs in a Skill. It becomes enforced, not hoped for.

3. The task involves files or tools. Skills shine when they invoke scripts or reference structured data. A Skill that extracts PDFs, runs a SQL query, or formats output using a Python parser is the sweet spot.

When a prompt is enough

Plenty of cases where a Skill is overkill.

• One-off tasks. You will never repeat this exact thing. Paste a good prompt, move on.
• Simple formatting. "Write this in bullet points" does not need a Skill.
• Tasks where the rules change every time. Skills are for consistency. If every instance is different, prompts win.
• When the variation in inputs means the instructions would need to be 3 pages long to cover all cases. At that point, you need an MCP server or a full agent, not a Skill.

The rough rule: if your prompt is under 100 words and works 80% of the time, stay with the prompt. If your prompt has grown past 300 words and you are still getting edge-case failures, the task has outgrown prompts. Build a Skill.

When you need MCP instead

Skills are great for instructing Claude. They are not good for connecting Claude to live systems.

If the task needs to:

• Query a production database with fresh data
• Call authenticated APIs (Salesforce, Stripe, your own backend)
• Stream from a tool that updates constantly

You want an MCP server, not a Skill. MCP is the protocol for Claude to talk to live external systems. Skills are for structured instructions and static reference files that ship with the Skill itself.

A useful way to think about it:

• Prompt = telling Claude what to do right now
• Skill = giving Claude a reusable playbook with optional scripts
• MCP = connecting Claude to live external systems

The Skills I have built

Rough taxonomy of what I have built for clients and myself, and the lessons from each.

Client project management. A Skill that reads the client's Notion database schema and drafts status updates in their voice. Saves 45 minutes a week on admin. Paid for itself in a day.

Invoice extraction. The one I described earlier. Ingests random PDF invoice formats, extracts clean JSON. Was a 5-hour build. Has paid back in saved manual data entry maybe 50 times.

Blog post drafting. A Skill loaded with my writing voice (the one you are reading right now, more or less). Drafts new posts with my tone baked in. This post was drafted by Claude using this Skill. Then I rewrote about 30%. The first draft was 70% of the way there.

SEO audit. Checks a page against a checklist I designed (meta, schema, internal links, keyword density). Outputs a table of issues. Same principle as the best AI tools I actually use every day, just codified into a Skill so Claude runs it consistently.

Brand guidelines enforcer. For one client with strict voice rules, a Skill that checks any outgoing copy against their 20-page guidelines doc and flags violations.

Support ticket triage. A Skill that classifies incoming tickets (severity, category, which team). Replaces a 15-line prompt I was reusing.

Meeting notes cleanup. Takes raw Fathom/Otter transcripts and produces structured action items per attendee.

The ones I killed:

• A Skill for "writing LinkedIn posts in my voice" because the outputs were stale and sounded like AI. Good prompts with examples work better for creative writing than Skills in my experience.
• A "code review" Skill that was trying to do too much. Split it into three smaller Skills (security check, style check, performance check) and they all work better.

The limits of Skills in 2026

Claude Skills are still new and there are real limits.

They do not share state. Each Skill invocation starts fresh. If you want Claude to remember what happened in the last run, you need to persist that yourself.

They do not orchestrate. You cannot have a Skill call another Skill automatically. Everything is triggered by the user prompt matching a Skill's description.

They are tied to Claude Code and Claude.ai. Using them in your own app requires the Agent SDK, which works but adds complexity.

Discovery can fail. Sometimes Claude does not pick up a Skill you expected it to. Usually because the description in the SKILL.md was too vague. Writing good metadata matters more than people realize.

Should you build one

Ask yourself: what is the task I do every week that I keep half-assing because I do not want to write the full prompt again?

If you have an answer, you have a Skill candidate.

Time to build your first Skill: 2 to 4 hours for something simple. A day for something with scripts. Longer if you want to integrate external data, at which point you should probably be looking at MCP instead.

If you are a founder wondering whether Skills are the right architecture for what you are building, or whether MCP, a custom agent, or just a prompt library is a better fit, book a call. I will look at the actual task and tell you which tool fits. Most people are overbuilding. A few people are underbuilding. Both waste money.

Related: I have written what vibe coding actually means and covered MCP servers next. Together these three are the Anthropic stack most developers will end up using this year.