Extensions: Skills, Hooks & MCP

The Big Idea

The chapter's claim: Claude Code's real value is not how capable it is out of the box — it is how much you can plug into it. The author noticed he kept repeating himself: reminding Claude to "run lint first" before every commit, re-explaining conventions for every new component, manually copying SQL results to paste back in.

Why This Topic Matters

• Repetitive instructions waste your time and get forgotten mid-session.
• Some checks (lint, security) need 100% certainty, which advice alone cannot give.
• Real work needs data from outside Claude Code: databases, APIs, design files, error logs.
• Extensions accumulate one at a time into a workbench built exactly for you.

Core Concepts: The Three Mechanisms

Topic 1 — Skills (start here)

Skills are the easiest extension to begin with. The idea: create a folder inside .claude/skills/, put a SKILL.md file in it, and Claude automatically loads its instructions based on context.

.claude/skills/
├── react-component/
│   └── SKILL.md   # Standards and steps for creating React components
├── fix-issue/
│   └── SKILL.md   # Standard workflow for fixing bugs
└── deploy-preview/
    └── SKILL.md   # Steps for deploying a preview environment

You can invoke a skill manually with /skill-name, or Claude decides on its own. Say "help me create a new React component" and Claude loads the react-component skill's conventions automatically.

Two types of skills

Simple example: a /techdebt command

Write the whole "spot technical debt → assess impact → create issue → link to sprint" workflow as a skill. Then whenever you find tech debt, type /techdebt and Claude walks through the process: evaluating priority, creating a GitHub issue, applying the right labels.

Key configuration for workflow skills

Workflow skills often do side-effectful things — creating issues, sending messages, triggering deployments. To stop Claude from auto-triggering them at the wrong moment, add this to the front matter of SKILL.md:

---
disable-model-invocation: true
---

What this line does: the skill can now only be invoked manually via /skill-name. Claude will not trigger it on its own.

Installing other people's skills

mkdir -p ~/.claude/skills/boris && \
curl -L -o ~/.claude/skills/boris/SKILL.md \
  https://howborisusesclaudecode.com/api/install

After installing, you get Boris's daily workflows — commit conventions, PR templates, code review standards. You can also browse the community marketplace inside Claude Code with /plugin.

Topic 2 — Hooks (not a suggestion, enforced)

Skills are fundamentally advice. Claude tries to follow them, but compliance is not 100% — especially deep into a long conversation, when a rule may simply be forgotten after context compression. The author learned this the hard way with an "run eslint after every file edit" rule in CLAUDE.md that disappeared once context was compressed.

Lifecycle hooks

Code example: auto-formatting after every edit

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": "npx eslint --fix $CLAUDE_FILE_PATH"
      }
    ]
  }
}

Explaining the code

• "PostToolUse" — run this after Claude uses a tool.
• "matcher": "Edit|Write" — only when the tool was an edit or a file write.
• "command": "npx eslint --fix $CLAUDE_FILE_PATH" — run the linter on the file that was just changed. $CLAUDE_FILE_PATH is filled in by Claude Code.

Result: every file Claude edits is formatted automatically — no relying on Claude to remember.

More hook examples (from the book)

Topic 3 — MCP (a window to the outside world)

Skills give Claude knowledge; Hooks guarantee execution — but both stay inside Claude Code's world. To query a database, call an API, or read a design file, you need MCP (Model Context Protocol), an open standard from Anthropic. The book's analogy: MCP is Claude Code's USB port — plug in different MCP servers, and Claude gains the matching capabilities.

Adding an MCP server

# Add an MCP server
claude mcp add slack -- npx -y @modelcontextprotocol/server-slack
# List installed MCPs
claude mcp list

Once added, the server's capabilities appear to Claude as "tools." After the Slack MCP, for example, Claude can search Slack messages, send messages, and create channels.

Recommended MCPs to start with

Boris's classic setup: Claude Code connected to the Slack MCP so that when someone reports a bug in Slack, Claude reads the description, finds the code, attempts a fix, submits a PR, and replies "Fixed — PR link here." No human intervention.

Code example: the MCP configuration file

