Module 6: Subagents: delegating work to specialized agents

Plugin Marketplace: installing capabilities instead of building them

Overview

So far you've learned to build capabilities for Claude Code: skills (Module 05), hooks (Module 05), built-in subagents (capsule 02), and custom subagents (capsule 03). Building from scratch gives you full control and teaches you how the system works. But it also takes time. There are common tasks — code review, test generation, security analysis, tool integrations — that somebody already solved and published.

That's what the plugin marketplace is for: an official catalog of plugins you can install with a single command. A plugin is a reusable bundle that can combine skills, hooks, custom subagents, and MCP servers into one package. Instead of writing a /code-review skill, you install a plugin that already ships one with a workflow battle-tested by thousands of developers.

This capsule covers what the plugin marketplace is, the /plugin command, how to install and manage plugins, criteria for deciding between installing and building, and security considerations. It isn't a review of specific plugins — the catalog changes weekly — but the mental model and the workflows for joining the ecosystem without losing control.

Where you are in the guide

Module 01: What Claude Code is ✅
Module 02: Installation and setup ✅
Module 03: CLAUDE.md and memory ✅
Module 04: Agentic workflow ✅
Module 05: Skills and Hooks ✅
Module 06: Subagents
  ├── 01: Introduction ✅
  ├── 02: Built-in subagents ✅
  ├── 03: Custom subagents ✅
  ├── 04: Plugin marketplace ← YOU ARE HERE
  └── 05: Introduction to Agent Teams
Module 07: Integrations (Git, SDK, Remote Control)
Module 08: Capstone project

The three previous capsules were about building your own capabilities. This capsule closes the loop: how to take advantage of what the community already built. Capsule 05 will take you to the frontier (Agent Teams).

What a plugin is

A plugin is a reusable bundle that packages one or more Claude Code capabilities:

┌────────────────────────────────────────────────┐
│            A PLUGIN CAN INCLUDE                │
│                                                │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐    │
│  │  Skills  │   │  Hooks   │   │ Subagents│    │
│  │  (slash  │   │ (events) │   │  custom  │    │
│  │ commands)│   │          │   │          │    │
│  └──────────┘   └──────────┘   └──────────┘    │
│                                                │
│  ┌──────────────────┐   ┌──────────────────┐   │
│  │    MCP servers   │   │    Settings      │   │
│  │  (integrations)  │   │   (defaults)     │   │
│  └──────────────────┘   └──────────────────┘   │
│                                                │
└────────────────────────────────────────────────┘

What sets a plugin apart from installing the pieces separately:

Coherence: The pieces are designed to work together. A "test generation" plugin ships the /gen-tests skill, a hook that runs the tests on save, and a subagent that analyzes coverage. All three pieces are tuned to each other.
Versioning: The plugin updates as a unit. You don't have to maintain skills, hooks, and subagents separately by hand.
Distribution: One command installs everything. One change updates everything. One command uninstalls it.

Plugin vs the previous capsules

Mechanism	Origin	Scope
Built-in subagent (capsule 02)	Anthropic, ships with Claude Code	Universal
Custom subagent (capsule 03)	You write it in `.claude/agents/`	Your project
Skill (Module 05)	You write it in `.claude/skills/`	Your project
Plugin (this capsule)	Community or Anthropic, installed from a marketplace	Your project, your user, or your team

Plugin = "somebody already built the subagent/skill/hook you need, bundled it, and distributed it".

The official plugin marketplace

Anthropic maintains an official marketplace of curated plugins: the public anthropics/claude-plugins-official repository. As of March 2026 it hosts more than 100 plugins, and it grows every week.

The marketplace is built into Claude Code — you don't need to open an external site or clone repositories by hand.

How to get to it

From a Claude Code session:

> /plugin

That opens the marketplace's interactive interface, with tabs:

Discover: browse plugins by category, search by name, see the most installed
Installed: see your active plugins, configure them, update them, uninstall them
Marketplaces: manage plugin sources (official + alternatives)

Example: exploring Discover

> /plugin

