Claude Skills Explained: What They Are and How to Use Them

You keep hearing that Claude Code skills will change how you work, but every explanation you find is either the official reference docs or a giant GitHub list of 300 skills with no on-ramp. You want the version that tells you what a skill actually is, how to make one, and when it is worth the effort. That is what this is.

A Claude skill is not a plugin, a prompt, or a setting. It is a folder with one markdown file that teaches Claude how to do a specific kind of work, and that Claude loads only when your request matches it. Once that clicks, the whole system gets simple.

Key takeaways

• A skill is a folder containing a single SKILL.md file: YAML frontmatter that says when to use it, plus markdown instructions for what to do.
• Skills load on demand. Only the short description sits in context by default; the full instructions load when your request matches, so your context window stays lean.
• Where you save the folder sets who can use it: personal (~/.claude/skills/), project (.claude/skills/, committed to git), or bundled in a plugin.
• Invoke a skill two ways: let Claude trigger it automatically from your phrasing, or call it directly with /skill-name.
• The most common failure is a vague description. A specific, keyword-rich description is what makes auto-triggering reliable.
• A skill tells the AI HOW to do the work. It does not carry YOUR facts, decisions, and current context. That is a separate job, and it is where most "why does the output still sound generic" problems live.

What is a Claude skill?

A skill is the on-demand expertise layer of Claude. Mechanically, it is a folder with a SKILL.md file inside. That file has two parts: YAML frontmatter between --- markers that tells Claude when the skill applies, and markdown below it with the actual instructions Claude follows when the skill runs.

The important design idea is progressive disclosure. Claude does not read every skill you have on every request. The short description from each skill's frontmatter sits in context so Claude knows the skill exists. The full body loads only when your request matches that description. This is why you can keep dozens of skills installed without bloating your context window or slowing every prompt down.

Skills are not exclusive to the terminal. The same skill format works across the Claude apps, Claude Code, and the API, so a skill you write once travels with you. In this guide the examples use Claude Code because that is where the phrase "claude code skills" sends most people, but the concept is the same everywhere.

One clarification that saves confusion: a skill is different from a prompt and different from a plugin. A prompt is one-off instruction text you type. A plugin is a packaging and distribution layer (more on that below). A skill sits in between: reusable, structured, and loaded automatically when relevant.

Where skills live (and who can use them)

The folder you save a skill into decides its scope. This is the single most useful table to keep in your head.

Personal skills at ~/.claude/skills/ follow you across all your projects. Project skills live inside a repo at .claude/skills/ (no tilde), get committed, and ship with the codebase, so every teammate who clones the repo gets the same skills automatically. On Windows, ~/.claude resolves to %USERPROFILE%\.claude.

When two skills share a name across levels, the more specific level wins in a defined order: enterprise overrides personal, and personal overrides project. You rarely need this, but it is good to know when a skill behaves unexpectedly.

How to create a skill, step by step

Here is a complete, copyable personal skill. It summarizes your uncommitted changes and flags anything risky. Nothing about the structure is specific to this task, so you can reshape it for anything.

Step 1. Make the folder.

mkdir -p ~/.claude/skills/summarize-changes

Step 2. Write SKILL.md inside that folder at ~/.claude/skills/summarize-changes/SKILL.md:

---
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
---

## Current changes

!`git diff HEAD`

## Instructions

Summarize the changes above in two or three bullet points, then list any
risks you notice such as missing error handling, hardcoded values, or tests
that need updating. If the diff is empty, say there are no uncommitted changes.

That is the whole skill. The frontmatter description is the trigger. The markdown is the behavior. The folder name (summarize-changes) becomes the command you can type to invoke it directly.

A few rules that keep skills healthy:

• The only required file is SKILL.md. Scripts, reference docs, and assets are optional extras you can add later and point to from the main file.
• Keep SKILL.md under about 500 lines. If it grows past that, move detail into separate files and reference them, so Claude only pulls in what it needs.
• Do not nest too deep. The single most common install error is a path like ~/.claude/skills/summarize-changes/some-folder/SKILL.md. The SKILL.md must sit directly in the named skill folder.

You usually do not need to restart. Claude Code watches your skill directories and picks up new or edited skills within the current session. The one exception: if you create a top-level skills/ directory that did not exist when the session started, restart once so it can be watched.

How to invoke a skill

There are two ways to run a skill, and you will use both.

Automatic. Ask something that matches the skill's description, and Claude loads it for you. With the example above, typing "what did I change?" triggers summarize-changes because the description names that exact intent.

Direct. Call the skill by name with a slash: /summarize-changes. This is handy when you know exactly which skill you want and do not want to leave the match to phrasing.

