--- title: "Claude Code Plugins for Product Managers" description: "A Claude Code plugin packages skills, agents and hooks into one installable bundle, so a whole product team runs the same workflow instead of five variants." canonical_url: "https://builderscamp.com/guides/tools/claude-code-plugins-for-product-managers" date_published: "2026-09-18" date_modified: "2026-09-18" author: "Andre Albuquerque, Guilherme Salgueiro" publisher: "Builders Camp" guide_class: "tools" --- # Claude Code plugins for product managers, and how to ship one to your team **TL;DR:** A Claude Code plugin bundles skills, agents, hooks and MCP servers into one installable directory with a manifest, so a product team runs one agreed workflow instead of five personal variants of it. Build it standalone in a .claude directory first, convert once a second person needs it, and distribute it through a git-hosted marketplace your teammates add once. ## What problem does a plugin actually solve for a product team? You wrote a workflow that works. It reads the last sprint's shipped pull requests, drafts release notes in your house format, flags anything customer facing that has no support article, and stops before publishing. It took you three weeks of refinement. Right now it lives in your `.claude` directory as a skill, a hook, and two lines in your CLAUDE.md, and the only way your colleague gets it is if you send them three files and hope they land in the right places. A plugin is the packaging step. It is a self-contained directory holding skills, agents, hooks, MCP servers, or any mix of those, with an optional manifest at `.claude-plugin/plugin.json` naming it, describing it, and versioning it. Anthropic's own guidance is to start with standalone configuration in `.claude` for quick iteration and convert to a plugin when you are ready to share, which is the right order: the thing you package should already have survived contact with real work. The shape of the problem is familiar from product work generally. Five people each solving the same problem their own way produces five defensible answers and no shared standard, and the cost is not the duplicated effort, it is that nobody can tell whether two outputs differ because the inputs differed or because the method did. ## What goes inside a plugin, and what stays out Four component types are supported: skills, agents, hooks, and MCP servers. Each answers a different question, and mixing them up is the usual reason a first plugin feels bloated. A [skill](https://builderscamp.com/guides/glossary/ai-agent-skill) is the procedure. It packages the steps, the known pitfalls, the quality gates, and the definition of done for recurring work, so the agent loads it instead of being re-explained every session. An agent is a role with its own focused context, used when one job should not see another job's reasoning, which is the argument for a reviewer that did not write the code. A [hook](https://builderscamp.com/guides/glossary/automation-hooks-claude-code) is the enforcement layer: a shell command that runs at a fixed point regardless of what the model decides. An MCP server is a connection to something outside the repository. What stays out is anything that is true only for you. Your personal shortcuts, your preferred model, the path to your local scratch directory: those belong in your own user-level configuration, not in a bundle five people install. The test is simple. If a teammate would have to edit it before it works, it does not belong in the plugin. ## A worked example: the weekly release notes plugin Here is the same workflow, packaged. Create a directory, `release-notes-plugin`, and inside it a `.claude-plugin/plugin.json` with four fields: `name`, `description`, `version`, and `author`. The name matters more than it looks, because it becomes the namespace: a skill called `draft` inside a plugin called `release-notes` is invoked as `/release-notes:draft`, never as a bare `/draft` that could collide with something else on the team. Then add the pieces. A skill file holding the actual procedure, including your house format and the rule that a customer-facing change with no support article gets flagged rather than silently written up. A hook that runs before the agent is allowed to write anything, checking that the sprint tag it was given actually exists. Optionally an agent whose only job is to read the draft against the format rules, with no access to the reasoning that produced it. Test it locally by pointing Claude Code at the directory with `--plugin-dir`, which avoids installing anything while you are still changing it every ten minutes. When it survives a real Friday, that is the moment to version it and share it, not before. ## How do you get it onto your colleagues' machines? Through a marketplace, which is a plainer thing than the name suggests: a git repository containing a `marketplace.json` catalog that lists your plugins and says where each one lives. Push it to GitHub, GitLab, or any git host you already use. Your colleagues add it once with `/plugin marketplace add`, install the specific plugins they want, and later run `/plugin marketplace update` to refresh their local copy. The version field is the part worth deciding deliberately. Set it, and people only receive updates when you bump it. Omit it, and the version resolves from the next source in the chain. For a team workflow, set it: a release-notes plugin that silently changes format mid-quarter is a worse problem than one that is slightly out of date, because the second is visible and the first is not. If you would rather install than build, Claude Code adds Anthropic's official marketplace, `claude-plugins-official`, the first time it starts interactively, and `/plugin` opens a Discover tab listing what is available. That catalog is curated at Anthropic's discretion, so read it as a well-maintained starting set rather than a complete index of everything that exists. ## The honest limitation: a plugin does not make a workflow good Packaging is a distribution improvement, not a quality one. A plugin that encodes a sloppy definition of done distributes the sloppiness faster and with more authority than the original ad hoc version, because it now has a name, a version, and the implication that somebody thought about it. The failure mode in Builders Camp's own Building with Claude Code practical challenge is exactly this: a team ships a broken deploy because nobody had defined what done meant, and the fix is not more tooling, it is an objective acceptance standard that a hook can then enforce. So sequence it. Get the workflow right by hand. Write down what done means in terms someone else could check. Only then package it, because the packaging step is what makes the definition binding across a team, and binding a wrong definition is worse than leaving it loose. ## What this looks like at the team level Three things change once a product team runs one plugin instead of five personal setups. - Outputs become comparable, because a difference between two drafts now means the inputs differed, not the method. - Improvements compound, since a fix you make once reaches everyone on the next update rather than living in your directory. - Onboarding stops being a conversation, because a new product manager installs the bundle and inherits the conventions rather than absorbing them over a quarter. That third one is where the return actually shows up, and it is the reason to write the plugin before you feel the need for it rather than after. ## Where this sits in the Builders Camp catalogue Building with Claude Code is the direct match: 2 live sessions and 9 microlessons covering CLAUDE.md and context architecture, skills, agents and memory, MCP and tool integrations, and hooks with quality gates, taught by Guilherme Salgueiro. Its practical challenge asks you to design a three-agent architecture with explicit boundaries and a governance layer, which is the thinking a plugin then packages. If your instinct is that the workflow itself needs designing before it needs bundling, Automate Workflows with AI is the earlier step, built around picking which repetitive work is worth automating and adding human approvals at the high-stakes points rather than automating everything. The AI Agentic Builders Expert Track bundles both alongside the agent-design work, for a product manager who wants the sequence rather than a single bootcamp. ## Package the second version, not the first The plugin worth building is the one you have already run four times and corrected twice, because the corrections are the content. Open the workflow you have been quietly re-explaining to yourself every week, write down what done means for it in a form a colleague could check, and package that. Everything else is a directory and a JSON file. [See the Building with Claude Code bootcamp](https://builderscamp.com/bootcamps/building-with-claude-code?utm_source=guide&utm_medium=organic&utm_campaign=claude-code-plugins-for-product-managers) For the layer above a single bundle, [multi-agent orchestration](https://builderscamp.com/guides/glossary/multi-agent-orchestration) covers how several agents share one task, and [n8n for product managers](https://builderscamp.com/guides/tools/n8n-for-product-managers) covers the workflow automation path for work that never touches a repository at all. ## Frequently asked questions ### What is a Claude Code plugin? A plugin is a self-contained directory bundling skills, agents, hooks, MCP servers, or any combination of those, plus an optional manifest at .claude-plugin/plugin.json. Installing it gives someone every piece at once instead of asking them to copy four files into the right places. ### How is a plugin different from just putting files in .claude? Standalone configuration in a .claude directory is faster to iterate on and fine for personal or project-specific work. A plugin adds a name, a version, and a distribution path, which is what you need the moment a second person has to run the same workflow. Anthropic's own guidance is to start standalone and convert when you are ready to share. ### Do plugin skills get their own names? Yes, and that is a feature. A standalone skill is invoked as /hello. The same skill inside a plugin is /plugin-name:hello, so two plugins can both define a review skill without colliding, and anyone reading a transcript can see which bundle a command came from. ### How does a product manager distribute a plugin to the team? Through a marketplace, which is a git repository containing a marketplace.json catalog listing your plugins. Teammates add it once with /plugin marketplace add, install the plugins they want, and pull later changes with /plugin marketplace update. GitHub or GitLab hosting is enough, no separate infrastructure required. ### Are there plugins I can install rather than build? Claude Code adds Anthropic's official marketplace, claude-plugins-official, the first time it starts interactively. Run /plugin and open the Discover tab, or browse the catalog at claude.com/plugins. Inclusion in that marketplace is curated at Anthropic's discretion, so treat it as a starting set rather than a complete index. ### Does a product manager need to write code to build one? The manifest is a short JSON file and a skill is a markdown file, so a plugin containing only skills needs no programming. A plugin containing hooks does, because hooks are shell commands. A common split is that the product manager writes the skills and the definition of done, and an engineer writes the hook that enforces it. ### What stops a plugin from becoming shelfware? The version field. If you omit it, users pick up changes on every refresh. If you set it, they only receive updates when you bump it, which means you can ship a fix without a team-wide surprise and you have a record of what changed. A plugin nobody has bumped in six months is visibly stale, which is the useful signal. ## Sources - [Anthropic: Create plugins](https://docs.claude.com/en/docs/claude-code/plugins) - [Anthropic: Discover and install prebuilt plugins](https://docs.claude.com/en/docs/claude-code/discover-plugins) - [Anthropic: Create and distribute a plugin marketplace](https://docs.claude.com/en/docs/claude-code/plugin-marketplaces) - [Anthropic: Hooks in Claude Code](https://docs.claude.com/en/docs/claude-code/hooks) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.