Files
claude-howto/07-plugins/README.md
T
Luong NGUYEN 487c96d950 docs: Sync all documentation with Claude Code February 2026 features
Update 23 files across all 10 tutorial directories and 7 reference
documents to match the latest Claude Code v2.1+ features and correct
outdated content including model names (4.5→4.6), permission modes,
hook events, CLI syntax, MCP config paths, plugin manifest format,
checkpoint commands, session management, and URLs. Add documentation
for new features: Auto Memory, Remote Control, Web Sessions, Desktop
App, Agent Teams, MCP OAuth, Task List, Sandboxing, and more.
2026-02-25 23:19:08 +01:00

18 KiB

Claude How To

Claude Code Plugins

This folder contains complete plugin examples that bundle multiple Claude Code features into cohesive, installable packages.

Overview

Claude Code Plugins are bundled collections of customizations (slash commands, subagents, MCP servers, and hooks) that install with a single command. They represent the highest-level extension mechanism—combining multiple features into cohesive, shareable packages.

Plugin Architecture

graph TB
    A["Plugin"]
    B["Slash Commands"]
    C["Subagents"]
    D["MCP Servers"]
    E["Hooks"]
    F["Configuration"]

    A -->|bundles| B
    A -->|bundles| C
    A -->|bundles| D
    A -->|bundles| E
    A -->|bundles| F

Plugin Loading Process

sequenceDiagram
    participant User
    participant Claude as Claude Code
    participant Plugin as Plugin Marketplace
    participant Install as Installation
    participant SlashCmds as Slash Commands
    participant Subagents
    participant MCPServers as MCP Servers
    participant Hooks
    participant Tools as Configured Tools

    User->>Claude: /plugin install pr-review
    Claude->>Plugin: Download plugin manifest
    Plugin-->>Claude: Return plugin definition
    Claude->>Install: Extract components
    Install->>SlashCmds: Configure
    Install->>Subagents: Configure
    Install->>MCPServers: Configure
    Install->>Hooks: Configure
    SlashCmds-->>Tools: Ready to use
    Subagents-->>Tools: Ready to use
    MCPServers-->>Tools: Ready to use
    Hooks-->>Tools: Ready to use
    Tools-->>Claude: Plugin installed ✅

Plugin Types & Distribution

Type Scope Shared Authority Examples
Official Global All users Anthropic PR Review, Security Guidance
Community Public All users Community DevOps, Data Science
Organization Internal Team members Company Internal standards, tools
Personal Individual Single user Developer Custom workflows

Plugin Definition Structure

Plugin manifest uses JSON format in .claude-plugin/plugin.json:

{
  "name": "my-first-plugin",
  "description": "A greeting plugin",
  "version": "1.0.0",
  "author": {
    "name": "Your Name"
  },
  "homepage": "https://example.com",
  "repository": "https://github.com/user/repo",
  "license": "MIT"
}

Plugin Structure Example

my-plugin/
├── .claude-plugin/
│   └── plugin.json       # Manifest (name, description, version, author)
├── commands/             # Skills as Markdown files
│   ├── task-1.md
│   ├── task-2.md
│   └── workflows/
├── agents/               # Custom agent definitions
│   ├── specialist-1.md
│   ├── specialist-2.md
│   └── configs/
├── skills/               # Agent Skills with SKILL.md files
│   ├── skill-1.md
│   └── skill-2.md
├── hooks/                # Event handlers in hooks.json
│   └── hooks.json
├── .mcp.json             # MCP server configurations
├── .lsp.json             # LSP server configurations
├── settings.json         # Default settings
├── templates/
│   └── issue-template.md
├── scripts/
│   ├── helper-1.sh
│   └── helper-2.py
├── docs/
│   ├── README.md
│   └── USAGE.md
└── tests/
    └── plugin.test.js

LSP Server Configuration

Plugins can include Language Server Protocol (LSP) support via .lsp.json:

{
  "go": {
    "command": "gopls",
    "args": ["serve"],
    "extensionToLanguage": {
      ".go": "go"
    }
  }
}

Plugin Settings

