Plugins

Status: 🟩 COMPLETE (🟦 LIVING) Last updated: 2026-06-19 Plain-English tagline: A bundle of skills, subagents, slash commands, hooks, and MCP server definitions, installable as a single unit. Don’t reinvent — install what someone else built.

In plain English

When you customize Claude Code, you write skills, configure hooks, install MCP servers, sometimes define subagents. That’s all good — but if you do it for every project, you’ll repeat yourself, and other people will repeat themselves writing the same things.

A plugin is a packaged collection of those customizations. One folder, one install command, and you get all the included skills, subagents, commands, hooks, and MCP integrations at once.

Plugins are how teams share Claude Code setups, how communities distribute integrations, and how the ecosystem composes. Public plugin marketplaces (like tonsofskills.com) host hundreds of plugins for specific stacks: a “Next.js + Supabase” plugin, a “React Native” plugin, a “data science” plugin, etc.

Your current Cowork session shows two plugins in use (cowork-plugin-management and anthropic-skills), each bundling many skills you can invoke directly.

Why it matters

Three reasons:

Composability. A plugin is the unit of reuse. Instead of N developers each writing their own /deploy skill, one plugin defines it once and all N install it.
Discoverability. Marketplaces let you browse what exists. “There’s probably a plugin for X” is true much more often than you’d think.
Versioning. Plugins are versioned, so you can rely on stable behavior. When the plugin updates, you opt in to upgrade.

For solo developers, the value is “use what already exists” instead of writing everything from scratch. For teams, the value is “the whole team has the same Claude Code setup.”

What a plugin can contain

A plugin can bundle any of these:

Component	What it is
Skills	Markdown files that define slash commands and behaviors
Subagents	Custom agent types with specialized prompts and tool restrictions
Slash commands (legacy form)	`.claude/commands/<name>.md` — still works
Hooks	Event-driven shell commands
Output styles	Templates for how Claude formats responses
MCP server definitions	Pre-wired MCP server configs

You don’t have to ship all of these. Many plugins ship just skills. Some ship just an MCP server with a thin skill wrapper. The category combinations are flexible.

Installing a plugin

Two main mechanisms:

From a marketplace

# Browse and install via a plugin manager
ccpi install nextjs-supabase-toolkit

(Where ccpi is the Claude Code package installer — analogous to npm. Your mileage may vary by which marketplace you use.)

Directly from a git repo

claude plugin add https://github.com/user/my-claude-plugin

Most plugins live as git repos with a known structure. Adding one clones it into ~/.claude/plugins/<name>/ and registers it.

Manually

Plugins are folders. You can copy a plugin folder into your ~/.claude/plugins/ directory and Claude Code will pick it up next session. Useful for plugins you’ve written or modified locally.

How a plugin is structured

A typical plugin folder looks like:

my-plugin/
├── manifest.json                  Metadata: name, version, description, author
├── skills/
│   ├── deploy/
│   │   └── SKILL.md
│   ├── verify/
│   │   └── SKILL.md
│   └── lint-fix/
│       └── SKILL.md
├── agents/
│   ├── reviewer.md
│   └── explorer.md
├── hooks/
│   └── hooks.json                 Hook definitions
├── mcp/
│   └── servers.json               MCP server configs
└── README.md

Each subfolder corresponds to one of the primitive types. Claude Code reads manifest.json for metadata and discovers components from the convention.

What you have right now (in the Cowork session)

Your current session shows plugins providing:

From cowork-plugin-management:

cowork-plugin-customizer — customize a plugin for a specific organization
create-cowork-plugin — guide through creating a new plugin

From anthropic-skills:

algorithmic-art — generative art via p5.js
brand-guidelines — apply Anthropic brand colors and typography
canvas-design — create visual art posters, designs
consolidate-memory — reflective pass over memory files
docx — Word document creation and editing
internal-comms — write internal communications
mcp-builder — scaffold MCP servers
pdf — PDF read/write/manipulation
pptx — slide decks
schedule — scheduled tasks
setup-cowork — guided Cowork setup
skill-creator — create new skills, edit existing
slack-gif-creator — animated GIFs for Slack
theme-factory — preset themes for artifacts
web-artifacts-builder — complex multi-component HTML artifacts
xlsx — spreadsheets

Plus various other user-invocable skills like update-config, keybindings-help, verify, code-review, simplify, fewer-permission-prompts, loop, schedule, claude-api, run, init, review, security-review.

That’s a substantial baseline of capability provided by plugins, not by you writing skills.

Writing your own plugin

When you have a set of skills that work well together, packaging them as a plugin makes them shareable.

The create-cowork-plugin skill walks you through creating a new plugin from scratch — /cowork-plugin-management:create-cowork-plugin.

The basics:

Create the folder structure (manifest, skills/, etc.)
Write the skills as you would for personal use
Write a README explaining what it does
Optionally include hooks, subagents, MCP configs
Publish — to a marketplace, to GitHub, to internal infrastructure

For an organization’s internal plugin (tailored to your stack and tools), the cowork-plugin-customizer skill (/cowork-plugin-management:cowork-plugin-customizer) helps tune a plugin for specific conventions.

Plugin marketplaces and ecosystem

As of mid-2026, several marketplaces exist:

tonsofskills.com — community marketplace with ~425 plugins, 2,810 skills, 200 agents
The official Anthropic plugin directory — curated official plugins
GitHub — direct from repos
Internal/private marketplaces — companies hosting their own

Quality varies. Read sources for sensitive plugins; vet them like you would any third-party code. Official plugins from Anthropic are well-vetted; community plugins range from excellent to abandoned.

Plugins vs skills vs MCP servers — the relationship

It’s a stack:

Skills are the atom — a single bit of teachable behavior.
Subagents are specialized agent definitions.
Hooks are deterministic shell-script automation.
MCP servers are external tool exposers.
Plugins bundle any combination of the above into a unit.

You can use the lower levels without plugins. Plugins are just for distribution.

For your own use across one project: write skills/hooks directly. For your use across all projects: put them in ~/.claude/. For sharing across teams or making them public: package as a plugin.

Common gotchas

Plugin quality varies wildly. Pin to known versions. Re-read the source after updates.
Skills can conflict. Two plugins with a skill named deploy cause confusion. The newer / higher-priority one wins, but it may not be what you expected. Use namespaced commands (/plugin:skill) to be explicit.
MCP server configs in plugins may want permissions you don’t grant. Read what the plugin’s MCP servers do before installing.
Hook collisions. Two plugins both registering a Stop hook → both fire. Usually fine, but order isn’t always predictable.
Plugins can be heavy. Hundreds of skills means hundreds of files to scan. For most users this is fine; for very large plugin counts, performance degrades.
Updating plugins can break things. A plugin update might change a skill’s behavior. For mission-critical workflows, pin to a specific version.
Plugins aren’t sandboxed. They run with your full Claude Code permissions. Treat them as trusted code.
Cross-platform issues. A plugin assuming Bash on Linux may not work on Windows. Test before relying.
Plugin discovery. Knowing what’s available is half the battle. Browse marketplaces periodically.

Tech & AI, Explained

Explorer

plugins