Claude Code Plugins and Skills Marketplace: Best Plugins, Hooks and Setup (2026)

The first plugin I installed in Claude Code did something I had been doing by hand for nine months.

It was a skill called frontend-design. I added it, asked Claude to build a landing page, and watched it ignore every default React-and-Tailwind cliché it usually reaches for. No emoji buttons. No space-y-4 p-6 rounded-2xl. No three-column-card grid. The skill loaded in a specific design vocabulary at the top of the turn and pushed the rest of the model output into a different aesthetic universe. I had been writing that vocabulary into my own system prompt for nearly a year. Now it was a one-line install.

That was the moment I understood what the Claude Code plugin marketplace actually is. It is not an app store. It is a distribution system for opinions. Specifically, the opinions about how to do a thing that you used to keep in your own CLAUDE.md, in a Notion page, or in your head. The marketplace turned those opinions into installable units that any developer can subscribe to in thirty seconds.

This is the post I wish I had read when I was still confusing plugins, skills, MCP servers, and hooks and reaching for the wrong one on every problem. I rewrote it in October 2026 so the commands match the current docs.

What Are Claude Code Plugins?

A Claude Code plugin is a directory that packages skills, subagents, hooks and MCP servers, plus a manifest at .claude-plugin/plugin.json, so Claude Code can install and load them as one unit. You get plugins from a marketplace, which is a catalog defined by a .claude-plugin/marketplace.json file, with /plugin install <name>@<marketplace>.

Skills, subagents, hooks and MCP servers all work on their own without a plugin. A skill in ~/.claude/skills/ is available in every project on your machine. You only need a plugin when you want several of those pieces packaged as one unit that a teammate can install, or when you want versioned releases.

The Mental Model

The single sentence that unlocks the marketplace is this. Plugins are the distribution format. Skills are the content. MCP servers are the data layer. Hooks are the automation.

If you only remember one paragraph from this post, remember the four nouns and what each of them does.

A skill is a folder with a SKILL.md at its root, optional supporting files, and a frontmatter block that tells Claude when to fire. A skill teaches the model how to do a specific thing well: debug a flaky test, audit SEO, review React components, build a landing page in a specific style. When the user's request matches the skill's description, Claude reads the skill and follows its instructions. The model does not run anything outside its normal toolset. The skill is, fundamentally, structured prompt material.

A plugin is a packaged folder that can contain one or more skills, plus MCP server configs, hooks, and agent definitions. It is the unit you install and uninstall. Plugins are how skills travel between developers. Anthropic's marketplaces ship plugins. Community marketplaces ship plugins. Your team's private GitHub repo ships plugins. The wrapper is always the same.

An MCP server is a separate process that exposes tools to the model over a standardised protocol. If you want Claude to read your Linear tickets, query your Postgres, or look up your internal Confluence, you need an MCP server for that data source. Plugins can bundle MCP servers, so installing the plugin wires the model into real systems. I went deep into MCP in the MCP developer guide; the short version is that MCP is the thing that turns Claude from "a model that writes code" into "an agent that touches your stack."

A hook is a command Claude Code runs in response to lifecycle events like SessionStart, PreToolUse, PostToolUse and Stop. Hooks are not prompts. They are real automation. They run when something happens, regardless of what the model thinks. There is a full section on them below.

Most plugins use two or three of these primitives. The shape of a great plugin is something like: skills for the agent's behavior, MCP servers for the data the skills need, hooks to enforce the rules the skills suggest.

Once you see the four pieces, every plugin you read becomes legible.

The Claude Skills Marketplace: Where Plugins and Skills Come From

People search for a "Claude skills marketplace" as if there were one store. There are really several catalogs, and the naming is confusing, so here is the map, checked against Anthropic's docs on October 22, 2026.

Two things from the docs surprised me. First, most of what the official marketplace lists comes from partners and other authors, not from Anthropic. Tool vendors publish plugins that connect Claude Code to their services. Second, /plugin marketplace add anthropics/claude-code adds the demo marketplace, not the official one, which trips up people following older tutorials.

To browse, run /plugin in a session and open the Discover tab. You can also search the full catalog on the web at claude.com/marketplace/plugins, which shows install counts and marks some plugins as Anthropic verified. And Claude Code does not need a marketplace at all for plugins you are building yourself.