// .mcp.json  (at the project root)
{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_TOKEN": "${SLACK_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "${DATABASE_URL}"]
    }
  }
}

Explaining the code

• .mcp.json lives at the project root and can be committed to Git — teammates who clone the project get the same MCP setup.
• Each entry under mcpServers is one server: the command and args that launch it.
• "env" passes secrets via environment variables like ${SLACK_TOKEN} — never hardcoded.

Topic 4 — Plugins (pre-packaged extensions)

Skills, Hooks, and MCP are each useful alone; combining them is where it gets powerful. A Plugin is a packaged combination of all three. Type /plugin to browse the marketplace; one install sets everything up. Example — a "Code Intelligence" plugin might include:

• a skill that teaches Claude symbol navigation,
• a hook that runs type-checking after edits,
• an MCP that connects to a language server for precise symbol information.

Topic 5 — Slash Commands (shortcuts with pre-computation)

Commands live in .claude/commands/. Unlike skills, commands can include inline Bash scripts that run before Claude reads the prompt, embedding the results into it.

# .claude/commands/commit-push-pr.md
Help me complete the following:
1. Review the current git diff:
```bash
git diff --stat
```
2. Generate a commit message and commit
3. Push to the remote branch
4. Create a Pull Request with a title based on the commit content
Note: The PR description should include a summary of the changes.

Type /commit-push-pr and Claude runs the whole workflow. Because the file lives in .claude/commands/, it is committed with Git and available to every team member.

Skills vs. Commands: a decision guide

How the Three Mechanisms Work Together

Team workflow: receive bug report → locate the issue → fix it → run tests → submit PR → notify stakeholders.

• MCP (Slack) lets Claude receive bug reports and reply with results.
• Skill (fix-issue) guides Claude through a standard process for locating and resolving the issue.
• Hook (PostToolUse) ensures tests and formatting run automatically after every change.

Each piece is valuable alone; combined they form a fully automated bug-fix pipeline.

Real-World Use Cases: 60+ Skills in Practice

The author has over 60 Skills installed, accumulated over six months, each squeezed out by a real need.

The first skill: three-pass proofreading

Before Skills, he dictated the same wall of instructions for every article: "reduce the AI tone, no em-dashes, avoid filler phrases, check for fabricated data, go through every paragraph." So he wrote huashu-proofreading:

# SKILL.md core structure (simplified)
Three-pass proofreading workflow:

Pass 1: Factual verification
- Are all data points, dates, and product names accurate?
- Is anything fabricated?

Pass 2: Reduce AI tone
- Check for 6 categories of AI-speak: excessive em-dashes, triple parallel structures, ...
- Banned phrases: "to put it simply," "in other words," "simply put" ...

Pass 3: Style refinement
- quotation mark conventions
- Bold key sentences (~10 per article)
- Paragraph density check

Result: proofreading went from 15 minutes of verbal dictation to a single /proofreading command — and the rules no longer vanish when context gets compressed.

A whole content-creation pipeline as skills

Other examples: huashu-book-pdf handles the full ebook pipeline (research → chapter planning → multi-agent parallel writing → HTML assembly → EPUB → upload); huashu-video-director goes from concept to a multi-shot AI-generated video; huashu-script-polish rewrites scripts into natural spoken language over three review rounds.

Visual Mental Model

            ┌──────────── Claude Code ────────────┐
 SKILLS ───►│  "here is HOW to do X"  (advisory)   │
 HOOKS ────►│  shell scripts at lifecycle points   │───► 100% enforced
   MCP ────►│  USB port to DB / API / Figma / logs │───► outside world
            └─────────────────────────────────────┘
 PLUGIN  = skill + hook + MCP, packaged, one install
 COMMAND = macro in .claude/commands/, can pre-run Bash

Important Comparisons

Common Beginner Mistakes

• Assuming Claude Code is "just what it is out of the box" and never extending it.
• Putting must-always-happen checks in CLAUDE.md (advisory) instead of a Hook (enforced).
• Letting workflow skills auto-trigger side effects — forgetting disable-model-invocation: true.
• Hardcoding tokens in .mcp.json instead of using environment variables.
• Adding an MCP without checking what data it can access.
• Trying to build a comprehensive extension system all at once instead of one painful task at a time.
• Writing skills for humans to skim rather than for the AI to execute line by line.
• Confusing skills and commands — "know something" vs "do a sequence of things."

