# What skills are and why they matter
Type "build me a budget model" into a stock chatbot and you get a wall of text describing what a budget should contain. Type it into Claude with the right Skill loaded and you get back an actual budget_model.xlsx file, formulas wired up, summary tab included, ready to open in Excel. That difference is what this lesson is about.
A Skill is a packaged folder of instructions and supporting files that Claude loads only when a task calls for it. It is the mechanism that turns a general-purpose assistant into a domain specialist on demand, without you re-explaining the domain every single time.
You already know the context windowcontext windowThe context window is the maximum amount of text (measured in tokens) a language model can process at once, including both the input prompt and the generated output.View full definition → is finite and that stuffing it with instructions is wasteful. Skills solve this with progressive disclosure: Claude reads only a short description of each available Skill up front, then loads the full instructions and files *only when* a task matches.
Think of it in three layers:
1. Metadata (always visible): a name and a one-line description, e.g. "Creates and edits Excel spreadsheets with formulas and charts." This is tiny and costs almost nothing in context.
2. Instructions (loaded on match): a SKILL.md file with the detailed how-to. Claude pulls this in once it decides the Skill is relevant.
3. Bundled resources (loaded as needed): scripts, templates, reference docs, schemas. Claude reaches for these only when the specific step requires them.
So a workspace can have twenty Skills installed and pay almost no context tax until one is actually triggered. That is the whole trick, and it is why Skills scale where a giant master prompt does not.
The official reference lives at docs.claude.com, and Anthropic publishes example Skills openly at github.com/anthropics/skills.
A Skill is just a folder. At minimum it contains a SKILL.md file with a YAML frontmatter block at the top and instructions below it.
Here is what the frontmatter for a spreadsheet Skill looks like:
name: xlsx-builder
description: >
Build and edit real .xlsx files from structured requests like budgets,
forecasts, and trackers. Use when the user wants a downloadable spreadsheet
with working formulas, not a description of one.The description is the most important line you will write. It is the metadata Claude reads at all times, and it is how Claude decides whether to load the Skill. Vague descriptions get ignored; precise, trigger-word-rich descriptions get picked up at the right moment.
Below the frontmatter, the SKILL.md body holds the actual playbook in plain Markdown. For our spreadsheet Skill it might say:
openpyxl library to write files.Summary tab plus one tab per data category.A Skill can also bundle a real script so Claude does not reinvent it each time:
# scripts/build_budget.py
from openpyxl import Workbook
def build_budget(categories: dict[str, float], path: str) -> str:
wb = Workbook()
ws = wb.active
ws.title = "Budget"
ws.append(["Category", "Monthly", "Annual"])
for row, (name, monthly) in enumerate(categories.items(), start=2):
ws.cell(row=row, column=1, value=name)
ws.cell(row=row, column=2, value=monthly)
ws.cell(row=row, column=3, value=f"=B{row}*12")
last = len(categories) + 1
ws.append(["Total", f"=SUM(B2:B{last})", f"=SUM(C2:C{last})"])
wb.save(path)
return pathNotice the formulas (=B2*12, =SUM(...)) are written *into* the file. The user gets a live model they can edit, not a static snapshot. That is the leap from "describe a budget" to "deliver a budget."
This is the distinction that matters most, so let's make it concrete.
A one-off prompt is a message you type once. Even a brilliant one is gone the moment the conversation moves on. To repeat the result, you copy-paste it, tweak it, and hope you remembered every nuance. It does not version, it does not carry files, and your teammates cannot reuse it without you sharing the raw text.
A Skill is a reusable asset:
A prompt tells Claude what to do *this once*. A Skill teaches Claude how to be good at a *category* of task, every time, with the tooling attached.
Skills are not tied to one surface. The same packaged capability shows up across the Anthropic ecosystem:
One folder, many runtimes. You author the capability once and it travels.
You have met several Claude features by now, and it is easy to blur them. Here is the clean mental model:
The useful pairing: a Connector lets Claude pull last quarter's actuals from your finance system, and a Skill knows how to turn those numbers into a properly structured .xlsx model. ReachReachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → and know-how are different problems, and Skills own the know-how half.
Knowledge check
1. What best defines a Skill in the context of Claude?
2. In the three-layer progressive disclosure model, what does Claude always have visible up front for each installed Skill?
3. Why do Skills scale better than a single giant master prompt containing all domain instructions?
4. Select ALL correct answers about the layers of progressive disclosure in Skills.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about the practical behavior and structure of Skills.
Sélectionnez toutes les réponses correctes.
Not every task deserves a Skill. The test is repetition plus specificity.
Build a Skill when:
Skip it when:
A quick gut check: if you find yourself pasting the same long instruction block for the third time, that block wants to be a Skill.
Claude does not run every Skill on every message. It reads the available descriptions, compares them to your request, and loads the best match. This is why the description field is doing real engineering work.
Compare:
description: helps with spreadsheetsdescription: Build downloadable .xlsx files with working formulas and multiple tabs for budgets, forecasts, and trackers. Use when the user asks to "build," "model," or "export" numeric data.The strong version names the file type, the triggers, and the boundary. When you write a Skill, spend real effort here. It is the difference between a Skill that fires reliably and one that sits unused.
If two Skills could plausibly match, keep their descriptions distinct so Claude is not guessing. Overlapping descriptions are the most common reason a Skill does not trigger when you expect it to.
Put it together with the budget example:
1. You ask: "Build me a 2026 budget model with rent, payroll, software, and marketing."
2. Claude scans Skill metadata, matches xlsx-builder on the words "build" and "budget model."
3. It loads SKILL.md, sees the rule about a Summary tab and formula-based totals, and pulls in scripts/build_budget.py.
4. It runs the script with your categories, generating real cells and =SUM formulas.
5. You get a downloadable budget_2026.xlsx you can open and edit immediately.
No re-explaining the tab structure. No copy-pasted boilerplate. Next month you say "same model, new numbers" and it just works, because the procedure lives in the Skill, not in your memory.
=SUM formulas delivers an editable model, not a description of one.