The description is not documentation. It is the trigger. A vague line like "helps with code" almost never fires; a specific, keyword-rich line fires reliably.

The description is where reliability lives or dies. Claude decides whether to load a skill by matching your request against that one line. So write it the way you would actually ask: name the tasks, name the trigger words, be concrete. This one sentence does more for reliability than anything else in the file.

Skills vs plugins vs Memory Packs

These three get conflated constantly. They solve different problems.

A plugin is just a convenient wrapper: installing one can add several skills at once and keep them updatable. You can even turn a single skill folder into a plugin by adding a .claude-plugin/plugin.json to it. So skills and plugins are the same axis at different scales: what to do, and how to distribute it.

Memory Packs are a different axis entirely, and it is the one most people are missing. A skill can be flawless at telling Claude how to write a launch email, and the email will still sound like nobody, because the skill does not know your product's positioning, your pricing, the objection you keep hearing on sales calls, or the opinion you formed last week. A Memory Pack is the "your facts" half of the pair: a bundle of real context you can inject into your brain so the same skill produces your output instead of a generic one. Skills tell the AI how. Memory Packs tell it what is true about you.

The part nobody tells you: skills go stale too

Here is the failure mode that shows up a month after you fall in love with skills. You write a skill that references your current stack, your naming conventions, or your pricing. It works. Then you migrate a library, rename a service, or change a price, and the skill keeps confidently applying the old rule. A skill is static text. The moment your reality moves, the skill is quietly wrong, and you are back to being the maintenance worker who updates it by hand.

This is the same problem a hand-built second brain has, and it is worth naming plainly: the value of any AI instruction is capped by how current its underlying facts are. Skills fix the "how" and freeze it in place. They do nothing for the "what is true right now."

That current-facts layer is exactly what Locul is built to be. Locul is a local-first second brain that builds itself from what you already produce (your local files, your PDFs, your dictation, your Notion, and your LinkedIn profile) and keeps itself current on its own, then serves that context to Claude and other tools over MCP. When your pricing changes or your opinion evolves, the old fact is marked superseded and the new one becomes active, without you editing anything. Pair a good set of skills (the how) with a brain that stays current (the what), and the output stops drifting. If you want the deeper version of why current context is the real lever on AI quality, the how to give your AI a memory that lasts guide walks through it. Locul is free to start with 500 memories on local AI, so you can wire it into your Claude setup and see the difference before you decide anything.

A quick mental model to keep

If you remember one thing, make it this split:

• Skills and plugins are the how. Reusable, on-demand, structured instructions Claude loads when your request matches. Cheap to write, easy to share, worth building for any task you repeat.
• Memory (and Memory Packs) are the what. Your real, current facts and context, kept up to date so the AI's output reflects your world instead of the internet's average.

Most people install a pile of skills, get a burst of improvement, then plateau, because they solved the how and never touched the what. Solve both and the improvement compounds.

FAQ

What is a skill in Claude Code?

A skill is a folder containing a SKILL.md file that teaches Claude how to perform a specific kind of task. The file has YAML frontmatter describing when to use the skill and markdown instructions for what to do. Claude loads the skill only when your request matches its description.

Do skills work in Claude Code, or only in the app?

Both. The same skill format works across the Claude apps, Claude Code, and the API. A skill you write once is usable in every surface, though where the SKILL.md folder lives differs by environment.

How do I create a Claude skill?

Make a folder in your skills directory (for example ~/.claude/skills/my-skill/), then add a SKILL.md file inside it with a description in the frontmatter and your instructions below. That is the minimum. Everything else, like scripts and reference files, is optional.

How do I use or trigger a skill?

Two ways. Ask something that matches the skill's description and Claude loads it automatically, or invoke it directly by name with /skill-name. A specific, keyword-rich description is what makes automatic triggering reliable.

Where are Claude Code skills stored?

Personal skills live at ~/.claude/skills/, project skills live at .claude/skills/ inside a repo (and get committed to git), and plugin skills live inside the plugin. On Windows, ~/.claude resolves to %USERPROFILE%\.claude.

Is a skill the same as a plugin?

No. A skill is a single folder of instructions. A plugin is a distribution layer that can bundle several skills (plus agents, hooks, or MCP servers) so you can install and update them together. You can add a skill by hand with no plugin at all.

Will my skills go out of date?

The instructions will not, but any facts baked into them will. If a skill references your stack, naming, or pricing, it keeps applying the old values after you change them. Keep the durable "how" in skills and keep the changeable "what is true now" in a memory layer that updates itself, so you are not hand-editing skills every time your reality moves.