Claude Code is useful the moment you install it. It reads your repo, edits files, and runs commands without any setup. But the gap between someone who installed it last week and someone who’s wired it into their workflow is large, and it comes down to a handful of extension points: MCP servers, skills, subagents, hooks, plugins, slash commands, the status line, and project memory.
This guide is the map. It explains what each feature is for, how they relate, and the order to learn them in. Every section links to a full walkthrough, so treat this as the hub you come back to when you’re deciding which tool fits a problem.
The thing to understand up front is that these features solve different problems, and reaching for the wrong one is the most common mistake. So we’ll start with what each one is actually for.
The mental model
Five extension points, five jobs. Keep these distinct and the rest of Claude Code makes sense.
What each feature is for
| Feature | Job |
|---|---|
| CLAUDE.md | Persistent project context and conventions |
| MCP servers | Connect to external systems (DB, GitHub, browser) |
| Skills | Package a repeatable procedure or knowledge |
| Subagents | Delegate focused work in isolated context |
| Hooks | Run shell commands on agent events |
The shortest way to say it: MCP connects, skills teach, subagents delegate, hooks automate, and CLAUDE.md remembers. Plugins bundle several of these together. If you internalize that, you’ll rarely build a skill when you needed an MCP server, or stand up a server when a skill would do.
CLAUDE.md: start here
Before any of the fancier features, there’s project memory. A CLAUDE.md file at the root of your repo is loaded into context at the start of every session. It’s where you put the things you’d otherwise explain every time: the build command, the test runner, the conventions, the directories that matter, the things not to touch.
This is the highest-leverage, lowest-effort feature in Claude Code. Five minutes writing a good CLAUDE.md saves you re-explaining your project in every conversation. There’s a user-level file too, at ~/.claude/CLAUDE.md, for preferences that follow you everywhere.
Start with setting up CLAUDE.md project memory — it’s the first thing to do in any repo you’ll use Claude Code in regularly.
MCP servers: connect to your tools
The Model Context Protocol is how Claude Code reaches systems outside the codebase. A GitHub server lets it read issues and PRs. A Postgres server lets it query a database. A Playwright server lets it drive a browser. Each capability is a server you connect, not a feature baked into the agent.
If the concept is new, read what MCP actually is for the client/server model and the tools-versus-resources distinction. Then:
- Set up MCP servers on Windows and WSL — the mechanics, scopes, and the Windows
cmd /cgotcha. - The best MCP servers for Claude Code — which ones are worth your context.
- Build your own MCP server — wrap an internal tool in under 40 lines.
Skills: teach Claude your procedures
A skill is a folder with a SKILL.md file that packages a repeatable procedure — your commit format, a review checklist, a release process. Claude reads the short description, and when your task matches, it pulls in the full instructions. The clever part is that skills are loaded on demand, so you can keep a stack of them without paying for the ones you’re not using.
The rule of thumb: if you’ve pasted the same instructions into Claude more than twice, that’s a skill.
- Claude Code skills explained — the format and a worked example.
- How to write a skill — build one from scratch, with the description-writing that makes it trigger.
- The best Claude Code skills and the DevOps-focused set.
Subagents: delegate without the clutter
A subagent is a specialized helper with its own system prompt, its own scoped tools, and optionally its own model. The main thread delegates a focused task — review this diff, map this feature, write these tests — and the subagent does it in a separate context window. What comes back is a clean summary; the noisy exploration never touches your main conversation.
Two payoffs: cleaner context, and cost control through model routing (send high-volume reading to a cheap model, keep the strong model on the main thread).
- The subagents guide — how they work and a complete example.
- How to build a custom subagent — the frontmatter, tool scoping, and testing delegation.
- The best subagents to set up and subagents vs parallel worktrees for scaling.
Hooks: automate the policy layer
Hooks run shell commands automatically on Claude Code events — after a file edit, before a tool runs, when a session starts. They’re how you enforce things that shouldn’t depend on the agent remembering: auto-format after every edit, block a dangerous command, log what happened. Hooks are deterministic, which is exactly why they’re good for guardrails.
See automating workflows with hooks for the events and a working config, and the best hook examples for patterns worth copying.
Slash commands and the status line
Two smaller features that punch above their weight.
Custom slash commands are markdown prompts you trigger by name with /. They’re for the prompts you reuse verbatim — a deploy checklist, a PR description template. Unlike a skill, which Claude can choose to apply, a slash command runs only when you call it. See creating custom slash commands and the best slash commands.
The status line is the customizable bar at the bottom of the terminal. It runs a shell script and can show your model, context usage, cost, and git branch at a glance. See customizing the status line on Windows and top status line setups.
Plugins: bundle and share a setup
Once you’ve built commands, agents, skills, hooks, and a set of MCP servers, a plugin lets you package them together and install the whole thing in one step, usually from a marketplace. It’s the answer to “how do I give my whole team the same Claude Code setup.” The ecosystem is large and uneven, so be selective.
- Install plugins and add a marketplace.
- The best Claude Code plugins.
- Plugins vs skills vs MCP if the layers blur together.
How they fit together
A mature setup uses several of these at once, each doing its job:
A realistic power-user setup
- CLAUDE.md with your build/test commands and conventions
- One or two MCP servers — GitHub, plus a database or Playwright per project
- A few skills encoding your team's procedures
- A code-reviewer and a context-gatherer subagent
- A hook that formats code after edits
- Custom slash commands for the prompts you reuse
You don’t build that on day one. You add each piece when you feel the friction it removes — re-explaining the project (CLAUDE.md), missing tool access (MCP), repeated instructions (skills), cluttered context (subagents), manual steps you keep forgetting (hooks).
For sysadmins specifically
If you’re running Claude Code on servers or admin boxes rather than a dev laptop, the setup and safety considerations differ — user-scope config across machines, tighter permissions, and which MCP servers make sense for ops. The Claude Code setup for sysadmins and MCP servers for sysadmins and DevOps cover that angle, and MCP security best practices is worth reading before you connect anything to real infrastructure.
Where to start
If you read nothing else, do these three things this week: write a CLAUDE.md for your main project, connect the GitHub MCP server, and set up a code-review subagent. That trio alone changes how Claude Code feels. Everything else in this guide is there for when you hit the specific friction it solves.
From here, pick the deep dive that matches what you’re trying to do — the links above each lead to a full walkthrough, and they all point back here.
