2.8 · Plugins and the Ecosystem

2.8 · 20 min

Plugins and the Ecosystem

By Lesson 2.6 you had built a working rig by hand: a CLAUDE.md, a review command, a skill, two hooks. Then you watch a teammate get the same setup in ninety seconds by installing a plugin, and the question writes itself: why did I build any of this manually? Because now you can read a plugin's hooks and know exactly what they do to your machine. The ecosystem is where that literacy pays, and where people without it get hurt.

What a plugin is

A plugin is a self-contained directory of the same components you have been building all part, packaged for distribution. Per the reference docs, a plugin can ship skills, agents, hooks, MCP servers, LSP servers, and monitors, with a manifest at .claude-plugin/plugin.json describing the package. Nothing in a plugin is a new kind of thing. A plugin's hook is a 2.6 hook; a plugin's MCP server is a 2.7 server; installation just wires them all up at once.

The tradeoff against your standalone .claude/ directory is naming and sharing. Standalone skills get short names like /review; plugin skills are namespaced as /plugin-name:review, which prevents collisions when you install strangers' work. The docs' guidance matches this course's: start standalone for personal, single-project workflows, and convert to a plugin when you want the same capability across projects or teammates. Your rig from 2.4 and 2.6 is standalone on purpose; packaging it is a ten-minute job you can do the day someone else needs it.

Marketplaces are catalogs of plugins. Adding a marketplace registers the catalog; installing a plugin is a separate, per-plugin choice. Two matter as of July 2026:

  • The official Anthropic marketplace (claude-plugins-official) is available automatically; run /plugin and browse the Discover tab, or view the catalog at claude.com/plugins. Inclusion is curated by Anthropic.
  • The community marketplace is where in-app submissions land: /plugin marketplace add anthropics/claude-plugins-community, then install from it under the name claude-community. Community means exactly that: useful work and abandoned experiments side by side, at varying quality.

Anyone can host a marketplace in a git repo, which is how teams distribute internal plugins: /plugin marketplace add your-org/your-plugins.

In practice: the ecosystem tour

Everything below is from the official marketplace, verified against the live catalog repo this month. Names, not endorsements; the evaluation checklist afterward is the actual lesson.

  • Code intelligence: the LSP plugins (typescript-lsp, pyright-lsp, rust-analyzer-lsp, gopls-lsp, and siblings). These wire real language servers into Claude Code, so Claude can jump to definitions, find references, and see type errors immediately after edits instead of waiting for your typecheck gate. Highest value-per-risk in the catalog: they add capability, not opinions. They do require the language server binary on your machine.
  • commit-commands: git workflow skills (commit, commit-push-pr, branch cleanup). The docs use it as their own installation example.
  • pr-review-toolkit: review agents for PR-shaped work. Pairs with the reviewer patterns you will build in 2.10.
  • security-guidance: reviews each change Claude makes for common vulnerabilities and instructs Claude to fix findings in-session. A soft-enforcement layer, not a scanner; treat it as an extra reviewer, not a gate.
  • hookify: builds 2.6-style hooks from natural-language descriptions. Useful scaffolding; audit what it generates, same as you would audit a copied hook.
  • Builder tooling: plugin-dev, mcp-server-dev, skill-creator, agent-sdk-dev. Plugins that help you build plugins, servers, skills, and SDK agents. You will meet agent-sdk-dev's territory in 2.11.

What is deliberately absent from this tour: the long tail of community plugins. Not because nothing there is good, but because nothing there should be installed on reputation. Which brings us to the checklist.

The evaluation checklist