Plugins can ship a settings.json file to provide default configuration. This currently supports the agent key, which sets the main thread agent for the plugin:

{
  "agent": "agents/specialist-1.md"
}

When a plugin includes settings.json, its defaults are applied on installation. Users can override these settings in their own project or user configuration.

Standalone vs Plugin Approach

Approach Command Names Configuration Best For
Standalone /hello Manual setup in CLAUDE.md Personal, project-specific
Plugins /plugin-name:hello Automated via plugin.json Sharing, distribution, team use

Use standalone slash commands for quick personal workflows. Use plugins when you want to bundle multiple features, share with a team, or publish for distribution.

Practical Examples

Example 1: PR Review Plugin

File: .claude-plugin/plugin.json

{
  "name": "pr-review",
  "version": "1.0.0",
  "description": "Complete PR review workflow with security, testing, and docs",
  "author": {
    "name": "Anthropic"
  },
  "repository": "https://github.com/anthropic/pr-review",
  "license": "MIT"
}

File: commands/review-pr.md

---
name: Review PR
description: Start comprehensive PR review with security and testing checks
---

# PR Review

This command initiates a complete pull request review including:

1. Security analysis
2. Test coverage verification
3. Documentation updates
4. Code quality checks
5. Performance impact assessment

File: agents/security-reviewer.md

---
name: security-reviewer
description: Security-focused code review
tools: read, grep, diff
---

# Security Reviewer

Specializes in finding security vulnerabilities:
- Authentication/authorization issues
- Data exposure
- Injection attacks
- Secure configuration

Installation:

/plugin install pr-review

# Result:
# ✅ 3 slash commands installed
# ✅ 3 subagents configured
# ✅ 2 MCP servers connected
# ✅ 4 hooks registered
# ✅ Ready to use!

Example 2: DevOps Plugin

Components:

devops-automation/
├── commands/
│   ├── deploy.md
│   ├── rollback.md
│   ├── status.md
│   └── incident.md
├── agents/
│   ├── deployment-specialist.md
│   ├── incident-commander.md
│   └── alert-analyzer.md
├── mcp/
│   ├── github-config.json
│   ├── kubernetes-config.json
│   └── prometheus-config.json
├── hooks/
│   ├── pre-deploy.js
│   ├── post-deploy.js
│   └── on-error.js
└── scripts/
    ├── deploy.sh
    ├── rollback.sh
    └── health-check.sh

Example 3: Documentation Plugin

Bundled Components:

documentation/
├── commands/
│   ├── generate-api-docs.md
│   ├── generate-readme.md
│   ├── sync-docs.md
│   └── validate-docs.md
├── agents/
│   ├── api-documenter.md
│   ├── code-commentator.md
│   └── example-generator.md
├── mcp/
│   ├── github-docs-config.json
│   └── slack-announce-config.json
└── templates/
    ├── api-endpoint.md
    ├── function-docs.md
    └── adr-template.md

Plugin Marketplace

The official Anthropic-managed plugin directory is anthropics/claude-plugins-official. Enterprise admins can also create private plugin marketplaces for internal distribution.

graph TB
    A["Plugin Marketplace"]
    B["Official<br/>anthropics/claude-plugins-official"]
    C["Community<br/>Marketplace"]
    D["Enterprise<br/>Private Registry"]

    A --> B
    A --> C
    A --> D

    B -->|Categories| B1["Development"]
    B -->|Categories| B2["DevOps"]
    B -->|Categories| B3["Documentation"]

    C -->|Search| C1["DevOps Automation"]
    C -->|Search| C2["Mobile Dev"]
    C -->|Search| C3["Data Science"]

    D -->|Internal| D1["Company Standards"]
    D -->|Internal| D2["Legacy Systems"]
    D -->|Internal| D3["Compliance"]

    style A fill:#e1f5fe,stroke:#333,color:#333
    style B fill:#e8f5e9,stroke:#333,color:#333
    style C fill:#f3e5f5,stroke:#333,color:#333
    style D fill:#fff3e0,stroke:#333,color:#333