Beyond Anthropic's catalogs, a marketplace is just a Git repository with a .claude-plugin/marketplace.json file. Anyone can run one, anyone can fork one, and a private repo works for a team. Anthropic does not review third-party marketplaces, so read the plugin security and trust page before you add one.

That design is the right call. The fragility of an "app store" model is that one central registry becomes a chokepoint. The Git-repo-as-marketplace model means the cost of running your own is roughly the cost of a public GitHub repo.

How To Install Plugins From the Claude Code Plugin Marketplace

The format is <plugin>@<marketplace>. As the docs' own example, here is commit-commands from the official marketplace:

/plugin install commit-commands@claude-plugins-official

In a session, that command does not install right away. It opens the /plugin panel on the plugin's details so you can review what it adds (commands, agents, skills, hooks, MCP servers) and pick a scope. Official-marketplace plugins also show a context cost estimate: tokens added every turn, and tokens added when its skills are invoked. The scopes are:

• User scope: enabled for you in every project on the machine.
• Project scope: enabled for everyone on the repo, recorded in the committed .claude/settings.json. Each collaborator still installs it on their own machine.
• Local scope: enabled for you in this repo only.

After install, plugin skills show up as /<plugin>:<skill>, so commit-commands gives you /commit-commands:commit. Skills are namespaced by plugin name, so two plugins can each have a hello skill without colliding.

For a marketplace that is not the official one, add it first:

/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills

You can do the same from your shell, which is handy in setup scripts:

claude plugin marketplace add anthropics/skills
claude plugin install example-skills@anthropic-agent-skills --scope project
claude plugin list

Other commands worth knowing: claude plugin disable, enable and uninstall take the same <plugin>@<marketplace> id, /reload-plugins applies changes in an open session, and claude plugin details <name> shows how many tokens a plugin adds to every session. Plugins update automatically only for marketplaces that have auto-update on, which is the default for the official ones and off for third-party ones.

If your team also uses Cursor or Copilot alongside Claude Code, the config-file projection workflow is what keeps the rules in those tools in sync with the ones living in .claude/.

Best Claude Code Plugins to Start With

The catalog changes often, so I only list plugins I could confirm exist in Anthropic's own docs or repos. Start small. An enabled plugin adds its skill names and descriptions to your context on every turn, so more is not better.

• commit-commands (official marketplace): commands for committing, pushing and opening pull requests. This is the docs' own install example, and a good first plugin.
• code-review (official marketplace): code review as a plugin. It is also in the demo marketplace, so install it from claude-plugins-official to avoid duplicates.
• feature-dev (official marketplace): one of Anthropic's worked examples of a full plugin, and a good one to read if you want to see what a larger plugin looks like.
• security-guidance (official marketplace): security guidance in your sessions.
• plugin-dev (official marketplace): skills and agents for writing and validating plugins. Once installed, /plugin-dev:create-plugin followed by a description walks you through building one.
• Language server plugins (official marketplace): code intelligence for your language. The docs have a dedicated code intelligence page.
• example-skills and document-skills (from anthropics/skills): Anthropic's public skills, such as frontend-design, webapp-testing, mcp-builder and the docx, pdf, pptx and xlsx skills. My skills guide lists the ones I would look at first.
• statusline-pro (from alexcloudstar/statusline-pro): a status line plugin I wrote, so weigh that accordingly. My Claude Code status line guide covers it and the alternatives.
• Vendor plugins: the official marketplace includes plugins from tool vendors that connect Claude Code to their services. I use the Vercel plugin on projects that ship to Vercel. Check /plugin for your own stack before you build a custom MCP integration.

What I would skip on the first install: anything that promises to autonomously refactor your codebase or auto-merge PRs. Not because it cannot work. Because the failure mode is hard to recover from when you have not yet built a feel for the surface. Start with skills that suggest. Graduate to hooks that enforce. Reach for autonomous workflows last.

Claude Code Hooks: Automate Actions Around Every Edit

Claude Code hooks are user-defined shell commands that Claude Code runs at specific points in its lifecycle, such as before a tool call, after a file edit, or when a session ends. They give you deterministic control: the action always happens, instead of relying on the model to remember to do it.

