Slash Commands and Skills

If you type the same prompt three times, you have found a skill that should exist. The teams pulling ahead convert repetition into reusable files that every session inherits.

Built-in commands worth knowing

Type / in any session to see the full list. These earn their keep daily.

Command	Purpose
/init	Generate a starter CLAUDE.md
/plan	Enter plan mode, optionally with a task
/clear, /compact, /context, /rewind	Context management (Chapter 3)
/memory	Edit memory files
/permissions	Manage allow and deny rules
/model	Switch models
/hooks	Configure hooks interactively
/agents	Create and manage subagents
/mcp	Inspect MCP server connections
/plugin	Browse and install plugins
/security-review	Audit pending changes for vulnerabilities
/review	Review the current diff, a branch, or a pull request (alias of /code-review)

From prompt to command to skill

Custom slash commands began as markdown files in .claude/commands/. They still work, but skills are now the recommended format. A skill gives you the same /name shortcut plus something commands never had: Claude can load it automatically when a task matches its description.

Use this progression:

1. A prompt you typed once. Leave it alone.
2. A prompt you typed three times. Make it a skill with just a SKILL.md.
3. A procedure with steps, templates, or scripts. Grow the skill with supporting files.

Anatomy of a skill

A skill is a folder. Project skills live in .claude/skills/, personal ones in ~/.claude/skills/.

.claude/skills/pr-description/
├── SKILL.md            # required: frontmatter + instructions
├── references/
│   └── examples.md     # loaded only when needed
├── scripts/
│   └── diff_stats.sh   # executable helpers
└── assets/
    └── template.md     # templates, static files

The SKILL.md starts with YAML frontmatter:

---
name: pr-description
description: Writes pull request titles and descriptions for this repo.
  Use whenever the user asks to open, draft, describe, or summarize a PR,
  or says "ship it", "write up these changes", or "PR this".
---

# PR description

1. Run `git diff main...HEAD --stat` and read the full diff.
2. Title: conventional commit style, under 70 characters.
3. Body sections: Summary, Why, Changes, Testing, Risks.
4. Under Risks, call out migrations, auth changes, and config changes explicitly.
5. Follow the tone in `assets/template.md`. Never invent test results.

Progressive disclosure

Skills are cheap because they load in layers. At startup Claude sees only each skill's name and description. It reads the SKILL.md body when the skill is triggered. It opens files in references/ or runs scripts/ only when the instructions say to.

That means you can install dozens of skills with little context cost, and a single skill can carry deep reference material without bloating every session.

The pushy description rule

The description decides whether a skill ever fires. Claude tends to under-trigger skills, so write descriptions that are explicit and a little insistent.

• Weak: "Helps with database stuff."
• Strong: "Optimizes SQL and ORM queries for this service. Use whenever the user mentions slow queries, query plans, N+1 problems, indexes, Prisma performance, or database latency, even if they do not ask for optimization directly."

Include the words people actually say, plus near synonyms. State both what the skill does and when to use it.

One skill, one job

A git-helper that writes commits, PR descriptions, release notes, and changelogs does all four poorly and triggers unpredictably. Four narrow skills compose cleanly and each can be tuned independently.

Keep each SKILL.md under about 500 lines. If it grows past that, move detail into references/.

Three patterns

Pattern	Contents	Best for
A. Instructions only	SKILL.md alone	Style guides, review checklists, commit formats
B. Instructions plus scripts	SKILL.md and scripts/	Deterministic work: validation, conversions, metrics
C. Instructions plus tools	Skill that drives MCP servers or subagents	Multi-step workflows across systems

Start with Pattern A. Move to B when you notice Claude improvising a calculation or check that a script would do identically every time. Move to C only when the workflow genuinely spans systems, because every moving part adds debugging time.

Dynamic context in skills

Skills and commands can pull live context when they run. A line such as Current branch: !`git branch --show-current` executes the command and inlines its output, and @package.json includes a file. Use this to hand Claude exactly the state it needs without a round of exploration.

Testing a skill

1. Write five realistic prompts, including two that do not use the skill's obvious keywords.
2. Run each in a fresh session. Note whether the skill triggered.
3. Where it did not, add the missing phrasing to the description.
4. Where it triggered but the output was off, fix the instructions, not the prompt.

Anthropic's skill-creator skill automates much of this, including description tuning. It is the best way to build your first few.

Libraries worth installing

• anthropics/skills, the official collection, including skill-creator
• obra/superpowers, battle-tested skills for planning, TDD, and debugging
• Trail of Bits skills for security work (Chapter 10)
• awesome-claude-code, the best curated index

Key takeaways

• If you typed a prompt three times, it should be a skill.
• Skills load in layers, so dozens cost little context until one is triggered.
• The description decides whether a skill fires; make it explicit about when to use it.
• Read every community skill before installing it; skills can run scripts on your machine.