Marketplace Configuration

Enterprise and advanced users can control marketplace behavior through settings:

Setting Description
extraKnownMarketplaces Add additional marketplace sources beyond the defaults
blockedMarketplaces Admin-managed setting to restrict specific marketplaces
strictKnownMarketplaces Control which marketplaces users are allowed to add

Additional Marketplace Features

  • Default git timeout: Increased from 30s to 120s for large plugin repositories
  • Custom npm registries: Plugins can specify custom npm registry URLs for dependency resolution
  • Version pinning: Lock plugins to specific versions for reproducible environments

Plugin Installation & Lifecycle

graph LR
    A["Discover"] -->|Browse| B["Marketplace"]
    B -->|Select| C["Plugin Page"]
    C -->|View| D["Components"]
    D -->|Install| E["/plugin install"]
    E -->|Extract| F["Configure"]
    F -->|Activate| G["Use"]
    G -->|Check| H["Update"]
    H -->|Available| G
    G -->|Done| I["Disable"]
    I -->|Later| J["Enable"]
    J -->|Back| G

Plugin Features Comparison

Feature Slash Command Skill Subagent Plugin
Installation Manual copy Manual copy Manual config One command
Setup Time 5 minutes 10 minutes 15 minutes 2 minutes
Bundling Single file Single file Single file Multiple
Versioning Manual Manual Manual Automatic
Team Sharing Copy file Copy file Copy file Install ID
Updates Manual Manual Manual Auto-available
Dependencies None None None May include
Marketplace No No No Yes
Distribution Repository Repository Repository Marketplace

Installation Methods

From Marketplace

/plugin install plugin-name

Enable / Disable (with auto-detected scope)

/plugin enable plugin-name
/plugin disable plugin-name

Local Plugin (for development)

# CLI flag for local testing (repeatable for multiple plugins)
claude --plugin-dir ./path/to/plugin
claude --plugin-dir ./plugin-a --plugin-dir ./plugin-b

From Git Repository

/plugin install github:username/repo

When to Create a Plugin

graph TD
    A["Should I create a plugin?"]
    A -->|Need multiple components| B{"Multiple commands<br/>or subagents<br/>or MCPs?"}
    B -->|Yes| C["✅ Create Plugin"]
    B -->|No| D["Use Individual Feature"]
    A -->|Team workflow| E{"Share with<br/>team?"}
    E -->|Yes| C
    E -->|No| F["Keep as Local Setup"]
    A -->|Complex setup| G{"Needs auto<br/>configuration?"}
    G -->|Yes| C
    G -->|No| D

Plugin Use Cases

Use Case Recommendation Why
Team Onboarding Use Plugin Instant setup, all configurations
Framework Setup Use Plugin Bundles framework-specific commands
Enterprise Standards Use Plugin Central distribution, version control
Quick Task Automation Use Command Overkill complexity
Single Domain Expertise Use Skill Too heavy, use skill instead
Specialized Analysis Use Subagent Create manually or use skill
Live Data Access Use MCP Standalone, don't bundle

Testing a Plugin

Before publishing, test your plugin locally using the --plugin-dir CLI flag (repeatable for multiple plugins):

claude --plugin-dir ./my-plugin
claude --plugin-dir ./my-plugin --plugin-dir ./another-plugin

This launches Claude Code with your plugin loaded, allowing you to:

  • Verify all slash commands are available
  • Test subagents and agents function correctly
  • Confirm MCP servers connect properly
  • Validate hook execution
  • Check LSP server configurations
  • Check for any configuration errors

Publishing a Plugin

Steps to publish:

  1. Create plugin structure with all components
  2. Write .claude-plugin/plugin.json manifest
  3. Create README.md with documentation
  4. Test locally with claude --plugin-dir ./my-plugin
  5. Submit to plugin marketplace
  6. Get reviewed and approved
  7. Published on marketplace
  8. Users can install with one command

Example submission:

# PR Review Plugin

## Description
Complete PR review workflow with security, testing, and documentation checks.

## What's Included
- 3 slash commands for different review types
- 3 specialized subagents
- GitHub and CodeQL MCP integration
- Automated security scanning hooks