Best Practices

• Start with Skills — the easiest extension. Begin with the sentence you say most often.
• Automate anything you have done more than once a day (Boris) — or twice (the author).
• Add disable-model-invocation: true to side-effectful workflow skills.
• Use Hooks for anything that must be 100% certain: lint, tests, security, post-compaction re-injection.
• Ask Claude to write your hooks: "Write a hook that runs eslint after every file edit."
• Use MCP to stop shuttling data by hand; commit .mcp.json so the team shares the setup.
• Keep secrets in environment variables; review each MCP's data access.
• Use a Command for a fixed sequence with pre-computation; a Skill for knowledge.
• Add extensions one at a time, driven by real pain.

Interview / Revision Questions

1. What are the three extension mechanisms, and what does each one do in one phrase?
2. Which mechanism is advisory, and which is 100% enforced? Why does that difference matter?
3. Where do skills live, and how are they invoked?
4. What is the difference between a knowledge-based skill and a workflow-based skill?
5. What does disable-model-invocation: true do, and when do you need it?
6. Name three lifecycle hooks and a typical use for each.
7. Explain the auto-format hook example line by line.
8. What is MCP, and what is the book's analogy for it?
9. Why should tokens never be hardcoded in .mcp.json?
10. What is a Plugin, and how does it relate to skills, hooks, and MCP?
11. Skills vs. Commands — what is the rule of thumb?
12. Walk through the automated bug-fix pipeline and name which mechanism does each step.

Practice Exercises

Quick Memory Map

Extensions: Skills, Hooks & MCP
│
├── Skills  (advisory, Markdown)      -> teach HOW
│   ├── .claude/skills//SKILL.md
│   ├── knowledge-based | workflow-based
│   ├── /skill-name  OR auto-loaded
│   └── disable-model-invocation: true  (side effects)
│
├── Hooks  (100% enforced, shell)     -> guarantee checks
│   ├── PreToolUse / PostToolUse / PermissionRequest
│   ├── Stop / PostCompact / PermissionDenied
│   └── config in .claude/settings.json
│
├── MCP  (external connectors)        -> the outside world
│   ├── "USB port": Slack, DB, Figma, Sentry, GitHub
│   ├── claude mcp add / claude mcp list
│   └── .mcp.json + env vars (never hardcode tokens)
│
├── Plugins  = skill + hook + MCP, packaged (/plugin)
└── Commands = macros in .claude/commands/ (pre-run Bash)
    Rule: "know something" -> skill ;  "do a sequence" -> command

Complete Chapter Revision

1. Claude Code's power comes from what you plug into it.
2. Skills teach it how (advisory), Hooks enforce checks (100%), MCP connects it to external systems (100%).
3. Skills are Markdown packages in .claude/skills/, knowledge-based or workflow-based, invoked by /name or automatically.
4. Add disable-model-invocation: true so side-effectful skills only run when you ask.
5. Skills are shareable; browse the marketplace with /plugin.
6. CLAUDE.md is advisory and can be forgotten; Hooks are platform-level and cannot be skipped.
7. Hooks fire at lifecycle points (PreToolUse, PostToolUse, PostCompact, Stop, etc.); configure them in .claude/settings.json, or ask Claude to write them.
8. MCP is the "USB port" — Slack, database, Figma, Sentry, GitHub. Config in .mcp.json, secrets via env vars.
9. Plugins package skills + hooks + MCP for one-step install.
10. Commands are macros with pre-computation; use skills for knowledge, commands for sequences.
11. All three combine into automated pipelines (e.g. Slack bug → fix skill → test hook → Slack reply).
12. Build your system one painful task at a time; skills are written for the AI to execute, not for you to skim.

Final Takeaway

This teaching edition is based on the supplied April 2026, 2nd edition of Claude Code: The Complete Guide (§07, "Extensions: Skills, Hooks & MCP"). File paths, config keys, hook names and package names reflect that edition and may change over time.