Plugins

Up to this point, every foundational element has been a single capability you author yourself. CLAUDE.md is one file. A skill is one folder. A hook is one entry in settings.json. Plugins are the next layer up: a packaging format that bundles skills, slash commands, hooks, and MCP servers into a single installable unit.

If skills are the equivalent of a function and hooks are the equivalent of an event listener, plugins are the equivalent of a library. Someone has done the work of designing a coherent set of capabilities for a specific job — code review, design critique, finance reporting — and packaged them so you can install once and use everything.

The anatomy

A plugin folder contains some combination of:

• Skills — the procedural knowledge for whatever the plugin does
• Slash commands — explicit triggers that invoke parts of the workflow on demand
• Hooks — lifecycle automations that fire without you asking
• MCP servers — external tools the skills and commands depend on

Not every plugin uses all four. A simple plugin might be three slash commands and nothing else. A heavyweight one might bundle half a dozen skills, a couple of hooks, and a custom MCP server. The format is flexible by design.

Why plugins matter for a Playbook project

Most of what you build with the Playbook is small enough that you’ll author capabilities one at a time, in place. The plugin question becomes relevant in two situations:

Installing someone else’s work. The Anthropic marketplace, accessible via /plugin, has plugins for common roles and workflows. The Design plugin gives you a /critique command. The official code-review plugin bundles security, correctness, and style checks. Installing one is faster than authoring the equivalent capabilities yourself, and the work is usually higher quality than a first-pass solo attempt.

Distributing your own work. Once you’ve built a constellation of skills, commands, and hooks that work together — the kind of setup that takes a few weeks of accumulated craft — packaging them as a plugin is the difference between “useful only on my machine” and “shareable with collaborators in one install.” For team projects in particular, this matters.

Installing a plugin

The flow is:

1. Run /plugin in Claude Code
2. Navigate to Marketplaces and pick claude-plugins-official (or another marketplace you trust)
3. Browse, read the plugin’s homepage, decide
4. Pick a scope — user-level for personal habits, project-level for plugins that should travel with the repo
5. Install
6. Verify it works in a safe context before relying on it for real work

Step 6 is the one most people skip. Plugins can install hooks that fire silently and skills that activate on inferred relevance. Triggering one in a low-stakes context — a scratch project, a throwaway branch — is the cheapest way to find out whether the plugin behaves the way you expected.

The third-party plugin problem

The official Anthropic marketplace is curated. The rest of the plugin ecosystem isn’t. You’ll find plugins on GitHub, in community marketplaces, in blog posts, in Discord servers. Some of these are excellent. Some are abandoned. A few are actively malicious.

Three checks before installing anything from outside the official marketplace:

Read the source. Plugins can install hooks that run shell commands and MCP servers that access external services. A malicious or careless plugin can run anything your shell can run. Open the repo and read what’s actually in there. If the README is thin and the source is opaque, walk away.

Check maintenance. A plugin last updated two years ago might not work with current Claude Code, or might depend on a deprecated API, or might have unfixed security issues. Recent commits and active issue resolution are the cheap signals.

Audit the permissions. What file access does the plugin require? What MCP servers does it install? What hooks does it register, and on what events? If any of those answers surprise you, don’t install it.

These checks aren’t unique to plugins — they apply to any third-party code you let near your filesystem. But plugins are the format most likely to install hooks that fire automatically, which makes the bar for trust higher than it would be for, say, copy-pasting a script you’ve read end-to-end.

When to package your own

The signal that you’re ready to package a plugin is that you’ve built a working set of capabilities for a specific job and someone else — a collaborator, a future you on a different machine — is asking how to get the same setup. At that point the cost of packaging is paid back the first time you don’t have to manually replicate the configuration.

A useful pattern for Playbook projects: the build flow itself, packaged as a plugin. The bootstrap prompts, the security skill, the launch checklist, the migration validator sub-agent — bundled together as playbook-build, installable in one step in any new project. Whether that’s worth doing depends on how many projects you start; for a single side project, the answer is usually no.