Claude Code Plugins: What They Are and How to Use Them

Claude Code Plugins let you bundle skills, hooks, subagents, and MCP servers into a single installable package. Instead of manually copying configuration across projects, you package everything into a plugin that anyone can install with one command.

Note: Claude Code Plugins are not currently tested on the Claude Certified Architect exam (exam guide dated 2026-02-10). This post covers a supplementary feature for practitioners who want to extend their Claude Code setup.

What plugins actually are

A plugin is a directory with a plugin.json manifest that declares what it provides. Think of it as a bundle — one plugin might include a custom slash command, a pre-commit hook, an MCP server for database access, and a subagent that handles code review. Install the plugin, and all of those capabilities become available in your Claude Code session.

Before plugins, you'd configure each of these individually across CLAUDE.md, .claude/settings.json, and MCP config files. Plugins collapse that into a single install step.

The plugin.json structure

Every plugin needs a plugin.json at its root. Here's a complete example:

{
  "name": "db-assistant",
  "version": "1.0.0",
  "description": "Database query assistant with schema-aware completions",
  "author": "your-org",
  "skills": [
    {
      "name": "query",
      "description": "Run read-only SQL queries against the connected database",
      "command": "/db-query",
      "entrypoint": "skills/query.md"
    }
  ],
  "hooks": [
    {
      "event": "on_message",
      "script": "hooks/validate-sql.sh",
      "description": "Validates SQL syntax before execution"
    }
  ],
  "mcpServers": {
    "db-schema": {
      "command": "node",
      "args": ["mcp/schema-server.js"],
      "env": {
        "DB_CONNECTION": "${DB_CONNECTION_STRING}"
      }
    }
  },
  "subagents": [
    {
      "name": "migration-reviewer",
      "prompt": "subagents/migration-reviewer.md",
      "description": "Reviews database migration files for safety issues"
    }
  ],
  "permissions": ["file_read", "file_write", "network"],
  "config": {
    "defaultDatabase": "postgres",
    "maxQueryResults": 100
  }
}

The key sections:

• skills declare slash commands with markdown entrypoints. When a user runs /db-query, Claude loads the skill prompt from skills/query.md.
• hooks attach scripts to lifecycle events. The on_message hook runs before Claude processes each message — useful for validation or logging.
• mcpServers define MCP servers that start automatically when the plugin loads. Environment variables use ${VAR} syntax and resolve from the user's shell.
• subagents register specialised agents that the main Claude Code session can delegate to.
• permissions declare what the plugin needs access to. Users see these at install time.
• config provides default settings that users can override.

Installing plugins

The /plugin command handles installation:

# Install from the marketplace
/plugin install db-assistant

# Install from a Git repository
/plugin install github:your-org/db-assistant

# Install from a local directory (useful during development)
/plugin install ./my-plugin

# List installed plugins
/plugin list

# Remove a plugin
/plugin remove db-assistant

When you install a plugin, Claude Code copies it into your local plugin directory and registers its skills, hooks, MCP servers, and subagents. Everything activates immediately — no restart required.

The plugin marketplace

The marketplace is a registry of community and first-party plugins. You can browse it from the CLI:

# Search the marketplace
/plugin search "database"

# View plugin details before installing
/plugin info db-assistant

Each marketplace listing shows the plugin description, permissions it requires, download count, and version history. Permissions matter here — a plugin requesting network access when it claims to be a local linting tool should raise questions.

Building your own plugin

Start with the scaffolding command:

/plugin init my-plugin

This creates the directory structure with a skeleton plugin.json. From there:

1. Add skills by creating markdown files in a skills/ directory and referencing them in plugin.json.
2. Add hooks by writing shell scripts or Node modules and binding them to lifecycle events.
3. Add MCP servers by building a server (Python with FastMCP or TypeScript with the MCP SDK) and declaring it in the mcpServers block.
4. Test locally by installing from the local path: /plugin install ./my-plugin.

During development, changes to skill prompts and hook scripts take effect on the next Claude Code message. Changes to plugin.json require a reinstall.

Plugin configuration and overrides

Users can override a plugin's default config without editing the plugin itself:

// .claude/plugins/db-assistant/config.json
{
  "defaultDatabase": "mysql",
  "maxQueryResults": 50
}

This layered config approach means plugin authors set sensible defaults and users adjust to their environment. Environment variables in MCP server definitions resolve at runtime, so secrets never get baked into the plugin package.

When to use plugins vs manual configuration

Plugins make sense when:

• You're sharing a Claude Code setup across a team or organisation
• The configuration involves multiple components (skills + hooks + MCP servers)
• You want version-controlled, reproducible environments
• You're publishing tooling for the community

Manual configuration is fine when:

• You're setting up a one-off project-specific tool
• The configuration is a single MCP server or a CLAUDE.md instruction
• You're prototyping and don't want the overhead of a manifest

What this means for the exam

The exam tests Claude Code configuration through Domain 3 — Claude Code Configuration & Workflows. The concepts that plugins build on — slash commands, MCP server configuration, hooks, and CLAUDE.md — are all testable. Understanding how plugins bundle these components gives you a stronger mental model of how Claude Code's configuration system fits together, even though plugins themselves won't appear in exam questions.

If you want to solidify the underlying concepts, work through Task 3.5 — Slash Commands & MCP and Task 3.3 — Hooks.