Read time: ~9 minutes. What you’ll learn: how to go from “ask Claude Code a question” to running it as your daily driver — using CLAUDE.md for persistent memory, Skills for reusable workflows, Subagents for parallel work, Plugins for shareable extensions, and MCP for connecting external tools. Every section has the actual file paths, commands, and the gotcha that bites people.

Most people use Claude Code the way they used the first chat assistants: open it, ask a question, copy the answer, close it. That works — but it leaves almost all of the leverage on the table.

The difference between “I tried Claude Code” and “Claude Code is my daily driver” comes down to five features that most users never touch. Each one moves you from one-off answers to persistent, reusable, delegable work. This guide walks through all five with the exact setup — no hand-waving.

A quick honesty note up front: Claude Code ships fast and some of these surfaces change between versions. Everything below was verified against a live install on May 30, 2026 (and cross-checked against real config files, not just docs). Where a detail is version-sensitive, I say so.

---

1. CLAUDE.md — give your project a long-term memory

The single highest-leverage move. CLAUDE.md is a plain Markdown file that Claude Code reads automatically at startup and injects into context. It’s how you stop re-explaining your project every session.

The three scopes

There are three places a CLAUDE.md can live, and they stack (they’re concatenated, not overwritten):

Scope	Path	Use it for
User (global)	~/.claude/CLAUDE.md	Your personal preferences across all projects
Project (shared)	./CLAUDE.md (or ./.claude/CLAUDE.md)	Team conventions, build commands — check it into git
Local (personal)	./CLAUDE.local.md	Your sandbox URLs, local test data — add to .gitignore

At startup Claude Code walks up from your working directory, collects every CLAUDE.md it finds, and loads them root-first so the most specific file wins. Nested CLAUDE.md files in subdirectories load lazily — only when you start working in those folders.

Pull in other files with @import

You don’t have to cram everything into one file. Reference others with @:

# Project rules

See @README.md for the overview.
Engineering discipline: @docs/engineering.md
Database schema: @~/.claude/shared/db-schema.md

Relative paths resolve against the file doing the importing; absolute paths (@~/...) work too. This is exactly how a well-organized global config stays readable — a short root CLAUDE.md that imports topic files.

What actually belongs in it

# ./CLAUDE.md

# Build & test
- Dev server: `npm run dev`
- Always pass `npm run lint` before `npm test`

# Code style
- TypeScript, strict mode
- API errors return `{ error: string, code: string }`

# Architecture
- Routes in `src/api/routes/`
- Business logic in `src/logic/`

Be specific. “Write clean code” does nothing; “2-space indent, 100-char lines” does. Keep it tight — aim for under ~200 lines. A bloated CLAUDE.md burns tokens every turn and the model follows a long rule list less reliably, not more. Multi-step procedures don’t belong here — those become Skills (next section).

Gotcha: rules drift. A CLAUDE.md that’s accreted six months of contradictory instructions actively hurts. Prune it the way you’d prune dependencies.

---

2. Skills — turn a repeated workflow into a command

CLAUDE.md is for facts. Skills are for procedures — a multi-step workflow you run again and again. Instead of re-typing “scrape this article, name the images, generate markdown” every time, you package it once.

Creating one

A skill is a directory with a SKILL.md inside it:

~/.claude/skills/my-skill/      # user-level (all projects)
  └── SKILL.md
# — or —
./.claude/skills/my-skill/      # project-level (this repo only)
  └── SKILL.md

The SKILL.md frontmatter is minimal — and this is where I’ll correct a common mistake. The real, verified frontmatter is just name and description:

---
name: summarize-git-changes
description: Summarize uncommitted git changes and flag risky patterns. Use when asking what changed.
---

## Instructions

1. Run `git diff HEAD` and list changed files (added / modified / deleted)
2. Give each file a 1–2 sentence summary
3. Flag risks: missing error handling, hardcoded values, untested paths

If there are no changes, say so.

The description does double duty: it shows up in the help list, and it’s how Claude decides when this skill is relevant. Write it like a trigger condition (“Use when…”), not a title.

How it fires

Two ways:

• You invoke it by typing /my-skill (optionally with arguments). Good for fixed rituals like /deploy.
• Claude invokes it when your request matches the description. You say “what did I change?” and it reaches for summarize-git-changes on its own.

Skill or CLAUDE.md?

You have…	Put it in…
A short fact (style rule, architecture note)	CLAUDE.md
A repeatable multi-step procedure or checklist	a Skill

Rule of thumb: if you’d write it as a numbered list, it’s a skill.

---

3. Subagents — delegate and run work in parallel

A subagent is a separate Claude instance with its own context window. You use them for two things: parallel fan-out (search five places at once) and context isolation (do a noisy, search-heavy task without flooding your main conversation with logs you’ll never reread).

How they run

In day-to-day use you usually don’t launch them manually — Claude delegates when it judges a task fits. The clearest example: Plan Mode spins up a read-only research agent automatically. There are built-in agent types for different jobs:

Built-in	Model	Tools	Best for
Explore	Haiku	read-only	Fast, cheap codebase searches — “where is X handled?”
Plan	inherits	read-only	The research phase of Plan Mode
general-purpose	inherits	full	Complex tasks that need to read and write

When it’s worth it

• ✅ The task produces a lot of intermediate output (search results, file dumps) you only need the conclusion of
• ✅ You want a cheaper model (Explore runs on Haiku) or a restricted toolset for one slice of work
• ❌ The task is just a continuation of what you’re already doing — then a subagent only adds overhead

Cost reality

Each subagent opens its own context window and is billed independently. Explore is cheap by design (Haiku + read-only); general-purpose inherits your main model, so it costs the same as the main session. And they don’t nest — a subagent can’t spawn another subagent.

