Fabler Labs → Guides → Claude Code skills

Claude Code skills: create, share & auto-invoke them

Free · no signup · verified against the docs · last updated July 2026

A skill is the unit Claude Code uses to learn a new trick: a SKILL.md file with instructions — a checklist, a procedure, a bit of reference knowledge — that Claude adds to its toolkit and reaches for when it's relevant. Skills are now the umbrella that custom slash commands merged into, so the same format powers both a /deploy you type on purpose and knowledge Claude loads on its own. The reason to care: unlike CLAUDE.md, which is always in context, a skill's body loads only when it's used — so long reference material costs almost nothing until you need it. This page is the practical, copy-paste version: create one, control who can invoke it, bundle scripts, pass arguments, inject live data, and run it in a subagent.

When to reach for a skill

Create a skill when you keep pasting the same instructions, checklist, or multi-step procedure into chat — or when a section of your CLAUDE.md has grown into a procedure rather than a fact. CLAUDE.md is for always-on facts about your project; a skill is for on-demand know-how that only loads when the moment calls for it. Two shapes cover almost everything:

• Reference content — conventions, patterns, style guides, domain knowledge Claude should apply to your current work. Runs inline, alongside your conversation.
• Task content — step-by-step instructions for a specific action: a deploy, a commit, a code-gen routine. Usually something you invoke on purpose with /name.

Create your first skill

A skill is a directory whose name becomes the command, with a SKILL.md inside. Put it in your personal skills folder to have it in every project. This one summarizes your uncommitted changes and flags anything risky — and it pulls the live diff in before Claude reads it:

---
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.

Create the folder with mkdir -p ~/.claude/skills/summarize-changes, save the file, and test it two ways: ask “What did I change?” and Claude loads it automatically because your request matches the description, or type /summarize-changes to run it directly. (Creating a brand-new top-level skills directory needs one Claude Code restart; after that, edits are picked up live.)

Where skills live & which one wins

Where you store a skill decides who can use it. Only two locations matter day to day — personal and project — but the full precedence order is worth knowing:

When the same name exists across levels, enterprise overrides personal, and personal overrides project; a skill at any level also overrides a bundled skill of the same name (a project code-review replaces the built-in /code-review). And if a skill and a legacy .claude/commands/ file share a name, the skill wins. Commit project skills to version control and a git pull is all a teammate needs to get your whole set. In a monorepo, skills also load from nested .claude/skills/ directories, and a clashing nested skill appears under a directory-qualified name like /apps/web:deploy.

Two kinds of skill, side by side

The frontmatter is where a skill stops being “just a prompt file.” Reference skills feed Claude knowledge; task skills give it an action. Same file format, different intent:

---
name: api-conventions
description: API design patterns for this codebase
---

When writing API endpoints:
- Use RESTful naming conventions
- Return consistent error formats
- Include request validation

---
name: deploy
description: Deploy the application to production
context: fork
disable-model-invocation: true
---

Deploy the application:
1. Run the test suite
2. Build the application
3. Push to the deployment target

Keep the body concise. Once a skill is invoked, its content stays in context for the rest of the session — every line is a recurring token cost. State what to do, not how or why, and move long reference material into supporting files.

Let Claude invoke it — or lock it down

By default, both you and Claude can invoke a skill: you type /name, and Claude auto-loads it when your request matches the description. Two frontmatter fields change that, and each also changes what sits in your context:

Rule of thumb: anything that writes, pushes, or spends money gets disable-model-invocation: true — you don't want Claude deciding your code “looks ready” and shipping it. Use user-invocable: false for background knowledge (say, a legacy-system-context skill) that Claude should know but nobody types as a command.

Bundle files with a skill

The biggest thing a skill has over a one-file command: it's a directory, so it can carry templates, examples, and scripts that only load when needed. SKILL.md is the required entrypoint; everything else is optional:

my-skill/
├── SKILL.md          # required — overview + instructions
├── reference.md      # detailed docs, loaded only when needed
├── examples/
│   └── sample.md     # example output showing the format
└── scripts/
    └── validate.sh   # a script Claude runs (executed, not loaded)

Reference the extra files from SKILL.md so Claude knows what each contains and when to open it (e.g. “For complete API details, see reference.md”). To run a bundled script from anywhere, point at it with ${CLAUDE_SKILL_DIR}, which resolves to the skill's own folder no matter where it's installed:

---
name: codebase-visualizer
description: Generate an interactive tree view of your codebase. Use when exploring a new repo or understanding project structure.
allowed-tools: Bash(python3 *)
---

Run the visualization script from the project root:

```bash
python3 ${CLAUDE_SKILL_DIR}/scripts/visualize.py .
```

Grant the tools a skill needs with allowed-tools (space- or comma-separated, or a YAML list) so it runs without a permission prompt each time. For a project skill, that takes effect once you accept the workspace-trust dialog — so review project skills before trusting a repo, since a skill can grant itself broad access.

Arguments & substitutions

Whatever you type after the skill name is available in the body. $ARGUMENTS is the whole string; index into individual words with $ARGUMENTS[0] / $0. If a skill has no $ARGUMENTS at all, your input is appended as ARGUMENTS: <value> so Claude still sees it.

---
name: migrate-component
description: Migrate a component from one framework to another
argument-hint: [component] [from] [to]
---

Migrate the $0 component from $1 to $2.
Preserve all existing behavior and tests.

Wrap multi-word values in quotes to keep them together — /migrate-component "Search Bar" React Vue makes $0 = Search Bar. For readable names, declare an arguments: [issue, branch] list and reference them as $issue / $branch. A few other substitutions are handy in bundled scripts and logging: ${CLAUDE_SESSION_ID}, ${CLAUDE_PROJECT_DIR}, and ${CLAUDE_EFFORT}.

Inject live data before Claude reads it

The most useful advanced trick: run a shell command before the skill reaches Claude and drop its output straight into the prompt. A line beginning with ! and a backtick does exactly that — Claude receives real data instead of the command:

## Environment
```!
node --version
npm --version
git status --short
```

## Changes
!`git diff HEAD`

Two details that trip people up: the inline ! form is only recognized at the start of a line or right after whitespace (so KEY=!`cmd` stays literal), and for several commands use a fenced block opened with three backticks and an !, as above. Always list the commands you inject under allowed-tools.

Run a skill in its own subagent

Add context: fork and the skill runs in a fresh, isolated context — the SKILL.md content becomes the subagent's whole task, and the result is summarized back to you. Pair it with live injection and it's a clean, self-contained routine that never clutters your main conversation:

---
name: pr-summary
description: Summarize changes in a pull request
context: fork
agent: Explore
allowed-tools: Bash(gh *)
---

## Pull request context
- Diff: !`gh pr diff`
- Comments: !`gh pr view --comments`
- Changed files: !`gh pr diff --name-only`

## Your task
Summarize this pull request: intent, risky changes, and anything a
reviewer should look at closely.

The agent field picks which subagent runs it — a built-in (Explore, Plan, general-purpose) or any custom one from .claude/agents/; it defaults to general-purpose. Note context: fork only makes sense for task skills with explicit instructions — a pure reference skill forked into a subagent has nothing to act on.

The frontmatter, at a glance

Every field is optional; only description is recommended. The ones you'll actually use: