Commands, Skills, and Plugins: Which One Do You Actually Need?
If you’ve started customizing an AI coding tool like Claude Code, you’ve run into three words that get used almost interchangeably: commands, skills, and plugins. They sound like competing options you have to choose between. They’re not.
They’re three rungs of the same ladder. Each one is the next step up in power — and in effort. The trick is knowing which rung your problem actually needs, because most people reach for the top when the bottom would have done fine.
Here’s the whole thing in one sentence: a command is a saved prompt you trigger, a skill is a capability the AI reaches for on its own, and a plugin is a bundle of those you can hand to other people. The rest of this post unpacks each one.
Commands: a saved prompt with a shortcut
A command is the simplest possible customization. It’s a single text file
holding a prompt you’d otherwise retype, given a slash command
A shortcut you trigger by typing a slash and a name, like /commit. The
tool swaps in the saved text as if you’d typed it yourself. It’s a
keyboard shortcut for a prompt, nothing more.
/commit or /standup.
You write the file, you type the shortcut, the prompt runs. That’s the
entire model. It’s the exact “save the recipe” idea from the reporting
walkthrough, just formalized into a /name you trigger.
Pros
- Dead simple — one file, no structure to learn. You can make one in a minute.
- You’re in control of when it runs, because nothing happens until you type it.
- Perfect for a prompt you use constantly but always by choice.
Cons
- It’s just a prompt. It can’t bundle a script, a reference document, or an example file alongside it.
- You have to remember it exists and trigger it yourself — it never fires on its own at the right moment.
Reach for a command when: you keep typing the same instruction and you always want to pull the trigger yourself — a commit-message generator, a “rewrite this the way I like it” prompt, a stand-up summary.
Skills: a capability the AI uses on its own
A skill is a command that grew up. Instead of a lone file, it’s a small
folder, and the crucial addition is a plain-English description of when
the skill should be used. That description is what lets the AI invoke it automatically
The difference between a command and a skill’s headline feature: with a
skill, the model reads your description of when it’s useful and pulls the
skill in by itself the moment your request matches — no slash command
required. You can still trigger it manually too.
(In current Claude Code the two have actually been merged under the hood: a command is simply the bare-bones, single-file version of a skill. So this isn’t command versus skill — it’s the same system with more features switched on.)
A skill can also carry more than a prompt: bundled scripts it can actually
run, example files, longer reference docs it only opens when needed. And
it’s cheap on memory, thanks to progressive disclosure
Only the skill’s one-line description sits in the AI’s working memory all
the time. The full instructions load only when the skill is actually used,
and any bundled reference files load only if they’re needed. So you can
attach a 40-page manual to a skill and it costs almost nothing until the
moment it’s relevant.
Pros
- The AI applies it at the right moment on its own — you don’t have to remember to trigger it.
- Can bundle real files and runnable scripts, so it does actual work, not just talk.
- Nearly free on memory until it’s used, so you can attach heavy reference material.
Cons
- More to set up — a folder, and a description you have to word well.
- That description is make-or-break: too vague and it never triggers, too broad and it fires when you didn’t want it.
- Once loaded, its instructions stay in the AI’s memory for a while, which has a cost if the skill is bloated.
Reach for a skill when: you want the AI to automatically follow a procedure or apply knowledge whenever it’s relevant — your team’s API conventions, a deployment checklist, a “generate this chart” routine that runs a bundled script.
Plugins: a bundle you can share
A plugin is the packaging layer. It doesn’t do anything new by itself — it
wraps up one or more skills, plus optional extras, into a single
installable unit with a name, a version, and a home in a marketplace
A shared catalog people install plugins from, the way an app store works.
You point your tool at a marketplace, browse what’s there, and install with
one command — instead of manually copying files into everyone’s setup.
The reason plugins exist is that they can bundle things a lone skill
can’t: multiple skills at once, custom sub-agents, automated hooks
Rules that fire automatically on an event — for example, “run the linter
every time a file is saved.” They let a plugin enforce behavior instead of
just suggesting it.
MCP servers
A standard way to plug an AI tool into external systems — your database,
your ticketing system, a company API — so it can read and act on real data.
A plugin can ship these connections pre-configured.
Pros
- One install delivers a whole set of capabilities to someone else.
- Versioned and updatable — fix a bug once and everyone gets it.
- Can bundle things skills alone can’t: hooks, external-tool connections, sub-agents.
Cons
- The most overhead by far — a manifest, a structure, and usually a marketplace to distribute through. Overkill for a personal tweak.
- Names get longer, because everything is prefixed to avoid clashes
(
/my-plugin:deployinstead of just/deploy). - You’re installing someone else’s code, so the usual caution applies: only install from sources you trust.
Reach for a plugin when: you want to distribute a set of capabilities — to your team, across many of your own projects, or to the community — or you need to bundle hooks and external-tool connections that a single skill can’t hold.
At a glance
| Command | Skill | Plugin | |
|---|---|---|---|
| What it is | A saved prompt | A capability with a “when to use it” | A shareable bundle of skills + extras |
| Who triggers it | You, by typing /name |
You or the AI, automatically | However its skills are set up |
| Can bundle files/scripts? | No | Yes | Yes |
| Built to share? | Copy the file | Commit to a project | Yes — install from a marketplace |
| Effort to make | Minutes | Moderate | Most |
How to choose
Walk up the ladder, and stop at the first rung that solves your problem:
- Just want a shortcut for a prompt you trigger yourself? A command. Don’t overthink it.
- Want the AI to do it automatically, or need to bundle a script or reference file? A skill.
- Want to hand the whole thing to your team or the public, or bundle hooks and outside-tool connections? A plugin.
The common mistake is starting at the top. You don’t need to build and publish a plugin to save yourself some retyping — that’s a command. And a skill you keep entirely to yourself doesn’t need to become a plugin until the day someone else wants it. In fact, the recommended path is to build a skill in your own folder first, get it working, and then wrap it in a plugin once it’s worth sharing.
The takeaway
Commands, skills, and plugins aren’t three tools competing for the same job — they’re the same idea at three levels of ambition. A prompt you trigger. A capability the AI reaches for on its own. A bundle you give away. Match the rung to the need, start as low as you can, and climb only when the problem actually asks you to.
Related: Build a Reusable AI Assistant — the same “stop re-explaining yourself” instinct, one level down from building a skill.