This is the piece that skills cannot replace. A skill is a strong suggestion. A hook is a guarantee. If the requirement is "every time Claude edits a file, run the formatter," that is a hook.

The events that matter

The hooks guide lists more than thirty events. These are the ones I reach for:

Example 1: format every edited file

Add this to .claude/settings.json. It runs Prettier on every file Claude writes or edits, using a PostToolUse hook with an Edit|Write matcher. This is the example from Anthropic's hooks guide:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Example 2: block edits to protected files

A PreToolUse hook can stop a tool call. The script reads the hook's JSON input on stdin, checks the target path, and exits with code 2 to block it. The message written to stderr goes back to Claude as feedback:

#!/bin/bash
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

PROTECTED_PATTERNS=(".env" "package-lock.json" ".git/")

for pattern in "${PROTECTED_PATTERNS[@]}"; do
  if [[ "$FILE_PATH" == *"$pattern"* ]]; then
    echo "Blocked: $FILE_PATH matches protected pattern '$pattern'" >&2
    exit 2
  fi
done

exit 0

Save it as .claude/hooks/protect-files.sh, make it executable with chmod +x, and register it:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-files.sh"
          }
        ]
      }
    ]
  }
}

How hooks are configured and what they can do

• Where they live: ~/.claude/settings.json for all your projects, .claude/settings.json for one project (committable), .claude/settings.local.json for local-only, managed settings for an organization, a plugin's hooks/hooks.json, or the frontmatter of a skill or subagent.
• Exit codes: exit 0 means no objection, exit 2 blocks the action and sends stderr to Claude. Other exit codes let the action proceed on most events.
• Handler types: most hooks are "type": "command". There are also http hooks that POST event data to a URL, mcp_tool hooks, prompt hooks that use a single-turn LLM evaluation, and experimental agent hooks.
• Debugging: run /hooks in a session to browse every configured hook grouped by event.
• Turning them off: set "disableAllHooks": true in your settings file.

Two cautions. Hooks run with your user permissions, so a hook from a plugin you have not read is code you are choosing to run. And a hook cannot override a deny rule: per the permissions docs, a PreToolUse hook that returns allow does not skip deny or ask rules. If you are building a safety setup around hooks, pair them with the settings in my permissions guide.

Hooks and skills compose well. The skill tells the model how to think about a problem. The hook makes sure the resulting action passes a real check. For more events, patterns and debugging tips, see the Claude Code hooks guide.

The Skill Format, Concretely

A skill is a folder with a SKILL.md at the root. The minimum viable skill is twenty lines.

---
name: postgres-migration-reviewer
description: |
  Review Postgres migrations for safety before merging. Use when the user
  is editing a SQL migration file, asking about migration safety, or asks
  to review a database change.
---

When reviewing a Postgres migration:

1. Flag any DROP COLUMN, DROP TABLE, or ALTER COLUMN TYPE as high-risk.
2. Confirm the migration is reversible. If not, the PR description must
   explain why.
3. For any NOT NULL added to an existing column, confirm a backfill exists.
4. For any index added on a table over 10M rows, recommend CREATE INDEX
   CONCURRENTLY.

Always end with a short verdict: SAFE, RISKY, or UNSAFE, with one line on why.

That is a complete skill. The frontmatter tells Claude when to load it. The body tells Claude what to do once it is loaded. If you save that to ~/.claude/skills/postgres-migration-reviewer/SKILL.md, it is available in your next session.

A more sophisticated skill can include supporting files: scripts the skill knows how to run, reference material it quotes, templates for boilerplate. The skill body can point to these files with relative paths and Claude will read them on demand. This is how skills stay small in context while still carrying a lot of structured knowledge.

The thing skills are not good at is anything that needs deterministic execution. A skill cannot guarantee that a check ran. A skill cannot block a commit. If you need a hard guarantee, you need a hook.

I have shipped twenty or so skills now. The pattern that consistently produces good ones is to start by writing the skill as a CLAUDE.md snippet in a real project, use it for a week, watch where Claude does the wrong thing, refine the snippet, then promote it to a packaged skill once it stops surprising you. Skills built without that real-use loop are almost always too abstract and the model ignores them in practice. I broke that entire workflow out into a hands-on guide for writing your first skill, including the SKILL.md anatomy, the trigger-description traps, and the CLAUDE.md promotion path.

