Slash commands

Status: 🟩 COMPLETE (🟦 LIVING) Last updated: 2026-06-19 Plain-English tagline: Type /name and Claude runs a specific skill — built-in or one you’ve written. The shortcut layer between you and repeatable workflows.

In plain English

A slash command is a typed shortcut: you write /something in your message, and Claude executes a specific predefined action. Some are built into Claude Code; some come from installed plugins; you can write your own.

In 2026, slash commands and skills are unified. Every skill (a markdown file teaching Claude how to do a specific task) automatically gets a /slash-command interface. Older .claude/commands/<name>.md still works, but new commands are now written as skills under .claude/skills/<name>/SKILL.md.

The point of slash commands:

Speed. Less typing for things you do often.
Consistency. The same workflow runs the same way each time.
Shareability. Skills/commands can be packaged into plugins and distributed.
Discoverability. Typing / shows you what’s available.

Why it matters

Slash commands are the bridge between “I know how I want this done” and “Claude does it that way every time.” They convert repeatable patterns into one-keystroke actions.

For day-to-day productivity, the difference between knowing about slash commands and not is significant. Without them, every repeatable task is a re-typed prompt; with them, it’s a single command.

The built-in commands you should know

A subset of what’s available in your current setup:

Code workflow

/code-review — comprehensive review of pending changes at chosen effort level (low/medium/high/ultra)
/verify — verify a PR or change works by running the app and observing behavior
/run — launch the project’s app to confirm a change works in practice
/simplify — review the changed code for reuse/simplification opportunities, then apply fixes
/security-review — security audit of pending changes

Project setup

/init — initialize CLAUDE.md for a new project
/review — review a pull request

Claude Code config

/permissions — view/edit permissions (terminal only in some contexts)
/agents — manage subagent definitions
/hooks — view/edit hooks
/config — general configuration
/model — switch between Opus / Sonnet / Haiku / Fable
/fast — toggle fast mode (Opus with faster output)
/doctor — diagnostic checks

Memory

/consolidate-memory — reflective pass over memory files: merge duplicates, prune index
/remember — save something to memory (uses AskUserQuestion to clarify what)

Scheduling & automation

/schedule — create, update, or run scheduled cloud agents (cron-style)
/loop — run a prompt or slash command on a recurring interval

Documents & artifacts

/anthropic-skills:docx — create or edit Word documents
/anthropic-skills:pdf — read, create, manipulate PDFs
/anthropic-skills:pptx — slide decks
/anthropic-skills:xlsx — spreadsheets
/anthropic-skills:canvas-design — create posters, designs
/anthropic-skills:algorithmic-art — generative art via p5.js
/anthropic-skills:brand-guidelines — apply brand guidelines
/anthropic-skills:theme-factory — style artifacts with 10 preset themes

Cowork / plugins

/cowork-plugin-management:create-cowork-plugin
/cowork-plugin-management:cowork-plugin-customizer

Help / meta

/help — built-in help

That’s not exhaustive but covers the daily-use majority.

Skill vs command — the modern relationship

The terminology overlap:

A skill is a markdown file that teaches Claude how to do a task. It lives at .claude/skills/<name>/SKILL.md.
A slash command is the invocation of a skill — /name.

Every skill gets a slash-command invocation automatically. There’s no separate “command” step; if you have a skill, you have a command. The 2026 unification was about removing this conceptual split.

(There’s also legacy .claude/commands/<name>.md that pre-dates the unification — still works, but new commands should be written as skills.)

Writing your own slash command (as a skill)

Create ~/.claude/skills/<name>/SKILL.md (or <project>/.claude/skills/<name>/SKILL.md for project-local):

---
name: pre-pr-checklist
description: Run the full pre-PR checklist — typecheck, lint, build, test
---
 
Before opening a PR, run these steps in order. Stop and report at the first failure.
 
1. `npm run lint` — fix any errors
2. `npm run typecheck` — fix any type errors
3. `npm run build` — fix any build errors
4. `npm test` — fix any test failures
 
Then summarize:
- What changed (one paragraph)
- What was tested
- Any known limitations or follow-ups
 