A plugin is someone else's code that runs with your permissions, and its hooks execute arbitrary shell commands on the lifecycle events you learned in 2.6. Evaluate accordingly, before installing:

  1. Read the "Will install" listing. Since v2.1.145, the install screen for a plugin shows every command, agent, skill, hook, and MCP or LSP server it will add. If you would not approve one component alone, do not approve the bundle. (Older Claude Code versions do not show this screen; update first.)
  2. Read the hooks. Open the plugin's source repo and read hooks/hooks.json or equivalent before it ever runs. A hook that curls a URL you do not recognize, writes outside the project, or runs on every prompt is a no.
  3. Check the context cost. The install screen shows an estimate of tokens the plugin adds every turn (v2.1.143 and later). A plugin that costs a thousand tokens per turn is paying rent from your attention budget, forever, whether used or not.
  4. Check maintenance. Last-updated date on the install screen, commit activity on the repo. The ecosystem is young and churn is high; an unmaintained plugin wrapping a moving tool is worse than no plugin.
  5. Check what its MCP servers talk to. A bundled server is a 2.7 trust decision, same boundary, same injection surface.

Run this list and most of the catalog filters itself out for any given project. That is the checklist working, not failing.

Where it breaks

The characteristic failure is capability hoarding: installing eight plugins in week one, then discovering your sessions feel different and you cannot say why. Every installed plugin's skills and instructions are candidates for your context on every turn; three overlapping review plugins produce advice that conflicts, and a hook you forgot about keeps firing on every edit. The fix is the same discipline as 2.7's server rule: install for a named, current need, audit what arrived, and uninstall what stopped earning its context cost. /plugin shows what you have; disabling is one keystroke in the same panel.

The sharper failure is trust transfer. The official marketplace is curated, and it is easy to let that curation lull you into installing community or third-party marketplace plugins with the same reflex. The machinery is identical; the vetting is not. A malicious or merely careless plugin with a PreToolUse hook sees tool calls before they run. Read the hooks. Every time. It takes four minutes.

Lablab-2-8Install one plugin like an adult

Goal: Evaluate a plugin with the checklist, install it, and produce a written audit of everything it changed.

Prereqs: Claude Code v2.1.145 or later (claude --version; update if the install screen lacks the Will install section), the agentic-practice repo.

  1. In a session, run /plugin and open the Discover tab. Pick commit-commands (or, if you prefer, the LSP plugin matching your practice repo's language).
  2. Before installing, run the checklist: read the Will install listing, note the context cost estimate and last-updated date, and open the plugin's directory in the catalog repo (github.com/anthropics/claude-plugins-official, under plugins/) to read its skills and any hooks. Record each checklist item's result in plugin-audit.md.
  3. Install it, choosing user scope when prompted.
  4. Audit what changed: run /plugin to see it listed as installed, then ask Claude "list the skills you now have from installed plugins" and try one, for example /commit-commands:commit after a small edit to the practice repo.
  5. Finish plugin-audit.md with: components it added, what invoking one did, its per-turn context cost, and your keep-or-uninstall verdict with one sentence of reasoning.

Verify

  • plugin-audit.md has an entry for all five checklist items, written before installation.
  • The plugin's namespaced skill ran (for example a /commit-commands: skill produced a real commit or commit message).
  • Your verdict names the plugin's context cost and whether the capability justifies it.
>Troubleshooting
  • Plugin not found on install: your official marketplace listing is stale. Run /plugin marketplace update claude-plugins-official, then retry.
  • No Will install section on the details screen: your Claude Code predates v2.1.145. Update, then redo step 2; the audit surface is the point of the lab.
  • Namespaced skill does not autocomplete: type the full form /plugin-name:skill-name. If it still fails, check /plugin to confirm the plugin is enabled, not just installed.

Knowledge check

Knowledge check

Q1You built a /review command and two hooks in your project's .claude/ directory, and they work. A teammate asks for them. What is the right move per this lesson?
Q2A community-marketplace plugin promises automatic code formatting. Its listing shows a PreToolUse hook, an MCP server pointing at a domain you do not recognize, and a last-update nine months ago. What does the lesson's checklist say?
Q3Three weeks after a plugin binge, your sessions feel sluggish and Claude's review comments contradict each other. What is the most likely mechanism?
Q4Why does the lesson insist you read a plugin's hooks even when the Will install screen already lists them?

Sources