The real power of Claude Code is not what it does out of the box. It is what you can connect to it. Skills, Hooks, and MCP — three extension mechanisms that turn a terminal tool into a workbench that grows with you.
Why You Need Extensions
I thought installing Claude Code was the end of the setup. Then I noticed myself repeating the same things over and over: “run lint before committing,” re-explaining project conventions for every new component, manually copying SQL results to paste into Claude.
Any repetition that happens more than three times should be automated. Claude Code gives you three mechanisms, each solving a different layer of the problem:
| Mechanism | What It Is | Determinism | Best For |
|---|---|---|---|
| Skills | Markdown instruction packs | High but not 100% (advisory) | Domain knowledge, reusable workflows |
| Hooks | Shell script triggers | 100% deterministic | Formatting, linting, security checks |
| MCP | External service connectors | 100% | Databases, APIs, third-party services |
The relationship: Skills teach Claude how to do things. Hooks automatically enforce checks at key moments. MCP connects the outside world. I use Skills the most — I add new ones almost daily.
Skills: Start Here
Skills are the easiest extension to pick up. The principle is almost absurdly simple: create a folder in .claude/skills/, put a SKILL.md file inside, and Claude will automatically load those instructions based on context.
Use /skill-name to invoke a skill manually. Claude also decides automatically whether to load one — say “create a new React component” and Claude loads your react-component skill with its conventions.
Two types of skills. Knowledge-type skills tell Claude “how things are done in this project” — API conventions, code style, project rules. They work like living documentation that Claude actively follows. Workflow-type skills tell Claude “what steps to follow for this kind of task” — like /fix-issue for a standard bug-fixing SOP or /review-pr for a code review checklist. They are structured procedures with clear steps and checkpoints.
Boris has a practical rule: if you do something more than once a day, turn it into a skill or command. I am more aggressive — twice and I write one.
Real example: a /techdebt command. Turn the flow of “discover tech debt → assess impact → create an issue → link to the sprint” into a skill. When you spot technical debt, type /techdebt and Claude walks through the entire process, including priority assessment, GitHub issue creation, and correct labeling.
Key configuration for workflow skills. Workflow skills often perform side-effect operations — creating issues, sending messages, deploying. To prevent Claude from triggering them automatically at the wrong time, add this to the SKILL.md front matter:
---
disable-model-invocation: true
---
With this, the skill only runs when you explicitly call it with /skill-name. Claude will not trigger it on its own.
Installing skills from others. Skills are shareable. Boris maintains a set of high-frequency skills you can install with one command:
mkdir -p ~/.claude/skills/boris && \
curl -L -o ~/.claude/skills/boris/SKILL.md \
https://howborisusesclaudecode.com/api/install
You now have Boris’s daily workflow — his commit conventions, PR templates, code review standards, and more. The community contributes new skills constantly; browse the marketplace with /plugin inside Claude Code.
Best practice: start with the sentence you say to Claude most often. If you find yourself saying “run the tests, format the code, then commit” before every commit, that is a skill waiting to be born. Write those steps into a SKILL.md, and next time it is one slash command.
Hooks: Not a Suggestion — an Enforcement
Skills have an inherent limitation: they are advisory. Claude tries to follow them, but compliance is not 100%, especially late in long conversations where context compression may have dropped early instructions.
I learned this the hard way. I wrote “run eslint after every file edit” in my CLAUDE.md. It worked fine for the first few rounds. Then context got compressed, and the rule silently disappeared.
Hooks exist to solve exactly this.
Hooks vs. CLAUDE.md: the essential difference. Many people write rules in CLAUDE.md like “please run npx eslint --fix after modifying files.” This works most of the time, but Claude occasionally forgets — especially in long conversations after context compression.
CLAUDE.md is advice. Hooks are enforcement. CLAUDE.md influences Claude’s behavior through natural language. Hooks are platform-level mechanisms that trigger shell scripts at specific lifecycle events. Claude cannot skip or ignore them.
Lifecycle hooks:
| Hook | Triggers When | Typical Use |
|---|---|---|
| PreToolUse | Before Claude calls a tool | Block dangerous operations |
| PostToolUse | After Claude calls a tool | Auto-format, auto-test |
| PermissionRequest | User authorization is needed | Auto-approve low-risk operations |
| Stop | Claude finishes a turn | Push it to continue |
| PostCompact | After context compression | Re-inject critical instructions to prevent amnesia |
| PermissionDenied | Auto Mode classifier rejects an action | Log rejected ops, notify user, trigger fallback |
Practical examples:
Auto-formatting after every edit (this is the exact solution to my eslint problem):
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"command": "npx eslint --fix $CLAUDE_FILE_PATH"
}
]
}
}
Auto-approving low-risk operations: route permission requests to a script that evaluates the operation type. Read files and run tests? Auto-approve. Delete files and push code? Still show the confirmation.
Re-injecting critical instructions after compression: after context gets compacted in a long session, a PostCompact hook can automatically re-inject your key rules to prevent Claude from developing amnesia.
Pushing Claude to continue: sometimes Claude stops mid-task and asks “should I continue?” A Stop hook detects this and auto-continues — perfect for unattended batch processing.
You do not need to write hooks from scratch. Tell Claude: “Write a hook that runs eslint after every file edit.” It will generate the config and write it to .claude/settings.json for you.
MCP: Connecting Claude to the Outside World
Skills teach Claude knowledge. Hooks guarantee execution. But both operate inside Claude Code’s internal world. When you need Claude to query a database directly, call an API, or read a design file, you need MCP.
MCP (Model Context Protocol) is Anthropic’s open standard for connecting AI tools to external data sources and services. Think of it as Claude Code’s USB port: plug in different MCP servers, and Claude gains corresponding abilities.
Adding an MCP server:
claude mcp add slack -- npx -y @modelcontextprotocol/server-slack
claude mcp list
Once added, the MCP server’s capabilities appear as “tools” available to Claude. With the Slack MCP, Claude can search messages, send messages, and create channels.
Recommended MCPs:
| MCP | Capability | Use Case |
|---|---|---|
| Slack MCP | Search/send messages | Auto-sync progress, reply to questions |
| Database MCP | Direct database queries | No more manual SQL copy-paste |
| Figma MCP | Read design files | Convert designs directly to code |
| Sentry MCP | Fetch error logs | Claude auto-locates production bugs |
| GitHub MCP | Operate repos/issues/PRs | Automate project management |
Boris has a classic setup: he connects Claude Code to Slack MCP. When someone reports a bug in Slack, Claude automatically reads the bug description, finds the relevant code, attempts a fix, submits a PR, and replies in Slack with “Fixed — PR link here.” Zero human intervention.
MCP configuration lives in .mcp.json at the project root. Commit it to Git and your whole team inherits the same MCP setup on clone. Use environment variables for sensitive tokens — never hardcode them.
Plugins: Packaged Extension Bundles
Skills, Hooks, and MCP work independently. But combined, they are something else entirely. Plugins are exactly that — packaged combinations.
Type /plugin in Claude Code to browse a growing marketplace. Each plugin can bundle skills, hooks, agents, and MCP configs. One install, everything configured.
For example, a “Code Intelligence” plugin might include a skill teaching Claude how to use symbol navigation to understand code structure, a hook that runs type-checking after every edit, and an MCP connecting to a language server for precise symbol information. Three mechanisms, one install, dramatically more accurate code understanding and modification.
Slash Commands: Shortcuts with Pre-Computation
Beyond /skill-name invocations, there is another tool: Slash Commands. Commands live in .claude/commands/ and, unlike skills, can include inline Bash scripts that pre-compute information before Claude reads the prompt.
A /commit-push-pr command might run git diff --stat as a pre-computation step, embed the result in the prompt, then have Claude generate a commit message, push, and create a PR — all from one command. Commands get checked into Git with your code, so the whole team can use them.
Skills vs. Commands — how to choose. Skills are about “knowing what” — Claude applies them automatically or you invoke them manually. Commands are about “doing a sequence” — they include pre-computation steps and emphasize execution flow. Rule of thumb: if Claude needs to know something, use a skill. If Claude needs to do a sequence of things, use a command.
How the Three Mechanisms Work Together
In real projects, these mechanisms often collaborate. Picture this workflow: a bug report arrives in Slack → Claude locates the issue → fixes it → runs tests → submits a PR → notifies the team.
- MCP (Slack) lets Claude receive the bug report and reply with the fix result
- Skill (fix-issue) guides Claude through the standard process of locating and fixing issues
- Hook (PostToolUse) ensures tests and formatting run automatically after every change
Each mechanism is valuable alone. Together, they form a complete automated bug-fix pipeline.
Do not try to build a full extension system on day one. Start with your most painful repetition. Always explaining the same rules? Write a skill. Always forgetting to lint? Add a hook. Always manually shuttling data? Connect an MCP. Add them one at a time, and gradually your Claude Code becomes a workbench tailored precisely to you.