Claude Code skills vs slash commands vs plugins: which one to use

Short answer: write a skill. In Claude Code, custom slash commands have been merged into skills, so .claude/commands/deploy.md and .claude/skills/deploy/SKILL.md both give you /deploy. A plugin isn't really a third option next to those two. It's a package that can hold skills, subagents, hooks and MCP servers, and you need one only when you ship several pieces together or reuse them across repos.

Behavior details below come from the official Claude Code docs on skills, commands and plugins. The Skillpack commands were run with Skillpack CLI 0.3.5 on 29 October 2026.

The four things people call "slash commands"

Type / in Claude Code and you see a mix of things that look the same but are built differently. The commands reference splits them into built-in commands, whose behavior is coded into the CLI, and bundled skills, which are prompts handed to Claude like the skills you write yourself.

The useful comparison is the last three rows. Everything you write yourself is now either a command file, a skill, or a skill packaged in a plugin.

Skill vs custom slash command

The skills page is direct about it: your existing .claude/commands/ files keep working, and skills add optional features on top. In practice, it looks like this.

Two rows matter most. Supporting files let a skill grow past a single prompt: a deploy skill can ship its script and a checklist next to SKILL.md, and Claude reads them only when needed. Portability matters if anyone on your team also uses Codex or Cursor, because both read SKILL.md folders and neither reads .claude/commands/.

When a plain command file is still fine

Keep a command file if it's a short personal prompt, you only use Claude Code, and you have no files to bundle. There's no deadline to migrate. The plugin docs suggest keeping commands/ only for files you are moving over, and say skills supersede commands for new work.

Who invokes it: the setting that replaces "command vs skill"

The old mental model was "a command is something I type, a skill is something Claude picks up." With the merge, that choice moved into two frontmatter fields. This table is from the skills docs:

Use disable-model-invocation: true for anything with side effects, like committing, deploying or posting a message. You decide when it runs, and it costs nothing in context until you type it. Use user-invocable: false for background knowledge, such as how a legacy system works, that Claude should apply but nobody should run as a command.

When a plugin is worth it

A plugin is a directory with a manifest at .claude-plugin/plugin.json and components such as skills/, agents/ (subagents, compared with skills in Claude Code subagents vs skills), hooks/ and .mcp.json. The plugins overview notes that skills, subagents, hooks and MCP servers all work on their own without one. The features overview gives the trigger in one line: when a second repository needs the same setup, package it as a plugin.

Plugins come with costs that a project skill doesn't have. An enabled plugin is part of every session. The name and description of each skill, agent and command Claude can invoke sit in context on every turn. Its MCP servers run and its hooks fire. And whatever it runs, it runs as you. Plugin skills are also namespaced, so review in a plugin becomes /my-plugin:review. That avoids clashes but makes names longer.

You install plugins with /plugin install <plugin>@<marketplace> at user, project or local scope, and while building one you can load it for a single session with claude --plugin-dir ./my-plugin.

A real example: Anthropic's commit-commands plugin

We cloned Anthropic's claude-plugins-official marketplace (commit f8c5e7a) to see how a published plugin is laid out. plugins/commit-commands contains only a plugin.json manifest and a commands/ folder with three files: commit.md, commit-push-pr.md and clean_gone.md. So it's a plugin built entirely from legacy command files. The same repo's example-plugin ships one command both ways, as commands/example-command.md and as skills/example-command/SKILL.md, and states that the two are functionally identical, with only the file layout differing.

How to migrate a command to a skill

We moved commit.md from that plugin into a skill in a scratch repo. Four steps:

1. Create the folder: .claude/skills/commit/.
2. Move the file to .claude/skills/commit/SKILL.md.
3. Add name and a specific description to the frontmatter. Keep allowed-tools as it was.
4. Add disable-model-invocation: true if the command has side effects. A commit does, so we added it.

The resulting frontmatter:

---
name: commit
description: Create a git commit from the current changes
disable-model-invocation: true
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
---

The body, including its ! lines that inject git status, git diff HEAD, the branch and recent commits, stayed the same. You still type /commit. If you leave the old file in .claude/commands/ during the move, the skill runs, because a skill wins a name clash.

Then we checked both layouts with the Skillpack CLI:

skillpack skills validate .claude/skills/commit
# valid: true, name "commit", files: 1, exit 0

skillpack skills validate .claude/commands
# "SKILL.md is missing or oversized", exit 5

The same split shows up with plugins. A skill inside a plugin is still a plain SKILL.md folder, so you can take it without the plugin. A plugin made only of command files can't be taken that way:

skillpack install github:anthropics/claude-plugins-official/plugins/frontend-design/skills/frontend-design \
  --scope project --tools claude-code,codex --dry-run
# targets .agents/skills, .claude/skills and .codex/skills, pinned to commit f8c5e7a, exit 0

skillpack install github:anthropics/claude-plugins-official/plugins/commit-commands \
  --scope project --tools claude-code --dry-run
# "SKILL.md is missing or oversized", exit 5

That last result is what staying on command files costs you in practice. Tools built around the Agent Skills format expect a SKILL.md folder, so a bare command file can't be validated, versioned or installed as a skill. We did not run Claude Code itself in this test, so the invocation behavior above comes from the docs.

For a full walkthrough of writing one from scratch, see How to create a Claude Code skill. For the format itself, see What is SKILL.md?.

What about Codex and Cursor?

Both moved in the same direction as Claude Code.

Codex's docs give the reason: custom prompts need explicit invocation and live in your local Codex home folder, so they aren't shared through the repository. Skills can be invoked explicitly or implicitly and can live in the repo. Cursor's docs describe disable-model-invocation: true as the way to make a skill behave like a traditional slash command. More detail in How to use skills in Codex.

Common mistakes

• Writing new commands in .claude/commands/. They work, but they can't carry files and other agents won't read them. Start new ones as skills.
• Leaving side-effect skills auto-invocable. A /deploy or /commit skill without disable-model-invocation: true lets Claude decide when to run it.
• Wrapping one skill in a plugin. For a single skill shared through one repo, a committed project skill does the job without the per-session plugin overhead.
• Keeping both files during a migration and editing the wrong one. The skill wins the name clash, so edits to the old command file do nothing. Delete it once the skill works.
• Vague descriptions. Claude decides when to load a skill from its description, so "helper" won't trigger. Say what it does and when.

Next step

Pick one command you type every week, move it into .claude/skills/<name>/SKILL.md, and add disable-model-invocation: true if it changes anything. When the team needs the same skills in every repo, create a free Skillpack workspace to version them and install them in each agent with one command.