[Tabs: Discover | Installed | Marketplaces]

DISCOVER
─────────
Categories:
  📝 Code review            (12 plugins)
  🧪 Testing                (15 plugins)
  🔒 Security               (8 plugins)
  📚 Documentation          (10 plugins)
  🚀 Deployment             (7 plugins)
  🔍 Code analysis          (14 plugins)
  ⚙️  DevOps               (11 plugins)
  🎨 Frontend               (9 plugins)
  🗄️  Backend               (13 plugins)
  ...

[Search: ___________]   [Filter by: ⭐ Most popular ▼]

You navigate with the arrow keys, press Enter to see a plugin's details (description, author, version, what it includes, usage examples, link to the repo). From there you install it with one Enter.

The installation workflow

1. /plugin → Discover
2. You find the plugin you need (e.g. "code-review-pro")
3. Enter to see the details
4. Enter on "Install"
5. Claude Code downloads the plugin, registers it, and reports which pieces it includes
6. Done: the new slash commands, hooks, and subagents are available

No session restart required. The plugin's slash commands show up in /help immediately.

Example: installing a code review plugin

Step 1: discover

> /plugin

[Discover → Code review]

⭐ code-review-pro                   v2.4.1   ★ 8.2k installs
   Comprehensive code review with security, performance, and 
   maintainability checks. Includes /review, /security-audit, 
   and a custom subagent.

   📦 Includes:
      • Skill: /review (general code review)
      • Skill: /security-audit (OWASP-style security check)
      • Subagent: code-reviewer (deep dive)
      • Hook: PreToolUse on Write (lint warnings)

Step 2: install

> [Enter on "Install"]

✓ Downloaded code-review-pro v2.4.1
✓ Registered 2 skills: /review, /security-audit
✓ Registered 1 subagent: code-reviewer
✓ Registered 1 hook: PreToolUse on Write
✓ Plugin enabled in current project

Available now in /help and /agents.

Step 3: use it

> /review src/auth/login.py

[the code-review-pro skill runs]
[Output: a structured review with 3 issues found,
 categorized by severity]

> /security-audit src/

[the code-review-pro skill runs in security mode]
[Output: OWASP analysis with findings and recommendations]

