Claude Code Skills vs Slash Commands

The short answer is: a Skill is the file, while a slash command is the invocation. People often use the terms interchangeably because typing /review is how you activate a Skill, but the distinction matters when you organize a project.

Skill vs slash command at a glance

The shortest decision rule is: keep a one-off task in the prompt; put a repeatable checklist in a Skill; delegate an independent investigation to a subagent; use a hook only when an event should trigger the action automatically. A slash command is the name you type to start a workflow, not a competing execution model.

The important consequence is that /review is not magic by itself. Its behavior comes from the instructions Claude loads for that command. The quality of the result depends on the description, the workflow, the boundaries, and the verification steps inside the file.

Where the files live

Project Skills belong in .claude/skills/. They travel with the repository and should contain rules specific to that codebase. Personal Skills belong in ~/.claude/skills/ and are available across projects. Existing .claude/commands/ files continue to work; Anthropic's current documentation treats custom commands as a legacy format with the same invocation behavior, while Skills also support directories and supporting files.

Use project scope for commands such as /check-migrations or /review-actions when the workflow depends on local architecture. Use global scope for workflows such as /commit, /debug, or /branch-readiness that you want everywhere.

project/
└── .claude/
    └── skills/
        ├── review.md
        └── check-migrations.md
 
~/.claude/
└── skills/
    ├── commit.md
    └── branch-readiness.md

If the same name exists in both places, the project-specific version should win because it knows more about the repository it is operating in.

What belongs in a Skill

A good Skill makes five things explicit:

1. The task it handles and when it should be used.
2. The first read-only inspection step.
3. The files, tools, or boundaries it may touch.
4. The checks that prove completion.
5. The format of the final report.

For example, a /review Skill should say whether it can edit files. A /ship Skill should say whether it can push. A /check-migrations Skill should state whether it is allowed to connect to a database. Ambiguity is where reusable automation becomes risky.

When a slash command is enough

Not every repeated phrase deserves a Skill. Keep a request as a normal prompt when it is short, one-off, or still changing. Turn it into a Skill when you have repeated it enough to know the stable sequence and the evidence needed to verify the result.

The practical rule is simple: prompts are flexible, Skills are repeatable. Start with the prompt, capture the workflow after the third or fourth repetition, then trim the Skill until a new session can follow it without your private context.

Check the current behavior in the official documentation

Claude Code's command and Skill behavior changes over time. This guide was checked against the official documentation on September 28, 2026. Before copying a path or frontmatter field into a project, verify it against the current Skills guide, subagents guide, and hooks guide. Those references are the source of truth for supported fields and lifecycle behavior.

Read the Claude Code Skills examples for complete workflows and the main Skills guide for frontmatter and discovery details.