Claude Code Skills: How to Create, Use, and Install Them

When you hand Claude Code the same kind of work more than a few times, you start wanting the format and the order you settled on to carry over to the next run. Typing the whole instruction again feels wasteful, and keeping it in a notes app is not quite enough. Two situations show the problem. You have probably hit both.

The first is retyping the format and the exclusion list for a weekly report four times in a row, then doing it all again the following week. The second is writing your deploy steps into a project memo, only to find the file is never read on its own. Every session you have to say "read this file and follow the steps in it" one more time.

The two situations break down at different points. In the first, there is nowhere to put the instruction, so you start from zero every time. In the second, you did write it down, but it is not read at the moment it matters. Skills solve both at once. We will start with what a skill is, then move through creating one, using one, and bringing in skills other people made.

What is a Claude Code skill?

In a game, a skill is a technique your character learns. It can be a single new ability, like generating a PDF or reading a recording, or several moves chained into one technique. Pulling metrics from a spreadsheet every week, analyzing them, and producing a report PDF is a skill in the chained sense.

A skill in Claude Code is close to a playbook the agent pulls out mid-task. Write down how to do something new, or the steps of a routine you repeat, and the agent opens it on its own at the right moment.

Skill

A skill is a file that tells Claude how to do something new, or how to run a multi-step task against the same standard every time. Claude loads it automatically when it judges the skill relevant, and you can also call it directly with /skill-name.

Skills are not a Claude Code exclusive either. The Agent Skills format that Anthropic created has been released as an open standard, and the official support list carries more than 40 tools. Cursor, GitHub Copilot, Gemini CLI, ChatGPT, and Codex all read the same format. This post focuses on using skills inside Claude Code. The Agent Skills standard itself deserves its own post.

Skills are also not code automation for developers only. The test is not whether you write code. It is whether you repeat the same explanation and the same steps. A monthly closing routine, a weekly report template, or the order you always follow when organizing research can all become skills.

I moved my own monthly GA4 reporting into a skill. I used to re-explain the date range, the metrics, and the ordering every single time. Once the steps lived in a file, one command produced the same report format every month.

A skill is a single SKILL.md file

Now that the concept is clear, here is what a skill physically looks like. It is one file inside a folder. The header says when to use it, and the body holds the steps to follow. If you have been pasting the same checklist into chat over and over, this is where that content moves so the agent can pull it out by itself.

The same logic applies when step-by-step procedures pile up in your CLAUDE.md project file. CLAUDE.md is read in full at the start of every session, while a skill body is read only when the skill is actually used. Facts about the project belong in CLAUDE.md. Procedures that only matter for one kind of task are better off as skills.

Custom slash commands, the older way of saving a frequent instruction behind /name, have been folded into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and behave the same. Files you made under the old system keep working.

Ask Claude to create the skill for you

So how do you make one? As of September 2026, the easiest way is to ask Claude to build it. You do not have to create the folder and the file by hand. Describe the repeated task and the result you want in plain language, and Claude sets up the folder and writes the SKILL.md.

If it is a task you already repeat, describe the instruction you currently use and the output format, and ask Claude to package it as is.

"Every week I turn last week's task list into a table, drop the dates, and add a three-line summary at the end. Make that routine into a skill."

If you have not done the task yet, you do not need to design it alone. Say you will describe the work and want to shape it together, and Claude asks questions that pin the steps down.

"I want to build a skill for a task I will repeat every week. I will describe the work, so let's flesh it out together and create it."

Also say where you will use it. If the skill should follow you across projects, ask for it explicitly: "make it global so I can use it across my whole account". The difference is covered in its own section below.

Open the file and check what was made

When Claude says the skill is done, do not take that as the finish line. Ask "open the SKILL.md you just made and show me", then read it together. Check two things in particular: whether the description contains the phrases you would actually say, and whether the steps and the finish condition in the body match what you wanted. Understanding the file's structure matters more than memorizing the creation command, because next time you will need to edit it.

That covers the spoken route. Here is the manual route too. All you need is one folder and one file, at a path shaped like this.

~/.claude/skills/my-skill-name/SKILL.md

Create a folder named after the skill and put SKILL.md inside. There is no registration step. The folder name becomes the slash command name.

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

mkdir creates a folder, and -p creates any missing folders along the way. This one line builds everything from .claude down to summarize-changes. Now the SKILL.md goes inside.

SKILL.md structure: header and body

SKILL.md splits into a header and a body. The header at the top is called front matter. It is where Claude reads what the skill is and when it is needed. The body below is the instruction Claude actually follows once the skill triggers.

The boundary is a --- line. The header sits between two --- lines, and the body starts right after.

---
Header: tells Claude what this skill is
---

Body: the instructions Claude actually follows

The field that does the real work in the header is description. It states what the skill does and what kind of request should trigger it. The body carries the commands to run, the working order, the output format, and the condition for being done. Filled in, it looks like this.

I would not start from a blank file. Having Claude generate one, opening it, and editing it toward your goal is faster. Fixing something filled in beats staring at an empty screen, and it teaches the format along the way.

---
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, requests a commit message, or wants the changes reviewed.
---
 
## Current changes
 
!`git diff HEAD`
 
## Instructions
 
Summarize the changes above in two or three bullets. Then list any visible risks,
such as missing error handling, hard-coded values, or tests that should change with the code.
If there are no changes, say so.

Per the official docs, every header field is optional and only description is recommended. Claude reads this description in the background to decide whether the skill fits the current request. When auto-invocation misfires, this is the first place to fix.