Step 4: uninstall (if you decide you don't need it)

> /plugin → Installed → code-review-pro → Uninstall

✓ Removed plugin code-review-pro
✓ Unregistered 2 skills, 1 subagent, 1 hook

Total time: 2-3 minutes to install, evaluate, and decide whether it's useful to you.

When to install a plugin vs build your own

Not everything deserves to be a community plugin. There are cases where building your own is better.

Install a plugin when…

✅ The task is generic (code review, test generation, formatting)
✅ There's a plugin with a solid reputation (★ 1k+ installs, known author)
✅ You want to validate the idea fast before building your own
✅ The plugin handles a well-solved, standardized use case
✅ It saves you hours of manual configuration

Build your own skill/subagent when…

❌ The task is specific to your project (internal conventions, unique domain)
❌ You need fine-grained control over every step of the workflow
❌ The available plugin doesn't fit and you'd have to override almost all of it
❌ The logic involves secrets, sensitive data, or internal compliance
❌ There's no plugin that covers exactly what you need

The hybrid pattern: install + extend

The most common setup in mature projects: install plugins that cover 80% of the case, and build 1-2 custom skills that cover the 20% that's specific to your project.

.claude/
├── agents/
│   └── domain-validator.md       (custom: your business domain)
├── skills/
│   └── company-style-check/      (custom: your conventions)
└── settings.json
    └── enabledPlugins:
        ├── code-review-pro       (from the marketplace)
        ├── test-generator-pro    (from the marketplace)
        └── security-audit-base   (from the marketplace)

Marketplace for the generic, custom for the specific.

Alternative marketplaces

Anthropic's official marketplace is the starting point, but there are community-curated alternatives. You can register them as extra sources:

Known marketplaces (May 2026)

Marketplace	Characteristic	URL
anthropics/claude-plugins-official	Curated by Anthropic, quality guaranteed	(built-in)
claude.com/plugins	Browsable web catalog of the official ones	claude.com/plugins
buildwithclaude.com	Community marketplace, 500+ plugins	buildwithclaude.com
claudemarketplaces.com	Directory of marketplaces and plugins	claudemarketplaces.com
awesome-claude-plugins	Curated list on GitHub	github.com/Chat2AnyLLM/awesome-claude-plugins

Adding an alternative marketplace

> /plugin → Marketplaces → Add new

Marketplace URL: https://buildwithclaude.com/registry.json
Name: Build with Claude

✓ Marketplace added. 547 plugins available from this source.

Recommendation

Start with the official marketplace. It's the safest and its plugins are reviewed. Only add alternative marketplaces when you have use cases the official one doesn't cover and you understand the risk of installing third-party code.

Security: what to weigh before installing

A plugin can bring hooks that run commands on your machine, MCP servers that connect to external networks, and subagents with write permissions. Don't install plugins you don't understand.

Checklist before installing

□ Is the plugin from the official marketplace?
   → Yes: high trust, it already passed Anthropic's review
   → No: read the source code before installing

□ How many installs does it have? What does the community say?
   → 1k+ installs and positive reviews: a solid signal
   → < 100 installs and an unknown author: caution

□ What hooks does it include? What events do they cover?
   → Hooks on PreToolUse Bash can intercept arbitrary commands
   → Hooks on PostToolUse Write can modify your files without you seeing it

□ What MCP servers does it include?
   → MCP servers connect to external services
   → Check what tokens or credentials it asks for

□ Does the plugin ask for elevated permissions?
   → If it asks for unrestricted Bash, weigh the risk
   → If it asks for access to your home directory, same

Convention: review before approving

When you install a plugin, Claude Code shows you which pieces it includes and which permissions it requires. Read that list. If there's something you don't understand, don't approve — open the plugin's source (link to the repo) and check what it does.

Plugins in team projects

If you're going to enable a plugin for the whole team (through a .claude/settings.json committed to the repo), run it through the normal PR review flow. Have a teammate verify what the plugin does before merging the change.

Common patterns

Pattern 1: A minimal starting stack

When you start a new project, install 3-4 core plugins and add more only when you need them:

Core plugins to start with (common examples):
  • code-review-pro          → /review on PRs
  • test-generator-pro       → /gen-tests for new logic
  • security-audit-base      → periodic /security-audit
  • doc-generator            → /gen-docs for public modules

Resist the temptation to install 20 plugins "just in case". Every plugin adds slash commands to the autocomplete and hooks to the lifecycle — too many and it gets noisy.

Pattern 2: Plugin + your own extension

Install a plugin as the base, then create a custom skill that extends it for your project:

1. Install code-review-pro (generic review)
2. Create .claude/skills/review-our-style/SKILL.md
   description: "Code review following OUR company's conventions"
   content: "First run /review, then add checks for:
            - naming in Spanish
            - relative vs absolute imports per our convention
            - error messages in {code}:{message} format"

The plugin does the heavy lifting. Your skill personalizes it for your context.

Pattern 3: Plugins per team, custom per developer

.claude/settings.json (committed, team)
└── enabledPlugins: [...]   # plugins the whole team uses

~/.claude/settings.json (personal, not committed)
└── enabledPlugins: [...]   # plugins only you use

.claude/skills/ (committed, team)
└── ...                      # team conventions

~/.claude/skills/ (personal, not committed)
└── ...                      # your personal preferences

The team shares the core plugins. Each developer adds their own personal ones.

Pattern 4: Periodic audit

Every 1-2 months, review the plugins you have installed:

> /plugin → Installed

For each plugin:
- Did you use it in the last 30 days?
   → No: candidate for uninstalling
- Is there an update available?
   → Yes: read the changelog before updating
- Is the plugin still maintained?
   → If it's gone 6 months without updates, look for an alternative

An active marketplace evolves — so do the plugins.

Pitfalls and edge cases

Pitfall 1: blindly trusting the install count

A plugin with 5k installs isn't necessarily safe. It can be popular but outdated, abandoned, or carrying a recent vulnerability. Check the date of the last commit and the changelog before installing.

Pitfall 2: conflicts between plugins

Two plugins can define the same slash command. For instance, code-review-pro and simple-reviewer may both register /review. When you install the second one, Claude Code warns you and asks you to choose which takes precedence.

⚠️  Slash command conflict: /review

  - code-review-pro v2.4.1 (already installed)
  - simple-reviewer v0.8.0 (about to install)

  Choose precedence:
  [1] Keep code-review-pro
  [2] Override with simple-reviewer
  [3] Cancel install

Resolve the conflict right then; don't leave the system in an ambiguous state.

Pitfall 3: hooks that slow your session down

Plugins with heavy hooks (e.g. running the full test suite on every Write) can make every Claude Code action sluggish. If you notice performance degradation after installing a plugin, review its hooks and consider disabling them individually.

Pitfall 4: updating without reading the changelog

An update can change the behavior of a slash command your team has already internalized. Before updating, read the plugin's changelog. If the bump is major (e.g. v2.x → v3.0), check for breaking changes.

Pitfall 5: installing plugins from outside the official marketplace without reviewing them

Claude Code's MCP/plugin ecosystem is growing fast and it attracts opportunists. A plugin from someone's personal GitHub repository with 3 commits doesn't deserve the same trust as an official plugin. Read the code before installing from uncurated sources.

Complete worked example

Scenario: a full setup for a new Python project

You're starting a FastAPI project. You want a quality workflow without writing 5 custom skills on day 1.

Day 1 — Initial setup with plugins
──────────────────────────────────

> claude

> /plugin → Discover → "fastapi"

Plugins found:
  ⭐ fastapi-helper       v1.2.0   ★ 3.1k installs
     /endpoint, /pydantic-model, validation hook

  ⭐ pytest-pro           v4.0.1   ★ 7.5k installs
     /gen-tests, /coverage, test-debugger subagent

  ⭐ security-audit-base  v1.5.2   ★ 5.4k installs
     /security-audit with OWASP, PreCommit hook

> [Install fastapi-helper]
> [Install pytest-pro]
> [Install security-audit-base]

✓ 3 plugins installed
✓ 7 new slash commands available
✓ 2 new subagents available
✓ 3 hooks active

Once installed, you can already work with the full workflow:

> "Create a POST /api/users endpoint that validates email and password"

Claude Code:
  → Uses /endpoint from the fastapi-helper plugin
  → Generates the endpoint with Pydantic validation (auto-detected)
  → The PreCommit hook runs /security-audit on the new code
  → Suggests /gen-tests to cover the endpoint

> /gen-tests src/api/users.py

  → Generates tests with pytest following the plugin's pattern
  → The test-debugger subagent verifies the tests pass

Without building anything custom, you already have a professional workflow.

Day 30 — Evolving with custom skills
─────────────────────────────────────

After a month you notice you repeat two things:
  1. Every new endpoint needs structured logging in JSON format
  2. Pydantic models must inherit from your custom BaseModel

Those are patterns SPECIFIC to your project. You create custom skills:

.claude/skills/endpoint-with-logging/SKILL.md
.claude/skills/our-pydantic-model/SKILL.md

Now Claude uses the plugins for the generic (endpoint structure)
and your skills for the specific (your logging and your BaseModel).

Plugins + custom is the winning pattern.

Practice exercises

Exercise 1: explore the marketplace

Open Claude Code in any project and run:

> /plugin

Browse Discover. Filter by a category that interests you (testing, security, deployment, etc.).

What to observe

Identify:

How many plugins are in that category
Which are the 3 most installed
What each one includes (skills, hooks, subagents, MCP servers)

Don't install anything yet. Just get familiar with the catalog and the information available per plugin.

Exercise 2: install and uninstall

Pick a plugin from the official marketplace (e.g. one from utilities or productivity). Install it:

> /plugin → Discover → [you select a plugin] → Install

Verify:

Which new slash commands show up in /help
If it brought subagents, they appear in /agents
If it brought hooks, which events they cover

Then uninstall it:

> /plugin → Installed → [the plugin] → Uninstall

Verify that the slash commands, subagents, and hooks are gone.

What to learn

The install/uninstall cycle is 100% reversible. That means you can try plugins freely — if one isn't useful, you uninstall it. No long-term commitment.

Exercise 3: compare a plugin against building the equivalent

Find a plugin that includes a skill you could build yourself (e.g. a code review skill).

1. Read the plugin's SKILL.md content (in its repo)
2. Estimate how long it would take you to build something equivalent from scratch
3. Compare the quality of the plugin's skill with what you would have written

What to evaluate

Does the plugin handle cases you wouldn't have thought of? (edge cases, output formats, configurability)
Does it follow conventions your team respects, or contradict them?
Does the quality difference justify the hours you save?

Sometimes it's worth installing even if you could build it, because the plugin has already been tuned by thousands of users. Other times your own skill — simpler and more specific — is better.

Exercise 4: a minimal stack for your project

For a real project of yours, define a minimal stack of 3 plugins:

1. What task do you repeat most often that a plugin could cover?
2. Is there a plugin in the official marketplace that covers it well?
3. Repeat until you have 3 plugins identified (no more).

Install the 3, use them for a week, and at the end evaluate which ones you keep.

Reflection

After the week:

Which one did you use most?
Which one did you barely use? (candidate for uninstalling)
Which one made you wish you could change something about its behavior? (candidate for a custom skill that extends the plugin)

Exercise 5: security audit

Pick a plugin that is NOT from the official marketplace (from an alternative marketplace or a public GitHub repository).

Before installing it, check:

Who the author is (GitHub profile, other projects)
When the last commit was
What hooks it includes and what they do
What MCP servers it includes and which services they connect to
What permissions it asks for

An informed decision

After reviewing, decide:

Would you install it on your personal machine?
Would you install it in your team's repo?
What would change your mind in either case?

This exercise is the practice you should run every single time you install something from outside the official marketplace.

Summary

The plugin marketplace is the fastest way to add capabilities without building them from scratch. Anthropic's official marketplace, built into Claude Code via the /plugin command, gives you access to more than 100 curated plugins that combine skills, hooks, subagents, and MCP servers.

What you learned in this capsule:

A plugin is a bundle of skills + hooks + subagents + MCP servers distributed as one unit
The /plugin command opens the marketplace interface with Discover, Installed, and Marketplaces tabs
Anthropic maintains an official marketplace (anthropics/claude-plugins-official) with 100+ curated plugins as of March 2026
There are alternative marketplaces (claude.com/plugins, buildwithclaude.com) — use them with judgment
When to install: generic tasks, plugins with a solid reputation, saving hours of configuration
When to build: tasks specific to your project, fine-grained control, secrets or internal compliance
The winning pattern: plugins for the generic (80%) + custom skills for the specific (20%)
Security: check the author, installs, hooks, and permissions before installing — especially outside the official marketplace
Conflicts between plugins get resolved at install time (explicit precedence)

Next capsule: 05 - Introduction to Agent Teams — the emerging multi-agent orchestration model with a team lead, teammates, and a task board.

Additional resources

Official documentation

Discover and install prebuilt plugins — Official plugin marketplace documentation
Plugins Reference — The full structure of a plugin (skills, agents, hooks, MCP)
claude.com/plugins — Web catalog of the official marketplace

Marketplace and community

anthropics/claude-plugins-official — The official marketplace repository
buildwithclaude.com — Community marketplace
awesome-claude-plugins — Curated list of marketplaces and plugins

Building your own plugins

Plugin development guide — How to package your skills + hooks + agents into a distributable plugin
Best Practices — Recommendations for building reusable plugins

← PreviousCustom Subagents: building specialized agents to fit your project Next →Introduction to Agent Teams: multi-agent orchestration