MCP Isn't Enough: Skills, Hooks, Plugins, and Packaged Workflows

The Model Context Protocol solved one problem well: connecting an agent to external tools and data. But MCP is plumbing — it lets the agent reach your GitHub, database or Figma. It does not capture how your team works: the workflow you re-type every day, the rule that must hold without exception, the domain knowledge the agent keeps missing. That is the layer above MCP, and in Claude Code it is built from three things — skills, hooks and plugins.

If you are new to MCP itself, start with the connection layer before building on top of it.

Read: MCP Explained Simply

Skills: turn a repeated prompt into a reusable workflow

A skill packages domain knowledge or a repeatable workflow the agent loads on demand. Per the Claude Code docs, skills "extend Claude's knowledge with information specific to your project, team, or domain," and Claude "applies them automatically when relevant, or you can invoke them directly with /skill-name." You create one by adding a SKILL.md to .claude/skills/:

---
name: api-conventions
description: REST API design conventions for our services
---
# API Conventions
- Use kebab-case for URL paths
- Use camelCase for JSON properties
- Always include pagination for list endpoints
- Version APIs in the URL path (/v1/, /v2/)

Skills can also be invocable workflows with side effects — a fix-issue skill that runs gh issue view, finds the relevant files, implements a fix, writes tests, and opens a PR, triggered with /fix-issue 1234. The docs recommend disable-model-invocation: true for workflows with side effects you want to trigger manually.

The reason skills beat stuffing everything into CLAUDE.md is context cost. CLAUDE.md is loaded every session; skills "load on-demand only when invoked," so moving specialized instructions into skills "keeps your base context smaller." The docs advise keeping CLAUDE.md under 200 lines and pushing sometimes-relevant workflows into skills.

Hooks: make a rule deterministic, not advisory

A CLAUDE.md instruction is a request; a hook is a guarantee. Per the docs, hooks are "user-defined shell commands that execute at specific points in Claude Code's lifecycle," providing "deterministic control... ensuring certain actions always happen rather than relying on the LLM to choose to run them." This is the difference that matters: "Unlike CLAUDE.md instructions which are advisory, hooks are deterministic and guarantee the action happens."

Hooks fire on lifecycle events — PreToolUse, PostToolUse, UserPromptSubmit, Stop, SubagentStop, SessionStart, SessionEnd, Notification, PreCompact — and you configure them in settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "~/.claude/hooks/check.sh" }]
      }
    ]
  }
}

Typical uses: run a linter after every file edit (PostToolUse), block writes to a protected directory (PreToolUse), or run a verification check before a turn ends — the docs note a Stop hook "runs your check as a script and blocks the turn from ending until it passes." Claude can even write hooks for you: "Write a hook that runs eslint after every file edit" or "Write a hook that blocks writes to the migrations folder." The mental rule from the docs: use hooks "for actions that must happen every time with zero exceptions."

Plugins: package the whole bundle for the team

A plugin is how you ship skills, hooks, subagents and MCP servers as one installable unit. Per the docs, plugins "bundle skills, hooks, subagents, and MCP servers into a single installable unit from the community and Anthropic," added "without configuration" — you browse the marketplace with /plugin. This is the distribution layer: instead of every teammate hand-configuring the same skills and hooks, you package them once and install with a command. A code-intelligence plugin, for instance, gives the agent "precise symbol navigation and automatic error detection after edits."

How the layers fit together

The progression is: MCP gives the agent reach, skills give it your team's knowledge and workflows on demand, hooks give it non-negotiable guardrails, and plugins let you ship all of it so the next engineer inherits the setup instead of rebuilding it. The features-overview docs frame the choice directly: match the feature to the goal — knowledge and workflows go in skills, must-happen-every-time rules go in hooks, reach goes through MCP, and the package goes in a plugin.

FAQ

Isn't MCP enough on its own?

No. MCP connects the agent to tools and data, but it does not encode your workflows, your non-negotiable rules, or your team's domain knowledge. Skills, hooks and plugins are the layer that does.

When should I use a skill vs put it in CLAUDE.md?

Put broadly-applicable essentials in CLAUDE.md (kept under ~200 lines, loaded every session). Put specialized or occasional knowledge and workflows in skills, which load on demand and keep your base context small.

When do I need a hook instead of an instruction?

When the action must happen with zero exceptions. CLAUDE.md instructions are advisory; hooks are deterministic shell commands tied to lifecycle events (PreToolUse, PostToolUse, Stop, and others) that guarantee execution.

What does a plugin bundle?

Skills, hooks, subagents and MCP servers as a single installable unit, so your whole team gets the same setup without configuring each piece by hand. Browse them with /plugin.

Bottom line

MCP is the connection layer, not the whole stack. The reusable-workflow layer sits above it: skills carry your team's knowledge and repeatable workflows on demand, hooks enforce the rules that must hold every time, and plugins package the lot so it travels. Stop re-typing the same prompt — capture it as a skill, guard it with a hook, and ship it as a plugin.

Sources and further reading