Extending Claude Code: Hooks, Skills, MCPs, and Plugins

Extending Claude Code: Hooks, Skills, MCPs, and Plugins

Part of the series: Claude Code: From Zero to Swarm

The limits of a standalone agent

Claude Code out of the box can read your files, write code, and run terminal commands. That covers an enormous amount of ground. You have already seen it build projects, refactor modules, and debug issues by reading your codebase and reasoning about it.

But there are things it cannot do.

It cannot open a browser and check whether your page actually renders correctly. It cannot query your production database to verify that the migration worked. It cannot post a message to Slack when it finishes a long-running task. It cannot follow your team's specific deployment checklist automatically every time you say "ship it."

These are not limitations of the AI's intelligence. They are limitations of what the AI is connected to. Claude is plenty capable. It just cannot reach the things it needs to reach.

The difference between a capable AI and a powerful AI system is not smarts. It is connections. This chapter is about extending Claude Code's reach using four mechanisms: hooks, skills, MCP servers, and plugins. Each solves a different problem, and together they transform Claude Code from a conversational coding partner into an integrated development environment operated by AI.

Hooks: teaching Claude to react automatically

Hooks are the simplest extension. They are shell commands or scripts that Claude Code runs automatically when specific events happen. Think of them as "if this, then that" rules for your AI workflow.

You do not write hooks inside Claude Code. You configure them in a settings file, and Claude Code executes them at the right moment without you needing to ask.

There are four events you can hook into.

PreToolUse fires before Claude reads a file, writes a file, or runs a command. This is your chance to inject context, enforce rules, or block certain actions before they happen. A PreToolUse hook could check whether Claude is about to modify a file it should not touch and stop it.

PostToolUse fires after Claude completes an action. This is where you log what happened, run validation, or trigger follow-up processes. A PostToolUse hook could run your test suite every time Claude edits a test file.

SessionStart fires when a conversation begins — whether that is a fresh startup, a resume, a clear, or a compact. This is how you load project-specific context automatically at the start of every session.

Stop fires when Claude finishes its response. Use this for cleanup, validation, or summaries.

Here is a practical example. Say your team uses ESLint and you want every TypeScript file Claude writes to be linted automatically. You configure a PostToolUse hook that watches for Write operations on .ts and .tsx files. When Claude writes one, the hook runs ESLint on it. If the linter finds issues, that feedback flows back into Claude's context — it sees its own mistakes and can fix them in the next step, without you ever saying "run the linter."

The configuration lives in your settings file as simple JSON. You specify which event to hook into, a pattern to match (which files or commands), and the shell command to run. No code, no framework, no build step.

The insight here connects directly to what you learned in chapter 3. Context engineering is about shaping the information Claude has access to. Hooks automate that shaping. Instead of manually telling Claude to check its work, a hook does it every time, consistently, without you thinking about it. It is context engineering on autopilot.

And hooks go beyond just quality checks. A SessionStart hook could inject your team's current sprint goals at the beginning of every session. A PreToolUse hook could add relevant documentation whenever Claude is about to edit a file in a specific directory. The pattern is always the same: an event happens, your hook runs, and Claude gets better context as a result.

Skills: reusable expertise in a file

If hooks are automated reactions, skills are packaged instructions. A skill is a markdown file that teaches Claude a specific workflow — a debugging methodology, a deployment checklist, a code review process. When Claude encounters a task that matches the skill, it reads the instructions and follows them.

Think of it as handing Claude a recipe card. Instead of hoping Claude knows the best way to debug a failing test, you give it a skill that says: first, reproduce the error. Second, read the error message carefully and identify the failing assertion. Third, check recent changes to the files involved. Fourth, form a hypothesis about what broke. Fifth, make a targeted fix. Sixth, run the test again to verify.

A skill file has two parts. The frontmatter describes when the skill should activate — which file patterns trigger it, what keywords or phrases match it. The body is plain markdown with instructions, constraints, checklists, and patterns that Claude follows when the skill activates.

Here is what makes skills powerful: they encode expertise that would otherwise live in someone's head.

Every team has a senior developer who debugs differently from everyone else — more systematically, fewer wrong turns, faster resolution. That methodology can be captured as a skill. Every team has a deployment process that looks simple on paper but has twelve gotchas that only the person who has done it fifty times knows about. That process can be captured as a skill.

Claude Code ships with built-in capabilities, but the real power is in the growing ecosystem of community-contributed skills. People have packaged their expertise into reusable files that you can install from repositories: debugging skills, testing skills, code review skills, documentation skills. Each one is a workflow someone refined through experience and made available for others — including AI — to follow.

You can also write your own. If your team has a specific way of handling database migrations, a skill can encode that process so Claude follows it every time. If your deployment requires a specific sequence of checks, a skill ensures none of them get skipped. The skill does not replace the expert who created the process. It makes the expert's approach available to everyone on the team, and to every Claude Code session, every time.

The distinction from hooks is worth noting. Hooks are reactive — something happens, a script runs. Skills are directive — Claude encounters a situation and follows a set of instructions. Hooks automate your environment. Skills automate your methodology.

MCP servers: connecting Claude to the outside world

This is where things change fundamentally.

MCP stands for Model Context Protocol. It is a standard way for AI agents to connect to external tools and services. An MCP server is a small program that exposes capabilities through a consistent interface — "I can search the web," "I can query a database," "I can control a browser" — and Claude Code knows how to talk to all of them.

Think of MCP servers as peripherals for your AI. The way you plug a monitor into your computer to give it a screen, you plug an MCP server into Claude Code to give it new abilities.