## Installation
```bash
/plugin install pr-review

Features

Security analysis Test coverage checking Documentation verification Code quality assessment Performance impact analysis

Usage

/review-pr
/check-security
/check-tests

Requirements

  • Claude Code 1.0+
  • GitHub access
  • CodeQL (optional)

## Plugin vs Manual Configuration

**Manual Setup (2+ hours):**
- Install slash commands one by one
- Create subagents individually
- Configure MCPs separately
- Set up hooks manually
- Document everything
- Share with team (hope they configure correctly)

**With Plugin (2 minutes):**
```bash
/plugin install pr-review
# ✅ Everything installed and configured
# ✅ Ready to use immediately
# ✅ Team can reproduce exact setup

Best Practices

Do's

  • Use clear, descriptive plugin names
  • Include comprehensive README
  • Version your plugin properly (semver)
  • Test all components together
  • Document requirements clearly
  • Provide usage examples
  • Include error handling
  • Tag appropriately for discovery
  • Maintain backward compatibility
  • Keep plugins focused and cohesive
  • Include comprehensive tests
  • Document all dependencies

Don'ts

  • Don't bundle unrelated features
  • Don't hardcode credentials
  • Don't skip testing
  • Don't forget documentation
  • Don't create redundant plugins
  • Don't ignore versioning
  • Don't overcomplicate component dependencies
  • Don't forget to handle errors gracefully

Installation Instructions

Installing from Marketplace

  1. Browse available plugins:

    /plugin list
    
  2. View plugin details:

    /plugin info plugin-name
    
  3. Install a plugin:

    /plugin install plugin-name
    

Installing from Local Path

/plugin install ./path/to/plugin-directory

Installing from GitHub

/plugin install github:username/repo

Listing Installed Plugins

/plugin list --installed

Updating a Plugin

/plugin update plugin-name

Disabling/Enabling a Plugin

# Temporarily disable
/plugin disable plugin-name

# Re-enable
/plugin enable plugin-name

Uninstalling a Plugin

/plugin uninstall plugin-name

The following Claude Code features work together with plugins:

  • Slash Commands - Individual commands bundled in plugins
  • Memory - Persistent context for plugins
  • Skills - Domain expertise that can be wrapped into plugins
  • Subagents - Specialized agents included as plugin components
  • MCP Servers - Model Context Protocol integrations bundled in plugins
  • Hooks - Event handlers that trigger plugin workflows

Complete Example Workflow

PR Review Plugin Full Workflow

1. User: /review-pr

2. Plugin executes:
   ├── pre-review.js hook validates git repo
   ├── GitHub MCP fetches PR data
   ├── security-reviewer subagent analyzes security
   ├── test-checker subagent verifies coverage
   └── performance-analyzer subagent checks performance

3. Results synthesized and presented:
   ✅ Security: No critical issues
   ⚠️  Testing: Coverage 65% (recommend 80%+)
   ✅ Performance: No significant impact
   📝 12 recommendations provided

Troubleshooting

Plugin Won't Install

  • Check Claude Code version compatibility: /version
  • Verify plugin.json syntax with a JSON validator
  • Check internet connection (for remote plugins)
  • Review permissions: ls -la plugin/

Components Not Loading

  • Verify paths in plugin.json match actual directory structure
  • Check file permissions: chmod +x scripts/
  • Review component file syntax
  • Check logs: /plugin debug plugin-name

MCP Connection Failed

  • Verify environment variables are set correctly
  • Check MCP server installation and health
  • Test MCP connection independently with /mcp test
  • Review MCP configuration in mcp/ directory

Commands Not Available After Install

  • Ensure plugin was installed successfully: /plugin list --installed
  • Check if plugin is enabled: /plugin status plugin-name
  • Restart Claude Code: exit and reopen
  • Check for naming conflicts with existing commands

Hook Execution Issues

  • Verify hook files have correct permissions
  • Check hook syntax and event names
  • Review hook logs for error details
  • Test hooks manually if possible

Additional Resources