Skills, Agents, Commands, Plugins: Which One Do You Actually Need?

There are four ways to extend Claude Code, and they overlap enough that people pick by vibes.

I have roughly eighty skills installed, eleven custom agents, two slash commands and two plugins. That ratio is not an accident, and it took a while to work out why it settles there.

The useful question is not "what can each one do" — the docs cover that. It is what happens to your context window, because that is the actual scarce resource.

The one-line version

• Skill — instructions loaded into your context when relevant
• Agent — a separate context that does work and reports back
• Command — a prompt you trigger by name
• Plugin — a distribution wrapper for the other three

Everything below follows from the first two.

Skills: knowledge you want in the room

A skill is a folder with a SKILL.md describing when it applies. When a task matches, its instructions load into the current conversation.

Key word: current. A skill does not run somewhere else. It changes how the assistant behaves right here, with full access to everything already in the conversation.

That makes skills right for knowledge and standards — the "how we do this" that should shape work you are actively supervising. My collection is heavily weighted to design and SEO for that reason: frontend-design, minimalist-ui, high-end-visual-design, seo-audit, seo-schema, humanizer, investigate.

These are all cases where I want to see and steer the output. If I invoke seo-audit I want the findings in front of me, in context, so I can push back on any of them.

The cost is context. A large skill can be thousands of tokens, and those tokens sit in the window for the rest of the session. Two or three is fine. Ten at once and you have spent a serious fraction of the window on instructions before doing any work.

Agents: work you want done elsewhere

A subagent gets its own context window. It runs, it does the work, and only its final report comes back.

The point is isolation. If an agent reads thirty files to answer a question, those thirty files do not land in your window — you get the conclusion.

Mine are all domain specialists:

wordpress-specialist   nuxt-vue-architect   nuxt-code-reviewer
vuejs-expert           docker-expert
seo-technical  seo-content  seo-schema  seo-sitemap
seo-performance  seo-visual

The pattern: each has a large body of domain knowledge that would be wasteful to keep loaded permanently, and each does work whose intermediate steps I do not need to see.

A code review is the clearest case. To review properly it has to read a lot of code. I want the findings, not the reading. That is exactly the isolation an agent provides.

The trade-off is that an agent cannot see your conversation. It knows only what its prompt tells it. Brief it badly and you get confidently irrelevant work — and unlike a skill, you do not see it going wrong until it is done.

Rule of thumb: if you need to watch it happen, use a skill. If you only need the answer, use an agent.

Commands: a prompt with a name

A slash command is a saved prompt. /optimize runs whatever ~/.claude/commands/optimize.md says.

I have two. That is deliberate — most things that feel like commands are better as skills, because skills load themselves when relevant while commands need you to remember they exist.

Commands earn their place when the trigger is a decision, not a context. /optimize is a thing I choose to do at a moment of my choosing. There is no signal in the conversation that should cause it to fire on its own.

If you find yourself with twenty commands, most of them probably wanted to be skills.

Plugins: distribution, not capability

A plugin bundles skills, agents, commands and hooks into something installable from a marketplace.

It adds no capability. It solves the problem of getting capability onto a machine — yours next month, or a colleague's.

I run two, both third-party. I have never packaged my own, because everything I have built is either project-specific or personal preference. The moment I needed the same setup on three machines, or wanted to hand a team a standard review workflow, that calculus would change.

The decision rule

In order:

1. Does it need its own context? Lots of file reading, or long output you do not want in your window → agent.

2. Does it need to see the conversation? Should shape work in progress, or needs conversation context to be useful → skill.

3. Is it triggered by your decision rather than by context? Nothing in the conversation signals it, you just want it on demand → command.

4. Does it need to exist on more than one machine? → wrap whatever you built in a plugin.

Note these are not exclusive. A plugin can ship a skill that spawns an agent. Start with the smallest thing that works.

Where I get it wrong

Two failure modes, both mine.

Building an agent for something small. A subagent has real overhead — spawn cost, and a briefing that has to carry everything it needs since it cannot see the conversation. For a task with a short answer, the briefing costs more than doing it inline. If the work is one grep, just grep.

Installing skills I never use. Eighty is more than I use. Skills are cheap to install and invisible when idle, so they accumulate. The cost is not runtime — it is that a crowded namespace makes the right one harder to surface, and I have definitely forgotten a skill existed and done the work manually.

The fix for both is the same and unglamorous: review the list occasionally and delete.

Start with none of them

If you are new to this, the honest advice is to use plain Claude Code for a few weeks first.

Every agent and skill I have exists because I did something repeatedly and got tired of re-explaining it. Building extensions before you have that friction means building for problems you have imagined rather than met — and those get abandoned.

Wait for the annoyance. Then build the smallest thing that removes it.

Next: what actually goes inside a domain agent — including why my code reviewer has no write access.