Let me make this concrete. Install the Playwright MCP server — it takes one line in your MCP configuration file — and then start Claude Code. Now ask:

Open my website at localhost:3000 and check if the homepage renders correctly.

Claude opens a real browser. It navigates to the URL. It takes a snapshot of the page and reads the accessibility tree. Then it describes what it sees — the heading, the navigation, the layout, whether anything looks broken. If something is wrong, it can tell you what and where.

This is not Claude guessing based on your HTML source code. This is Claude looking at the actual running application, the same way you would by opening a browser tab. That is a fundamentally different capability.

Here are a few other MCP servers that change the game:

Postgres or Neon MCP lets Claude query your database directly. Instead of you describing the data problem and Claude guessing, you can say "show me all users who signed up this week but never completed onboarding" and Claude writes and runs the actual query against your actual data.

GitHub MCP lets Claude create pull requests, review code, manage issues, and search repositories. Your workflow stays in the terminal instead of bouncing between Claude Code and the GitHub website.

Notion or Linear MCP lets Claude read your project management tools. When you say "what are the open tickets for the auth module?" Claude pulls the real answer from your real project tracker.

Slack MCP lets Claude search channels, read message history, and send messages. Context from team conversations becomes available to Claude without you having to copy-paste it.

Each MCP server you connect compresses your workflow. Without MCP, the loop looks like this: you describe the problem to Claude, Claude suggests a fix, you apply it, you check the result yourself in a browser or database client, you report back to Claude what you saw. With MCP, the loop is: you describe the problem, Claude investigates directly — opens the browser, queries the database, checks the logs — proposes a fix based on what it actually observed, applies it, and verifies it worked. Minutes become seconds.

The connection to chapter 3 is direct. Context engineering is about giving Claude better information. MCP servers are context engineering taken to its logical extreme — not telling Claude about your system, but letting Claude observe your system directly. The same model, working from facts instead of assumptions, produces dramatically better output.

Installing an MCP server is not complicated. Each one has a configuration block you add to your Claude Code MCP settings — usually a command to start the server and any required credentials. The MCP protocol handles the rest: authentication, input validation, response formatting. You configure once, and every future session has access to that tool.

There are hundreds of MCP servers available, covering everything from cloud infrastructure to email to payment systems. The directory at ryzo.nl/mcps lists curated picks across categories, but the ecosystem is growing fast. If a service has an API, someone has probably built an MCP server for it.

Plugins: bundles that tie it all together

You now know four mechanisms for extending Claude Code: hooks for automated reactions, skills for reusable expertise, MCP servers for external connections, and slash commands for custom actions you can invoke by name. Individually, each is useful. Together, they can define an entire development workflow.

A plugin is the packaging format that bundles them into a single, installable unit.

When you install a plugin, everything inside it activates together. A Vercel plugin might include hooks that inject deployment best practices when you edit configuration files, skills for debugging build failures and optimizing performance, and connections to the Vercel MCP server so Claude can inspect your deployments and logs. You do not configure each piece separately. You install the plugin, and your Claude Code environment gains a complete set of capabilities for working with Vercel.

The structure is straightforward. A plugin lives in a folder with a plugin.json manifest that declares what it provides: which hooks to register, which skills to make available, which MCP servers to connect, which slash commands to add. When Claude Code starts, it reads the manifest and activates everything.

You can have multiple plugins active at once. They compose without conflicting — a Next.js plugin and a testing plugin and a documentation plugin all run side by side, each adding their own hooks, skills, and tools to your environment.

The plugin ecosystem is where this gets interesting at scale. Instead of every developer on your team independently configuring their Claude Code setup — installing the same MCP servers, writing similar hooks, creating overlapping skills — someone packages the team's standard setup as a plugin. New team members install one plugin and their Claude Code environment matches everyone else's. Standards are encoded, not documented. Consistency is automatic, not aspirational.

Community plugins extend this further. There are plugins for specific frameworks, platforms, and workflows. The patterns that experienced developers have refined through practice become installable packages that benefit everyone.

You can also build your own. If your team has a unique deployment pipeline, a custom CRM integration, or a proprietary tool that Claude should know about, a plugin wraps all of that into a shareable unit. The hooks, skills, MCP configurations, and commands that make your team's workflow special become portable.

Putting it together

Four mechanisms, each solving a different problem:

Here is what a realistic Claude Code environment looks like in practice. A developer working on a Next.js application has a framework plugin installed that provides hooks for best practices and skills for common patterns. They have the Playwright MCP connected so Claude can check their pages in a real browser. They have the Postgres MCP connected so Claude can query the development database. And they have a custom skill their team wrote for their specific code review process.

That developer did not build all of this from scratch. They installed two plugins, connected two MCP servers, and wrote one custom skill. Maybe thirty minutes of one-time setup. Every Claude Code session after that benefits from all of it, permanently.

The progression across this series has been deliberate. Chapter 3 taught you to shape what Claude knows — the information and context that drives its responses. This chapter taught you to shape what Claude can do — the tools, workflows, and connections that extend its reach.

The combination of good context and extended capabilities is what transforms Claude Code from a smart chatbot into something closer to an intelligent development environment. An environment that knows your project, follows your team's practices, connects to your running systems, and reacts to its own output.

In the next chapter, we take the final step: what happens when one agent, no matter how well-equipped, is not enough? Multi-agent orchestration — running multiple Claude Code instances that coordinate on larger tasks — is where this series reaches its summit.