When To Build A Plugin Instead Of A Skill

The first question I get from teams adopting this stack is "should I build a plugin or just a skill." The answer is almost always "start with a skill" and the reason matters.

A single skill is a five-minute investment. You write the Markdown, you drop it in your skills folder, you use it. If it works, you keep it. If it does not, you delete it. The cost of being wrong is zero.

A plugin is a longer investment. You write a manifest, you decide on a directory layout, you publish it somewhere, you keep it updated. The cost of being wrong is the time you spent maintaining a packaged thing that nobody used.

The right time to graduate from a skill to a plugin is when one of three things happens.

The first is more than one person needs it. Once your teammate is asking for "that skill you use," the plugin form makes sharing trivial. A loose SKILL.md in your personal folder is fundamentally yours.

The second is the skill needs supporting infrastructure. If your skill works only when an MCP server is also running, or only when a specific hook is firing, you cannot ship the skill alone. The plugin format is the container that bundles all of those pieces together. If the MCP server piece is new to you, the build-your-own-MCP guide walks through the exact stdio setup most plugins bundle.

The third is you want versioned releases. A plugin can set a version in its manifest, and users stay on that version until you change it.

Outside those triggers, a skill is the right move. Most of what teams call "we should build a plugin" is actually "we should write three skills and see which one survives."

Plugin Provenance: The Security Story Under The Marketplace

When you install a plugin, you are installing instructions that the model will follow, and often code that runs on your machine. The docs say it directly: a plugin you install can run code with your user privileges.

A malicious plugin can include a hook that pipes your file contents to an external server. It can include a skill that tells Claude to do something you did not ask for. It can include an MCP server that proxies your local tool calls through someone else's process. The capability is there from day one.