The !`git diff HEAD` line gets replaced with the command's output. Claude Code runs the command before Claude sees the file and substitutes the result into that line. Claude starts with the actual diff in hand rather than an instruction to go look it up.

Global install vs project install

Think of a project as a workshop. A project install keeps the tool inside that one workshop, so it does not follow you elsewhere. A global install keeps the tool on your account, so it is there wherever you work.

You do not need to memorize the paths. Just remember that the leading ~ means your account's home folder.

For a routine you repeat alone across projects, global is the convenient choice. For a rule that belongs to one project, or a procedure the team must share, put it inside the project. Starting global and moving a skill into a project later, once the team needs it, works fine too.

Calling a skill: slash command or plain language

Once it exists, it is time to use it. There are two ways to call it. First, the direct slash command.

/summarize-changes

Plain language works too.

what did I change?

If the sentence matches the situations written in the description, Claude triggers the skill on its own.

You do not need to restart the terminal to use a skill you just made. Claude Code watches the skill folders and picks up changes live, in the session that is already open. The one exception: if this session started before the top-level skills folder existed at all, for example the very first skill on your account, that first time requires a restart.

The description decides auto-invocation

In the background, Claude holds only a list of skill names and descriptions, not the bodies. It scans that list to judge which skill the current request needs. So do not write just a task name into description. Write the phrases a user would actually say and the moments it should fire.

For example, "summarize changes" alone is weaker than "use when the user asks what changed, or requests a commit message". The second version fires at the right time.

Descriptions have a length limit. In the list, each entry is truncated at 1,536 characters. And as skills pile up, the descriptions of your least-used skills get trimmed first. That is why the most important use case and trigger phrasing belong at the front.

Keep the body short too. The official docs recommend keeping SKILL.md under 500 lines, because once a skill loads, its content stays in the conversation and consumes context for the rest of the session. When it grows, move the detail into other files in the same folder and have SKILL.md point to them, like reference.md. Those files are read only when needed.

Write instructions you can verify. "Follow the team conventions" is weaker than "function names start with a verb", because the second one states the behavior and the observable result.

I would define the finish condition before the run count. When I built my fact-check skill, I first wrote "verify three times", and some posts still had corrections on the third pass. So I replaced the count with a condition: repeat until a pass finds nothing to fix. Writing what to check before stopping, not how many times to run, is what makes results consistent.

Blocking auto-run: deploy, commit, send

Some tasks should never run just because Claude decided to. Deploys, commits, and sending messages are the usual suspects. For these skills, block auto-invocation. You can ask Claude to "make this skill run only when I call it myself", or add one line (disable-model-invocation: true) to the header directly.

---
name: deploy
description: Deploys the application to production
disable-model-invocation: true   # this line blocks auto-invocation
---

With this set, the skill runs only when the user types /deploy. Claude does not even know the skill exists. It stops Claude from starting a deploy on the grounds that the code looked ready.

The opposite direction exists too. Set user-invocable: false and only Claude uses the skill. It disappears from the user's menu. This suits background-knowledge skills a user would never run as a command.

When it never triggers, or triggers too often

If a skill does not auto-trigger, first ask "what skills are installed?" or type /skills and check whether it appears in the list. If it is listed, the description is the likely problem. Put the words a user would naturally say, and the trigger moments, into the description.

If it is missing from the list entirely, the front matter may be malformed. In that case /skill-name may still work while auto-invocation does not.

If it triggers too often, narrow the description's scope. If you only ever want to call it yourself, add disable-model-invocation: true. And if descriptions seem to be getting cut off, run /doctor to see how much context the skill list consumes and which skills take the most.

Built-in skills and the marketplace

You can also use skills other people made. When a good one already exists, there is no reason to build from scratch.

Claude Code ships with skills already in the box. /doctor, /code-review, /debug, /batch, /loop, and /claude-api are the notable ones, and the list grows with new versions. No install needed. Type the command and it runs.

If the skill you need is not built in, the official marketplace covers the next step. For example, skill-creator, a plugin for building and refining skills, installs with this command.

/plugin install skill-creator@claude-plugins-official

The official marketplace is registered from the moment Claude Code starts, so this command is usually all it takes. If you see a message that the marketplace cannot be found, the registration is stale or missing. Refresh first with /plugin marketplace update claude-plugins-official, and if that does not fix it, add it with the command below.

/plugin marketplace add anthropics/claude-plugins-official

After installing, run /reload-plugins to use the new skills in the current session. For skills that are not on any marketplace, you can also copy a published SKILL.md folder straight into place.

When names clash, the personal skill wins

Once you start pulling in other people's skills, a name can collide with one of yours. How you installed it decides what happens. Marketplace installs never collide in the first place, because they live behind /plugin-name:name rather than /name. Real collisions happen when you copy a published SKILL.md folder directly into your account or project folder. Then only one runs: the skill in your account folder overrides the one inside the project. And if your company distributes skills at the enterprise level, those override yours.

The real problem is the silent case, where the wrong skill runs and you never notice the overlap. After adding a new skill, check the list with /skills. If you see the same name twice, rename one of the folders. The folder name is the command name, so renaming the folder is the whole fix.

Sharing your skills with others

A skill is not a setting locked inside an app. It is a file. Copy the folder and it moves to another project. It also works in any other AI tool that supports the same Agent Skills format.

You can publish to a GitHub repository or distribute through a skills marketplace as well. The details of distribution deserve their own post.