The most common question I get about the Claude ecosystem right now is some version of "what is the difference between a Skill and a Plugin, and which one do I need?" It sounds like a terminology quibble. It is actually the decision that determines whether your AI automation stays a pile of clever one-off tricks or becomes something that runs a whole job function. I build and ship both — my own machine currently has two dozen plugins installed across several marketplaces, and packaging skills is part of what I sell — so this is the practitioner's version of the answer, including the parts where plugins are oversold.
When Anthropic brought plugins to Cowork, I initially assumed they were Skills with better packaging. That assumption is exactly wrong, and the gap between what I assumed and what plugins actually are is the useful content of this post.
Where Skills hit a wall
A Skill is a single-task capability: a set of instructions (and optionally scripts and resources) that loads when a matching task shows up. Branded invoice generation. SOP writing. A design review checklist. For isolated, repeatable tasks, Skills are close to perfect, and I have written at length about building them properly.
The wall is that real work is not a series of isolated tasks. Marketing is not "write one email" — it is a welcome sequence, then a landing page, then atomized social posts, then a nurture flow, each needing context from the last. Individually excellent Skills do not share that context by themselves. Run them separately and you become the glue: copying outputs forward, re-explaining the campaign to every new session, bridging gaps a coordinator should bridge.
I lived this. My skill collection grew to dozens of well-crafted single-purpose tools, and my actual role degraded into human middleware between them. That is the specific pain plugins exist to remove.
What a plugin actually is
A Cowork plugin bundles skills, connectors, slash commands, and sub-agents into one installable package with shared context. The kitchen analogy holds up: a Skill is a recipe card for one dish; a plugin is a chef running the whole service — knows every recipe, has access to the equipment, and coordinates timing across courses.
| Aspect | Skill | Plugin |
|---|---|---|
| Scope | Single task | Entire job function |
| Context | Isolated | Shared across bundled skills |
| Contains | Instructions (+ scripts/resources) | Skills + connectors + commands + sub-agents |
| Best for | Repeatable individual tasks | Multi-step workflows with handoffs |
Here is the part I can add because I ship these things: a plugin is not magic infrastructure — it is a directory. Crack one open (they sit on disk once installed) and you find a .claude-plugin/plugin.json manifest, a commands/ folder of slash commands, a skills/ folder, and optionally hooks/ for lifecycle behavior. Anthropic open-sourced its Cowork plugin collection at anthropics/knowledge-work-plugins, so you can read exactly what the marketing or finance plugin does before trusting it with your accounts — and this is the same plugin format Claude Code uses, which is why my daily plugin workflow transfers between the two products. Knowing that plugins are inspectable files, not sealed apps, changes your relationship with them: you can audit them, fork them, and strip the parts you do not want.
The official library covers the common knowledge-work functions — sales, finance, legal, marketing, support, product, data analysis, research — plus Plugin Create, a plugin whose job is building custom plugins. Installation is genuinely a ninety-second affair: browse, install, then enable the plugin in a conversation. The step people skip, and should not, is opening the plugin's management panel first to see which skills, commands, and connectors it actually bundles. Precise requests to a plugin you understand beat vague requests to a black box, every time.
The test that made the difference concrete
To evaluate the marketing plugin honestly, I gave it a full job rather than a toy prompt: a complete welcome email sequence for a new product signup flow. What came back was not seven emails — it was a campaign. A structured sequence across two weeks, each email with a distinct strategic slot: quick-win welcome, value delivery, personal connection, free-to-paid bridge, social proof, the pitch, the follow-through. Subject lines, preview text, body copy, and — the tell — a rationale for why each email sat where it sat.
The plugin-versus-skill difference showed up in the details a single Skill cannot produce: the tone stayed consistent across all seven emails, email five called back to a story opened in email two, and the pitch referenced the value delivered earlier in the sequence. Skills write artifacts. Plugins write artifacts that know about each other. That is what shared context buys, and once you have seen it, going back to stitching outputs together by hand feels like a downgrade.
Connectors extend this from "coordinated documents" to "coordinated actions" — the plugin reaching into Slack, Notion, cloud data warehouses, or your email platform to read real data and push real output. My honest status report on connectors: the ones I lean on regularly have been reliable, but the ecosystem is uneven and newer connectors deserve a low-stakes trial before you wire them into anything that touches customers. Treat connector claims the way you treat any integration claim: verified per connector, not per marketing page.
Customization is the actual leverage
Every Cowork plugin can be modified by asking Claude to modify it — because, again, a plugin is files, and Claude is good at editing files. When the marketing plugin lacked a capability I use constantly (atomizing one long-form piece into LinkedIn posts, newsletter segments, and a thread outline), I described the missing skill in plain language and had it added to the plugin. No config ceremony. The customized plugin then did the atomization with the campaign's shared context — so the LinkedIn posts and the email teaser stayed consistent with the sequence the plugin had already written.
This is where I would focus if you only have an hour: do not evaluate plugins on their stock behavior. Evaluate them on how quickly you can bend one to your actual workflow. Stock plugins are someone's generic model of "marketing." Ten minutes of customization makes them a model of your marketing, and the compounding starts there.
The honest limits
Three things the plugin enthusiasm skips.
Plugins have a context cost. Every installed plugin advertises its skills and commands to the session. Install everything and you pay for that surface area in attention and tokens before any work happens. My rule, learned by pruning my own over-stuffed setup: install for the functions you run weekly, uninstall aspirational ones. The skills-loading mechanics explain why lean beats comprehensive here.
A single Skill is still the right tool surprisingly often. If the task is genuinely isolated — generate this invoice, review this document — a plugin adds coordination machinery with nothing to coordinate. The maturity path I recommend and follow: build the Skill first; promote to a plugin only when you catch yourself manually ferrying context between skills. The pain arrives before the plugin should.
Plugins do not replace judgment about the work itself. My welcome sequence was structurally excellent because email marketing has well-established structure for the plugin to encode. Functions with weaker playbooks get weaker plugins. The plugin encodes practice; it does not invent strategy. Which product you even run this in matters too — I broke down where Cowork ends and Claude Code begins in Cowork versus Claude Code, and the short version is that plugins make Cowork viable for exactly the non-developer workflows this post describes.
Where this lands
The distinction, compressed: Skills are capabilities, plugins are coordination. Skills made Claude good at tasks; plugins make it useful at job functions, because the bundled skills share context and the connectors touch real systems. The confusion between the two persists because both get demoed on single tasks — where they look identical. Give them a workflow with handoffs and they stop looking identical immediately.
The capability layer under all of this is the part I keep public: the skills I have built and refined for my own operations — content, SEO, automation, review workflows — sit in my agent skills marketplace, packaged for the same plugin architecture this post just took apart. Open one and read its files before you enable it; that habit is worth more than any install list.