Format the summary as the PR description.

That’s a complete skill. After saving it, type /pre-pr-checklist in any session and Claude will execute the steps. Or Claude may invoke it autonomously when you describe a task that matches the description.

Key details:

name is the slug used for the slash command (/pre-pr-checklist)
description is read by Claude when deciding whether to apply the skill autonomously — make it specific
The body is the instructions. Claude reads it and follows it as if you’d just typed the same thing as a prompt
Subfolders can hold supporting files (templates, scripts, data) the skill references with relative paths

Skill arguments

Pass arguments after the command:

/code-review ultra
/code-review high --fix
/code-review --comment

The skill receives the arguments and can branch on them. The convention is to document accepted arguments in the description.

Autonomous skill invocation

A skill’s description field is also read by Claude when deciding whether to use the skill on its own — without you typing the command.

If you write a skill with description “Run the pre-PR checklist” and you later say “let’s get this ready to ship,” Claude can recognize “ready to ship” is similar to “pre-PR” and apply the skill automatically.

This is the value of writing good descriptions. Vague descriptions mean skills only fire when you explicitly type the command. Sharp descriptions mean Claude picks them up at the right moment.

Plugin commands (namespaced)

When a skill comes from a plugin, the slash command is namespaced:

/anthropic-skills:docx
/cowork-plugin-management:create-cowork-plugin

The pattern is /<plugin-name>:<skill-name>. This prevents collisions when different plugins ship skills with the same name.

You can configure aliases or top-level shortcuts in settings.json if you want a shorter version.

A concrete example: building a “deploy to staging” skill

Suppose you’re tired of typing the same deploy sequence:

---
name: deploy-staging
description: Deploy the current branch to the staging Vercel environment
---
 
Steps:
 
1. Run `npm run build` and confirm it succeeds.
2. Push the current branch to GitHub (if it's not already pushed).
3. Run `vercel --target=preview` to deploy to staging.
4. Wait for the deploy to finish.
5. Report the preview URL.
 
If any step fails, stop and report the error. Don't try to fix without asking.

After saving, /deploy-staging runs the whole flow. You can also say something like “let’s get this ready for the team to test,” and Claude may apply the skill autonomously based on the description.

Where Claude Code finds your skills

The lookup order (highest priority wins):

Project skills — <project-root>/.claude/skills/<name>/SKILL.md
User skills — ~/.claude/skills/<name>/SKILL.md
Plugin skills — installed via plugins; namespaced

If a project-local skill has the same name as a global one, the project version wins. This lets projects override defaults.

Listing what’s available

In a Claude Code session, typing just / will surface available commands. The list updates as you install plugins or add skills.

Programmatically: skills live as files, so you can ls ~/.claude/skills/ to see your custom ones.

Common gotchas

Description quality determines autonomous use. A vague description means the skill only fires when you explicitly type /name. Sharp descriptions get applied at the right moment without your prompting.
Name conflicts. Project skill > user skill > plugin skill. If your /deploy doesn’t behave as expected, check if a higher-priority version exists.
Skills run with your current permissions. A skill that calls Bash needs Bash permission. If the skill tries to do something not in your allow list, you’ll get prompts.
Skills don’t have their own memory. They run in the current session’s context. If a skill needs to remember something across sessions, use the memory system.
Slash command typos are silent — sort of. /dploy-staging may not match anything, in which case Claude treats it as literal text in your message. Watch your typing.
Long skills should be split. A skill that’s hundreds of lines is harder to maintain. Split into multiple skills that compose.
Plugin-namespaced commands are verbose. /anthropic-skills:docx is long. Aliasing or sourcing from a top-level skill helps if you use one constantly.
/init overwrites without asking. Be careful when running it in a project that already has a CLAUDE.md — it can clobber content.
Some commands are terminal-only. /permissions, /agents, /config, /hooks open interactive panels that may not work in every Claude Code surface (e.g. cowork sessions). If a command “doesn’t do anything,” check whether it’s a terminal-only one.

Tech & AI, Explained

Explorer

slash-commands