- In short
- A Claude Code skill is a folder under .claude/skills/ containing a SKILL.md file. The file has YAML frontmatter that tells Claude when and how to run the skill, followed by markdown instructions that load only when the skill is invoked. Frontmatter fields such as description, allowed-tools, argument-hint, and context turn a plain prompt into a configurable, on-demand capability.
What Claude Code skills are
Claude code skills extend what the assistant can do by packaging a procedure as a small folder you commit alongside your code. Each skill is a directory under .claude/skills/, and the one required file inside it is SKILL.md. That file has two parts: a block of YAML frontmatter between --- markers, and the markdown instructions beneath it. The frontmatter is the control panel; the markdown is the work. Together they turn a prompt you used to paste by hand into a named capability that either you or Claude can trigger.
- SKILL.md
- The required entry-point file of a skill. Its YAML frontmatter declares metadata and behaviour (description, allowed-tools, argument-hint, context, and more), and the markdown body holds the instructions Claude follows when the skill runs. The skill folder name becomes the slash command.
The reason skills exist as their own concept, rather than living inside a giant always-on instruction file, is cost. A skill body loads only when the skill is actually used, so a long reference procedure sits idle and free until the moment you need it. That single property, on-demand loading driven by a short description, is what separates skills from the always-loaded CLAUDE.md model, and it is why this knowledge point sits at the centre of TS 3.2.
The two parts of a SKILL.md
A minimal SKILL.md needs only a description; everything else is optional. But understanding the body and the frontmatter as distinct layers is what the exam rewards.
- The markdown body is the instruction set: the checklist, the steps, the conventions Claude should follow. Keep it concise, because once a skill loads, its content stays in the conversation for the rest of the session and every line is a recurring token cost.
- The YAML frontmatter decides when the body runs, who can trigger it, which tools run without prompting, and where the work happens. This is where an architect spends their attention.
The folder name, not a frontmatter field, determines what you type. A directory .claude/skills/release-notes/ is invoked as /release-notes. The optional name field only sets the display label in listings.
The frontmatter fields that matter for the exam
Four fields recur across TS 3.2 questions, and you should be able to state what each one does.
description(recommended): a sentence describing what the skill does and when to use it. Claude reads this to decide whether to load the skill automatically, so a vague description means the skill never triggers when you expect it to.allowed-tools: pre-approves the listed tools so Claude uses them without asking for permission while the skill is active. It is a convenience-and-trust control, not a restriction, every other tool is still reachable, just subject to your normal permission prompts.argument-hint: the placeholder shown during autocomplete, such as[issue-number], so a developer who invokes the skill without arguments is reminded what it expects.context: fork: runs the skill in an isolated subagent context so its verbose output never pollutes the main conversation.
Supporting fields round out the picture: disable-model-invocation: true makes a skill manual-only (good for side-effecting actions like deploy), user-invocable: false hides a background-knowledge skill from the slash menu while still letting Claude use it, model overrides the model for the skill, and paths restricts automatic activation to files matching a glob.
How a skill gets invoked
Two paths lead into a skill, and both are available by default. You can invoke it directly by typing /skill-name, exactly like a slash command. Or Claude can invoke it autonomously: because the description is always visible, the model recognises when your request matches and loads the skill on its own. The frontmatter is how you tune that behaviour, disable-model-invocation removes the automatic path and leaves only manual triggering, which is the responsible default for anything with side effects.
Worked example
You keep running the same test-coverage audit by hand and want to standardise it for your team as a skill called /coverage-audit.
You create the folder .claude/skills/coverage-audit/ and add a SKILL.md. In the frontmatter you write a precise description, "Audit test coverage for a module and list untested branches; use when the user asks about coverage gaps", so Claude can both surface it when you type /coverage-audit and reach for it on its own when you ask "what is not tested here?". You add argument-hint: [module-path] so anyone invoking it sees that it expects a path. Because the audit only needs to read and search, you set allowed-tools: Read Grep Glob, which lets those run without permission prompts while leaving destructive tools subject to your normal approvals.
The body is a tight checklist: locate the module test file, enumerate the public functions, compare against the assertions, and report uncovered branches. You commit the folder to .claude/skills/ so the whole team inherits it. The payoff is twofold. First, the procedure is consistent for everyone instead of living in one engineer head. Second, the long checklist costs nothing until someone actually runs it, because the body loads on demand. Had you instead pasted the same checklist into CLAUDE.md, it would load on every single session whether or not anyone audited coverage that day, the exact inefficiency skills exist to remove.
The three levels of skill loading
Anthropic Agent Skills documentation frames a skill as three layers of content that load progressively, and naming them explicitly is the cleanest way to remember why Claude code skills stay cheap. Level 1 is metadata, the skill name and description, and it is always loaded so Claude knows the skill exists and can judge when it is relevant. This standing cost is tiny, a sentence or two, and it is the only part of a skill that occupies context before the skill ever runs. Level 2 is the instructions, the markdown body of SKILL.md, and it loads only when the skill is triggered, whether you type the slash command or Claude matches the description. Level 3 is resources and code, the templates, reference documents, and scripts bundled in the skill folder, and these load as needed, only when the instructions point Claude at a particular file.
This progressive disclosure is the architecture behind every efficiency claim on this page. A skill can package a sprawling style guide and a handful of helper scripts, yet cost almost nothing until the moment its description matches your request, and even then it pulls in only the resources the task actually reaches for. For the exam, hold the three levels as a ladder: metadata is permanent and small, instructions arrive on invocation, and resources arrive only when referenced. A question that asks why a large, resource-heavy skill does not bloat the context window is really asking you to recite this loading model.
Common misreadings to avoid
Misconception
A skill is loaded into context all the time, just like the instructions in CLAUDE.md.
What's actually true
Misconception
Setting allowed-tools on a skill restricts it to only those tools, so it can never touch anything else.
What's actually true
The supporting fields you should recognise
Beyond the four headline fields, the frontmatter offers a handful of refinements that turn up in more advanced scenarios, and recognising them keeps you from misreading a question.
disallowed-toolsremoves tools from the pool while the skill is active, the genuine restriction control that pairs with the pre-approvingallowed-tools. Use it for an autonomous skill that should never call a particular tool.modelandeffortlet a skill run on a different model or reasoning level for the duration of its turn, then hand control back to the session defaults.pathsrestricts automatic activation to files matching a glob, so a skill loads on its own only when you are working in the part of the codebase it concerns.when_to_useadds trigger phrases that sharpen auto-invocation, andhooksscopes lifecycle hooks to the skill.
You do not need to memorise every field, but you should be able to tell a pre-approval (allowed-tools) from a restriction (disallowed-tools), and an invocation control (disable-model-invocation, user-invocable) from an execution control (context, agent, model). Questions often hinge on choosing the field whose job actually matches the requirement.
The skill directory and supporting files
A skill is a directory, not just a file, and that distinction unlocks one of its biggest advantages over a plain command. Alongside SKILL.md you can place templates, example outputs, reference documents, and executable scripts. The key behaviour is that these supporting files do not load into context automatically; you reference them from SKILL.md so Claude knows what each one contains and reads it only when the task calls for it. A large API specification or a long style guide can therefore live next to the skill and cost nothing until the moment it is genuinely needed.
That layout keeps SKILL.md itself short, which matters because of the lifecycle of skill content. When a skill is invoked, its rendered body enters the conversation as a message and stays there for the rest of the session; Claude Code does not re-read the file on later turns. Because every line is a recurring cost once loaded, the documentation advises keeping the body concise and stating what to do rather than narrating why. Moving detailed reference material into separate supporting files is the idiomatic way to honour that advice while still making the depth available on demand.
Dynamic context injection
One more capability separates skills from static prompts: a skill can pull live data into itself before Claude ever reads it. A line written as !`git diff HEAD` runs that command first and replaces the placeholder with its output, so the skill arrives with the real diff already inlined. This preprocessing happens once, before the model sees anything, and is not something Claude chooses to do. It is baked into how the skill renders. The practical effect is that a summarise-changes skill can be grounded in your actual working tree rather than relying on what Claude can infer from open files. For the exam, the detail to carry is conceptual: skills are not just saved prompts, they are templates that can be filled with current state at invocation time, which is part of why they are the recommended successor to plain command files.
Why skills are the recommended successor to commands
It is worth understanding why the documentation now points people toward skills even though plain command files still work. A command is a single markdown file: a saved prompt and nothing more. A skill is a directory with frontmatter, so it gains four capabilities a bare command cannot offer. It can bundle supporting files that load only when referenced. It can be invoked automatically by Claude through its description, instead of waiting for you to remember to type the slash. It can run in an isolated context with context: fork to keep verbose work out of your main thread. And it can carry richer frontmatter to control tools, invocation, model, and activation paths. None of this deprecates your existing .claude/commands/ files, which keep working unchanged, but it explains the direction of travel: when you reach for a new reusable workflow, a skill gives you room to grow that a command does not. For the exam, the practical takeaway is that "command" and "skill" are close cousins where the slash invocation is concerned, and the skill is the richer of the two when a scenario asks for anything beyond a fixed prompt.
How this shows up on the exam
TS 3.2 sits inside Domain 3 (20% of the exam) and surfaces mostly through Scenario 2 and Scenario 4. Expect questions that describe a verbose, repeated workflow and ask where it belongs and how to configure it. The strongest answers name the right file (SKILL.md), the right folder (.claude/skills/), and the right frontmatter field for the requirement, description for auto-invocation, allowed-tools to pre-approve a safe tool set, argument-hint for usability, and context: fork when the output is noisy. Master the anatomy here and you are ready to reason about when a skill is the right tool at all versus CLAUDE.md.
A developer writes a multi-step refactoring procedure and wants Claude to use it automatically when a refactor is requested, while keeping the long instructions out of context on unrelated turns. Which SKILL.md element makes the automatic, on-demand behaviour work?
People also ask
What is a SKILL.md file in Claude Code?
What frontmatter fields can a Claude Code skill use?
Do Claude Code skills load automatically?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
What are skills?
Why watch: Introduces SKILL.md-based skills invoked on demand, the configuration unit this KP defines.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.