Four primitives, one recurring confusion. People ask "claude skills vs subagents" like they're picking between two versions of the same feature. They aren't the same feature, and they don't even sit on the same layer. A skill is knowledge. A subagent is a worker with its own context window. A slash command is a typed shortcut, and as of 2026 it is literally a skill. A plugin is the box you ship all of that in. Figure out which layer each one lives on and the choice mostly answers itself.
Think of this as the decision-matrix version of the question. If you want the deep mechanics of any single primitive, the cross-links below go there. My goal here is narrower: get you to the right pick in under a minute. So I'll start with what each one actually is, then hand you a table and a flow you can follow.
The four primitives, in one sentence each
Skills are reusable instructions Claude loads when they are relevant. You write a SKILL.md file with YAML frontmatter and a markdown body, drop it in ~/.claude/skills/<name>/ or a project's .claude/skills/, and Claude adds it to its toolkit. Per the official docs, "a skill's body loads only when it's used, so long reference material costs almost nothing until you need it." That is progressive disclosure: the short description sits in context so Claude knows the skill exists, and the full body loads only on use. Claude invokes a skill automatically when the task matches, or you type /skill-name to run it yourself.
Subagents are specialized assistants that run in a separate context window. The docs describe them as for "a side task [that] would flood your main conversation with search results, logs, or file contents you won't reference again: the subagent does that work in its own context and returns only the summary." Each subagent gets its own system prompt, its own tool access, and its own permissions. You define one in a markdown file under .claude/agents/ (or via the /agents command) with frontmatter that can pin a model like Haiku for cheap, fast work.
Slash commands are the typed shortcuts: /compact, /review, /deploy. The thing most people miss in June 2026 is that custom slash commands no longer exist as a separate concept. Per the skills docs: "Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way." Built-in commands like /help and /compact still run fixed logic. Anything you author is a skill wearing a slash.
Plugins are the distribution wrapper. A plugin is a directory with a .claude-plugin/plugin.json manifest that can bundle skills, subagents (agents/), hooks, MCP servers (.mcp.json), LSP servers, and background monitors. You install one from a marketplace, its skills get namespaced like /my-plugin:hello, and the version field controls when users get updates. Plugins are how a team or community ships a working set of behavior as one versioned unit.
That gives you the answer to "claude code skills vs agents" already. A skill is text Claude reads. An agent (subagent) is a process Claude spawns. One is not a stand-in for the other, and in practice they tend to work together, which is the part the versus framing tends to hide.
The comparison table
| Skill | Subagent | Slash command | Plugin | |
|---|---|---|---|---|
| What it is | Reusable instructions in SKILL.md |
A worker with its own context window | A typed shortcut that runs a skill | A bundle you distribute |
| Where it lives | .claude/skills/<name>/SKILL.md |
.claude/agents/<name>.md |
Same file as the skill it triggers | A dir with .claude-plugin/plugin.json |
| Who triggers it | Claude (auto) or you via /name |
Claude delegates when task matches the description | You type it | N/A (it ships the others) |
| Context | Loads into the current conversation | Separate, isolated context window | Inherits the skill's behavior | N/A |
| State / persistence | Stateless text; reloaded each use | Lives within one session, returns a summary, then is gone | Stateless | Can carry MCP servers, hooks, monitors that hold state |
| Parallelism | None on its own | Yes, multiple run simultaneously in one session | None | Inherits whatever it bundles |
| Distribution | Copy the folder, or check it into a repo | Copy the file (not loaded from --add-dir dirs) |
Ships with its skill | Marketplace install, versioned |
A few cells deserve a footnote. Subagents run in parallel ("spawn multiple subagents to work simultaneously," per the docs), but they cannot spawn other subagents. The Plan agent comment in the docs spells out why: it "prevents infinite nesting (subagents cannot spawn other subagents)." So parallelism is one level deep. For sustained parallel work that outlives a single session, the docs point you to agent teams and background agents instead.
On persistence, the short version is that none of these four are databases. A skill reloads fresh every time you use it. A subagent's context evaporates the moment it hands back its summary. The only durable state in the whole list rides in through a plugin that bundles an MCP server or a background monitor, and that's exactly why "bundle plus state plus MCP" lands on the plugin branch below.
The decision flow
Walk it top to bottom and stop at the first match.
You have repeatable knowledge, a checklist, a procedure, or conventions you keep pasting into chat. That is a skill. The docs are blunt about the trigger: make one "when you keep pasting the same instructions, checklist, or multi-step procedure into chat, or when a section of CLAUDE.md has grown into a procedure rather than a fact." Most of what people reach for is actually this.
Maybe instead you need to spin off a helper for isolated or parallel work, and you would rather its logs and file dumps not clog your main context. That is a subagent. Research three modules at once, run the test suite and get back only the failures, hand a read-only reviewer a locked-down tool set. Separate context window, optional cheaper model, returns a summary.
You just want a one-line shortcut to fire off behavior you already defined. That is a slash command, which means you are writing a skill and invoking it with /name. If the action has side effects you never want Claude to trigger on its own, like a deploy or a Slack send, add disable-model-invocation: true so only you can run it.
Finally, say you want to bundle several of the above, distribute them to a team or the community, version the releases, or ship an MCP server or hooks alongside them. That is a plugin. The plugin docs draw the line cleanly: use standalone .claude/ config for "personal workflows, project-specific customizations, quick experiments," and reach for a plugin when "you want to share functionality with your team or community... version control and easy updates... distributing through a marketplace."
Where the lines actually blur
Two overlaps trip people up.
First, claude skills vs slash commands barely qualifies as a question anymore. Same file, same mechanism. The slash is just the manual trigger for a skill. The one fork that matters is invocation control. Leave a skill model-invocable and Claude runs it when relevant; set disable-model-invocation: true and it becomes a pure /command that only you can fire. If you are still keeping loose files in .claude/commands/, they keep working fine, but I'd write new work as a SKILL.md so you get the supporting-files directory and the frontmatter that comes with it.
Second, claude code skills vs subagents blur because a skill can run as a subagent. Add context: fork to a skill's frontmatter and "the skill content becomes the prompt that drives the subagent." You can also preload skills into a custom subagent as reference material, so the relationship runs both directions. That, more than anything, is why I think the versus question misses the point. Pick the skill when you are packaging knowledge, pick the subagent when you need an isolated worker, and combine them when you need an isolated worker that follows packaged knowledge.
And claude skills vs plugins is a containment story. The plugin holds the skills. A plugin with no skills is mostly hooks and MCP wiring. A skill with no plugin works great for you but gets awkward to share past a cp -r. Once you want versioned, installable, namespaced distribution, you wrap your skills in a plugin. The docs do let you split the difference here: drop a .claude-plugin/plugin.json into a skill folder and it loads as a <name>@skills-dir plugin, so a single skill can bundle agents, hooks, and MCP servers without the full marketplace dance.
The hard part is the skill, not the wrapper
Here's the fact most of this debate steps around. The subagent, the slash, and the plugin are plumbing. The thing that makes any of them worth having is the skill, the actual SKILL.md that encodes how a job gets done well. A subagent with a vague prompt produces vague summaries, and a plugin full of thin skills is just a thin plugin in a nicer box. The payoff comes from writing a skill that captures real procedure: the right description so it loads at the right moment, and the right body so Claude actually follows it once it does.
That writing step is where most people stall. Turning tacit knowledge into a clean SKILL.md is, itself, a skill. Knack exists for exactly that branch of the flow. You answer a roughly 20-minute interview and it produces a shippable Anthropic-format SKILL.md, one you can drop into .claude/skills/, run in Claude Code, Codex, Cursor, or Gemini CLI, and later wrap in a plugin if you want to share it. You stay on the skill branch of the decision tree, which is where most people belong anyway, and you skip the part where you stare at an empty file wondering what the frontmatter wants from you.
Pick one and move
If you remember nothing else: repeatable knowledge is a skill, an isolated or parallel helper is a subagent, a one-line trigger is a slash command pointing at a skill, and a shareable versioned bundle is a plugin. Treat the four as a stack rather than a bracket of competitors. Most days you only ever reach for the bottom layer.
For the mechanics, the deep dives go further than this hub can. Start with how to use skills and SKILL.md vs MCP for the knowledge layer, how to use subagents for the worker layer, slash commands for the trigger layer, and plugins explained for distribution. Pick the layer you are on, build the thing, and stop overthinking which of the four you needed.