The defensive moves are the same ones that mature ecosystems eventually adopt. Read the manifest, the hooks and the MCP server configs of any plugin before you install it. The install panel shows what the plugin adds before you confirm, so use it. Pin marketplaces and plugins to a tag or version where you can (/plugin marketplace add your-org/plugins#v1.2.0 pins a tag). Treat plugin updates the way you treat dependency bumps, with at least a glance at the diff. In a regulated environment, run a private marketplace that mirrors only the plugins you have audited, and use managed settings to allowlist marketplaces.

This is the same defense pattern that applies to AI-generated code security risks. The model and the plugins around it have access to your tools. Trust is not the default. Trust is a thing you earn from sources you have inspected.

I have seen one team get bitten by a plugin that quietly added a hook capturing every prompt and shipping it to an analytics endpoint. The analytics endpoint was the maintainer's own; the intent was telemetry, not malice. The team only found out because their network monitoring caught the outbound traffic. The lesson is not "do not trust plugins." The lesson is "trust plugins the way you trust npm packages, which is carefully."

Building And Shipping Your Own Plugin

Once you have used the marketplace for a few weeks, you will find yourself wanting to ship your own. The flow is friendly. Start with a folder:

my-plugin/
  .claude-plugin/
    plugin.json
  skills/
    my-skill/
      SKILL.md
  hooks/
    hooks.json
  .mcp.json

Only plugin.json goes inside .claude-plugin/. Everything else sits at the plugin root. If you put skills/ inside .claude-plugin/, the plugin loads but its skills are missing, which is the most common mistake in the troubleshooting docs.

The manifest only requires a name, which also becomes the prefix on every skill:

{
  "name": "my-plugin",
  "description": "Skills and hooks for my team",
  "version": "1.0.0",
  "author": {
    "name": "Your Name"
  }
}

The hooks/hooks.json file has a top-level "hooks" key with the same shape as the hooks block in a settings file.

Test it without installing anything. --plugin-dir loads a plugin for one session:

claude plugin validate ./my-plugin
claude --plugin-dir ./my-plugin

Edit the plugin while the session is open and run /reload-plugins to pick up changes. There is no build step. The plugin is just files.

When it is ready to share, you have three routes: send the folder or a zip to a few people, list it in your own marketplace, or submit it to Anthropic's directory. A marketplace is a repo with a .claude-plugin/marketplace.json:

{
  "name": "my-marketplace",
  "description": "Plugins for my team",
  "owner": {
    "name": "Your Name"
  },
  "plugins": [
    {
      "name": "my-plugin",
      "source": "./plugins/my-plugin",
      "description": "Skills and hooks for my team"
    }
  ]
}

Run claude plugin validate ./my-marketplace after every edit. Teammates then run claude plugin marketplace add your-org/your-repo and claude plugin install my-plugin@my-marketplace. Keep the entry name in the marketplace file the same as the name in the plugin's manifest, or installs by name fail. You do not need a central registry. The Git repo is the registry.

For plugins that survive past their first month, version them with semver and keep a CHANGELOG.md. The ecosystem is young enough that none of this is enforced, but the signal that you take maintenance seriously is what tips a team from "I will read the code first" to "I will trust the install."

What I Recommend On A Clean Machine

If you are starting from zero, here is the short stack I would set up today.

From the official marketplace: commit-commands and code-review, plus a language server plugin for your main language.

From Anthropic's skills repo: example-skills, then keep the two or three skills that match your daily work. For me that is frontend-design.

From your stack's vendor, if it publishes a plugin: one install instead of hand-wiring an MCP server.

From your own repo: a private plugin with your team's CLAUDE.md content broken into skills, plus any hooks that enforce your local conventions, such as the formatter hook above. Even a single-skill private plugin pays back the setup cost within a week.

Then run claude plugin details on what you installed and disable anything you do not use. The Installed tab also flags plugins that have not been used recently.

The honest read on the marketplace as a whole is that it is genuinely good, and also genuinely early. The plugins that work are excellent. The ones that do not work waste a session you cannot get back. Read what you install.

What This Changes For Developer Tooling

Step back from the implementation details for a second. The marketplace is the first time AI tooling has had a real distribution surface for opinionated workflows. Before this, every team had a CLAUDE.md, a Notion page, a Slack thread of "here is how we use the AI." None of it travelled. None of it got versioned. None of it composed.

The marketplace solves the distribution problem. It does not solve the quality problem, the security problem, or the discovery problem. Those are still open. But distribution is the prerequisite that the rest of the ecosystem can build on, the same way npm being good did not automatically make every npm package good, but did make the package ecosystem possible.

If you only do one thing after reading this post, install three things this week. One plugin from the official marketplace, one skill from Anthropic's skills repo, and one hook of your own. Run them for a week. See what changed in your workflow. The first marketplace shift will not feel like a productivity revolution. It will feel like the thing you used to type into your system prompt now lives somewhere a teammate can install. Quiet. Composable. The kind of change that compounds.

Frequently Asked

What are Claude Code plugins? Directories that package skills, subagents, hooks and MCP servers with a manifest at .claude-plugin/plugin.json. Claude Code installs and loads them as one unit, usually from a marketplace.

How do I install a Claude Code plugin? Run /plugin install <plugin>@<marketplace> in a session, for example /plugin install commit-commands@claude-plugins-official, review the details panel and pick a scope. From a shell, use claude plugin install <plugin>@<marketplace>.

What is the difference between a skill and a plugin? A skill is one SKILL.md workflow. A plugin is a package that can hold several skills, plus agents, hooks and MCP servers. You need a plugin to share or version your setup. You do not need one to use a skill yourself.

Is there a Claude skills marketplace? There are several catalogs. Anthropic publishes the official, community and demo plugin marketplaces, and a public skills repo at anthropics/skills. You can browse the web catalog at claude.com/marketplace/plugins, or use the Discover tab in /plugin. Third-party marketplaces are not reviewed by Anthropic.

What are Claude Code hooks? Shell commands (or HTTP, prompt and agent handlers) that Claude Code runs at lifecycle events such as PreToolUse and PostToolUse. A hook that exits with code 2 blocks the action and sends its message back to Claude.

Where do I configure hooks? In ~/.claude/settings.json for all projects, .claude/settings.json for one project, .claude/settings.local.json for local-only, managed settings for an organization, or a plugin's hooks/hooks.json. Run /hooks to see what is active.

Are Claude Code plugins safe? A plugin can run code with your user privileges, so treat one like an npm package. Read what the install panel says it adds, prefer pinned versions, and be careful with third-party marketplaces.

Sources: Anthropic's Claude Code documentation pages on plugins, installing plugins, Anthropic's marketplaces, creating a plugin, creating a marketplace and the hooks guide, checked October 22, 2026.