Plugin. Skill. Connector. Three words. Three layers. Constantly confused, including by people selling them.
The confusion costs money. Operators install a plugin expecting a skill. Buy a connector expecting a workflow. Ship a skill that should have been a plugin. The fix is a working mental model, not more docs.
Here is the model I use to scope client builds.
The 3-Layer Model
Skill = the unit. One job, one trigger. A directory with a SKILL.md file. YAML frontmatter at the top tells Claude how it runs. Markdown body tells it what to do. Progressive disclosure: enough to trigger, detail on demand. Skills are the atoms of the stack.
Plugin = the bundle. A plugin packages skills together with slash commands, MCP connectors, and sub-agents. One install, multiple capabilities, all tuned to a workflow or a role. The plugin is the box. The skills are what's inside.
Connector = the bridge. An MCP connector exposes an external tool (Gmail, Drive, ClickUp, Slack, Asana, Notion) to Claude as a callable surface. The connector does not decide what to do. It makes "what to do" possible. Skills decide. Connectors enable.
Skills run jobs. Plugins bundle skills. Connectors give skills hands.
The Anthropic Receipt
The plugin model launched Jan 30 2026 with 11 plugins. Anthropic shipped 10 more on Feb 24. Vertical bundles followed in May: a Legal plugin set on May 12, a Marketing Ops set on May 18. The marketplace lives at claude.com/plugins, and the open-source reference repo is at github.com/anthropics/knowledge-work-plugins.
Agent Skills became an open standard in December 2025. The spec lives at agentskills.io. Same skill format runs in Cowork, Claude Code, and the Anthropic API. That portability is the strategic story. A skill you write today does not lock you to a surface.
When A Plugin Is The Right Answer
You buy a plugin when three things are true.
The role is generic. Legal review. Marketing ops. Sales prospecting. A role thousands of operators share. The plugin captures the 80% pattern. You tune the last 20% locally.
The bundle saves you setup time. A plugin gives you the skills, the slash commands, the connectors, and the sub-agents in one install. Reproducing it skill by skill is days of work. The plugin is hours.
You will run the /customize step. This is the one nobody runs and it is where the ROI lives. A plugin installs with generic prompts. /customize takes 15 minutes and rewrites them to your business, your voice, your data. Skip /customize and you have a generic assistant. Run it and you have a tuned one.
The Legal plugin is the cleanest example. Install it cold and it produces generic contract review. Run /customize with your firm's preferred markup style, your jurisdiction, your standard redlines, and the same plugin becomes a junior associate who knows the house rules. Same code. Wildly different output.
When A Custom Skill Beats A Plugin
Three signals point to custom over off-the-shelf.
The job is yours, not a category. The way you write client briefs. The format of your weekly status update. The structure of your audit deliverables. There is no plugin for this because there is no category for this. Write the skill yourself using Anthropic's skill-creator as the on-ramp. Skill-creator handles the syntax in about 90 minutes. The trigger phrasing, the failure modes, the data contracts the skill depends on, the rollback when it produces a bad artifact, those still need an engineer to define before you ship the skill into a workflow you actually rely on.
The trigger is specific. Generic plugins trigger on broad descriptions. A custom skill triggers on your exact phrasing. "Run callsheet" "draft my Monday client digest" "prep me for the Power4 call." The narrower the trigger, the more reliable the load. Progressive disclosure rewards precision.
Your SOPs already exist. Every documented process you run is a skill in waiting. The SOP is the body. The trigger is the frontmatter. Conversion takes an afternoon. If you have 12 SOPs and 0 skills, that is 12 free skills you are not running.
The owner-operator pattern I see across client builds: 5 to 8 custom skills covering the core daily loop (briefing, prep, triage, debrief, wrap), 2 to 3 installed plugins covering specialised role work, and 4 to 8 connectors wiring it all to the actual data.
Where MCP Connectors Fit
Connectors are the layer that makes everything else useful. A skill that cannot reach your Gmail is a journal entry. A plugin that cannot read your ClickUp is a demo.
Cowork ships with 38+ native connectors. Gmail, Calendar, Drive, Slack, Notion, Asana, ClickUp, Linear, GitHub, Jira. Coverage for most knowledge-work stacks. Where native coverage stops, Zapier MCP is the standard escape hatch. One connector, thousands of tools downstream, no custom integration code.
The trap with connectors is bloat. Every active MCP server consumes context every turn. An over-installed Cowork can burn 18,000+ tokens per turn just announcing what tools exist. The fix is the same as it is for skills: only enable what the current project actually uses. Per-project connector scoping cuts cost without cutting capability.
/customize: The Step Everyone Skips
This is the wedge. The single highest-ROI action in the entire stack, and almost nobody runs it.
Every plugin installs with generic system prompts. Generic voice. Generic data assumptions. Generic output format. It works. It works badly. It works the same as it does for every other person who installed it.
The /customize command opens an interview. The plugin walks you through what it needs to know about you, your business, your data, your voice, and your output preferences. You answer once. The plugin rewrites its own prompts. The next time it runs, the output sounds like you, references your actual data, and lands in your preferred format.
Run /customize on every plugin within an hour of install. Re-run it monthly as the business changes. Clients who skip /customize file complaints. Clients who run it ask what to install next.
Same plugin. Different operator. 10x output gap. That is what /customize is worth.
The /customize step is where the ROI lives, and it is where every plugin install fails. Most users skip it because they do not know what to tune. Knowing what to tune means knowing your data model, your voice rules, your output contract with the next person in the chain. That is the gap between installing a plugin and shipping one.
The rule: if you installed a plugin and you have not run /customize, you do not have a tuned tool. You have a generic one. Block 30 minutes this week, run /customize on everything installed, and the same stack will produce 2x the output by Friday.
How To Decide Which Layer To Buy Or Build
The decision flow is short.
Job is a category role (legal, marketing, sales prospecting)? Install a plugin. Run /customize. Done.
Job is specific to your business (your brief format, your client digest, your audit doc)? Write a custom skill. Use skill-creator as the on-ramp. 90 minutes, not a week.
Job needs to reach an external tool? Add a connector. Native if available, Zapier MCP if not. Scope it per-project so it does not bloat every conversation.
Job repeats across 3+ skills inside one workflow? Bundle them into your own plugin. The plugin format is open. Your library becomes a portable productized asset.
Skills run jobs. Plugins bundle skills. Connectors give skills hands. Customize is what makes any of it land. Get the layers right and the stack pays for itself before the first month ends.
Most teams figure this out by hitting it. Install a plugin, skip /customize, ship a generic skill into a workflow that has nuance the skill never asked about, watch the artifact drift for two weeks before someone notices. You can also bring in someone who has already hit it.
Want this running on your ops? Book a free 45-min ops mapping call. We'll audit your stack, find the bottlenecks, and show you where Cowork moves the needle. cal.com/formaum/45
Run on a stack that's holding you back?
Book a 45-minute discovery call. I'll map what moves, what stays, and what makes sense for your operation.
Book a call