You can define custom subagents under ~/.claude/agents/, but the exact file format is version-sensitive — check the current official docs before scripting one, rather than copying a frontmatter block that may be stale. The built-ins above cover the vast majority of real use.

---

4. Plugins — package and share extensions

A Skill is great for you. A Plugin is how a skill (or a whole bundle of skills, agents, hooks, and MCP servers) gets versioned and shared — across your team or the community.

The commands

/plugin                              # interactive UI (Discover / Installed / Marketplaces / Errors)
/plugin install <name>@<marketplace> # install
/plugin uninstall <name>@<marketplace>

Plus marketplace management — a marketplace is just a Git repo that lists installable plugins:

/plugin marketplace add owner/repo   # add a marketplace (e.g. a GitHub repo)
/plugin marketplace list

Install syntax is always name@marketplace:

/plugin install github@claude-plugins-official

Plugin vs Skill

	Standalone Skill	Plugin
Lives in	~/.claude/skills/	its own repo/dir, installed via /plugin
Command name	/skill-name	/plugin-name:skill-name (namespaced)
Sharing	copy by hand	/plugin install, version-controlled
Can bundle	just the skill	skills + agents + hooks + MCP servers

The practical heuristic: for a behavior rule or a quick personal workflow, a standalone skill (or even just lines in CLAUDE.md) is enough — don’t install a plugin for it. Reach for a plugin when you need a vertical capability (image generation, scraping, a hosted API) or you’re distributing to a team.

---

5. MCP — connect Claude Code to the outside world

Model Context Protocol (MCP) is how Claude Code talks to external systems — GitHub, your database, Stripe, internal APIs — through a standard interface. Once a server is connected, its tools just appear and Claude uses them automatically.

Adding a server

The easiest path is the CLI. Two transport types cover almost everything:

Remote HTTP server (cloud APIs — recommended where available):

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer ghp_xxxxx" \
  --scope project

Local stdio server (a command running on your machine — e.g. a local DB):

claude mcp add --transport stdio db -- npx @bytebase/dbhub \
  --dsn "postgresql://user:pass@localhost/mydb"

Note the shape: all options come before the server name, then --, then the command and its args.

Where the config lives

Scope	File	Use for
Project (team)	.mcp.json in the repo	Production servers, checked into git
User / local (personal)	~/.claude.json	Cross-project or experimental servers

A project .mcp.json looks like this:

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ghp_xxxxx" }
    },
    "db": {
      "type": "stdio",
      "command": "npx",
      "args": ["@bytebase/dbhub", "--dsn", "postgresql://localhost/mydb"]
    }
  }
}

Verify connections in-session with /mcp.

stdio vs HTTP, quickly

• stdio: a local process. Reliable, no auth dance — best for personal scripts and local databases.
• HTTP: a remote endpoint. Supports OAuth — best for cloud APIs like Stripe or GitHub.

The gotcha that bites everyone: auth / login state. Interactively-authenticated servers can drop their session and silently stop working. If a server’s tools vanish, run /mcp and re-authenticate. For headless or scheduled runs, an interactively-logged-in server may simply be absent — don’t assume a server that works in your terminal works in a cron job. Also watch large outputs: a chatty server can blow past the output limit; bump MAX_MCP_OUTPUT_TOKENS or make the server paginate.

---

Stringing it together: one real day

Here’s how the five compose, not as a feature list but as a workflow:

1. You open a repo. Its CLAUDE.md already tells Claude the build commands, the architecture, and that errors return a standard shape — no re-explaining.
2. You ask “where do we handle webhook retries?” — Claude fires an Explore subagent (Haiku, read-only) that greps the codebase and hands back just the answer, no log spam in your main thread.
3. You finish a feature and type /summarize-git-changes — your Skill runs git diff, summarizes it, and flags a hardcoded timeout you forgot.
4. You need the open PR’s review comments — your GitHub MCP server pulls them in directly; no copy-pasting from the browser.
5. Your teammate clones the repo and runs /plugin install for the team bundle — same skills, same agents, same MCP config, zero setup doc.

That’s the daily-driver loop: persistent context, delegated search, one-command rituals, live external data, shareable setup.

---

What not to do

Each feature has a failure mode worth naming:

• CLAUDE.md bloat. More rules ≠ better adherence. Past ~200 lines, signal drowns in noise. Prune ruthlessly.
• Skill-ifying one-liners. If it’s a single fact, it’s a CLAUDE.md line, not a skill directory.
• Subagents for everything. They add latency and cost. Use them for fan-out and noisy isolation, not for work that’s just the next step of your conversation.
• Plugin for a personal rule. Don’t install a plugin to enforce a code-style preference — that’s three lines in CLAUDE.md.
• Trusting an MCP server you didn’t vet. A stdio server runs commands on your host. Read what it does before you connect it, and never enable an untrusted one.

---

The takeaway

The jump from “I tried Claude Code” to “Claude Code runs my day” isn’t about prompting harder. It’s about persistence and delegation: write the project’s memory once (CLAUDE.md), package the procedures you repeat (Skills), hand off the noisy work (Subagents), share the setup (Plugins), and wire in the systems you actually use (MCP). Set those up once and every session after starts from a much higher floor.

If this resonates with how you think about AI-assisted coding, two related reads: using AI to write better code more slowly on why slower-but-auditable beats fast-but-opaque, and constraint decay in LLM coding agents on why agents drift on long tasks — both of which these features directly help you manage.

Sources

• Claude Code (Anthropic) — official product page
• Model Context Protocol — MCP spec and server directory
• Details verified against a live Claude Code install and real config files, 2026-05-30. Version-sensitive surfaces (custom subagent file format, evolving frontmatter fields) are flagged inline — check the official docs for the latest.