Module 4 of 6

Slash Commands & Skills

Core Concepts introduced skills as one of the things that shape what Claude Code knows how to do. This module is the practical follow-up: how to actually invoke slash commands and skills day to day, and how to write your own so your team stops retyping the same instructions.

Quick distinction: a slash command is a saved prompt you trigger by typing /name. A skill is a packaged capability — instructions, and optionally scripts or reference files — that Claude can decide to use on its own when it's relevant, or that you invoke directly. Slash commands are for things you want to kick off by hand. Skills are for things Claude should recognize a need for, sometimes without you asking by name.

Part 1: Slash commands

Built-in slash commands

Claude Code ships with a set of built-in commands for managing the session itself. You don't install these — they're always available. A few you'll use constantly:

Command	What it does	When to reach for it
`/clear`	Wipes the conversation and starts a fresh context window.	Switching to an unrelated task, or context feels cluttered.
`/compact`	Summarizes the conversation so far to free up context space.	A long session is running out of room but you still need history.
`/model`	Switches the active model for the session.	Trading off speed/cost against reasoning depth mid-task.
`/agents`	Lists or configures available subagents.	Setting up delegated work (see the Agentic Workflows module).
`/init`	Generates a starter `CLAUDE.md` for the current project.	Onboarding a new repo so Claude picks up conventions automatically.
`/help`	Lists everything available in the current session.	Whenever you forget what's installed.

Type / at the start of a line in Claude Code and an autocomplete menu pops up — that's the fastest way to discover what's available in any given project, including custom ones your team has added.

Custom slash commands: how they work

A custom slash command is just a Markdown file with a bit of frontmatter. Drop one in a commands/ folder and Claude Code picks it up automatically:

.claude/commands/ in a project — shared with anyone who clones that repo.
~/.claude/commands/ in your home directory — personal, available in every project you open.

The filename becomes the command name. So .claude/commands/pr-summary.md becomes /pr-summary.

Worked example: a custom command

Say your team writes the same PR description every time. Instead of retyping it, save this as .claude/commands/pr-summary.md:

---
description: Draft a PR summary from the current diff
---

Look at the staged and unstaged changes in this repo (git diff and git diff --staged).

Write a pull request description with:
1. A one-line summary of what changed and why
2. A bulleted "What changed" section grouped by area
3. A "How to test" checklist
4. Call out any breaking changes explicitly

Keep it under 200 words. Do not include a title, just the body.

Now anyone on the team can type /pr-summary instead of writing that prompt from scratch. That's the whole value proposition: a slash command turns a prompt you'd otherwise retype into a one-word invocation.

Passing arguments

Commands can accept arguments with $ARGUMENTS (everything typed after the command name) or numbered placeholders like $1, $2 for individual words. For example, a command file containing:

---
description: Explain a file's purpose in plain language
---

Read $1 and explain, in 3-5 sentences aimed at a non-engineer, what it does and why it
exists in this codebase.

...used as /explain-file src/billing/invoice.py would substitute $1 with src/billing/invoice.py.

Tip: good candidates for a custom slash command are prompts you've copy-pasted more than twice, or steps that always follow the same shape — "write a commit message," "summarize this PR," "check this file for obvious security issues." If you notice yourself typing near-identical instructions repeatedly, that's the signal to save it as a command.

Part 2: Skills

What makes a skill different

A skill is a folder, not a single file. At minimum it has a SKILL.md with instructions describing what the skill does and when Claude should use it — it can also bundle helper scripts, templates, or reference docs the instructions point to. The critical difference from a slash command: Claude reads the short description of every installed skill up front, and decides on its own whether a skill is relevant to what you just asked — you don't have to remember to invoke it by name (though you can, e.g. by saying "use the changelog skill").

	Slash command	Skill
Invocation	Explicit — you type `/name`	Automatic (Claude notices relevance) or explicit by name
Shape	Single Markdown file	Folder: instructions + optional scripts/assets
Good for	A specific prompt you run on demand	A capability that should kick in whenever it's relevant
Example	`/pr-summary`	A skill that always applies your team's chart style guide when asked for a graph

Anatomy of a skill

A minimal skill folder looks like this:

.claude/skills/changelog-writer/
  SKILL.md
  templates/
    entry-template.md

And a SKILL.md might read:

---
name: changelog-writer
description: Use when the user asks to write or update a CHANGELOG entry for this repo.
---

# Changelog Writer

When adding a changelog entry:
1. Read templates/entry-template.md for the required format.
2. Look at the merged commits since the last tagged release.
3. Group changes into Added / Changed / Fixed / Removed.
4. Keep each bullet to one line, written for an external user, not internal jargon.
5. Prepend the new entry to CHANGELOG.md under a new version heading.

The description field matters more than anything else in the file — it's what Claude scans to decide whether this skill is relevant to the current request, so write it the way you'd explain the skill's purpose to a new teammate in one sentence.

Where skills live

.claude/skills/ in a project — shared with the team via version control.
~/.claude/skills/ personally — available across every project on your machine.
Organization-managed skills your admin has made available to everyone (no setup needed on your end).

When to reach for which

Write a slash command when...

You always run it explicitly, never implicitly
It's one short prompt with no bundled files
The trigger is a deliberate action ("draft the release notes now")

Write a skill when...

It should activate without you remembering a command name
It needs reference material, templates, or scripts alongside instructions
It encodes a standing convention ("our team always formats invoices this way")

Common mistake: stuffing a huge, general-purpose prompt into a slash command "just in case." Both commands and skills work best narrow and specific — one clear job, described in one clear sentence. If a command is growing branches for five different situations, it's probably several commands (or a skill with clearer conditional instructions), not one.

Try it yourself

Before the knowledge check, try this in a real project:

Type / in Claude Code and see which commands are already available.
Create .claude/commands/ in a repo you use, and add one small command for a prompt you write often.
Restart Claude Code (or open a new session) and confirm /your-command-name shows up.