Claude Code as a Daily Driver: A Practical Guide to CLAUDE.md, Skills, Subagents, and MCP

Coding agents have crossed from novelty into serious daily use — Simon Willison argued in late May 2026 that the leading AI labs have found genuine product-market fit for exactly this kind of tool. If you have decided Claude Code is going to be part of your everyday workflow, the next question is the practical one: how do you configure it so it earns its place instead of getting in the way?

This guide is opinionated and concrete. It defines the primitives you will actually touch — CLAUDE.md, skills, subagents, plugins, and MCP — explains when each one is worth the cost, and is honest about where the agent's limits are. The goal is a setup that makes Claude Code reliable on real work, not a pile of configuration you stop trusting after a week.

What is Claude Code — and what counts as an "agent" anyway?

Before configuring anything, it helps to use the vocabulary correctly, because the words get thrown around loosely. Hugging Face's agent glossary draws the distinctions cleanly:

A model is the LLM itself. On its own it has no memory between calls, no loop, and simply answers one prompt and stops.
A harness is the execution layer that makes the model run: it calls the model, handles tool calls, and decides when to stop.
Scaffolding is what the model works from: the system prompt, tool descriptions, and how its output is parsed. The most common confusion is harness vs. scaffold — scaffold is the instructions and format the model reasons over; harness is the machinery that executes the loop.
An agent = model + harness — the complete system that lets a model act in a loop, not just respond.

Claude Code is that complete system, plus a set of configuration surfaces you control. Two more glossary terms matter here. Skills are reusable, structured packages of knowledge for multi-step tasks, portable across agents and loaded on demand. Subagents are agents called by another agent: a subagent has its own model and scaffold, reasons independently, and returns a result — the caller acting as an orchestrator. Keep those definitions in mind; the rest of this guide is about configuring each one well.

How should you write a CLAUDE.md file?

The single highest-leverage file is CLAUDE.md, and the guidance from the Claude Code daily-driver writeup is to keep it minimal. Anthropic's own CLAUDE.md focuses on just three things: build commands, workflow steps, and documented gotchas — nothing else.

The test for every line is sharp: "Would removing this cause Claude to make a mistake?" If the answer is no, the line is noise that dilutes the instructions that matter. A bloated CLAUDE.md is not more helpful; it is harder for the model to follow.

The most powerful habit is to let the file grow from real errors. When Claude makes a mistake, tell it to update CLAUDE.md so the same mistake cannot recur. The writeup notes Claude is surprisingly good at distilling its own errors into precise rules, and over weeks this compounds into a curated, battle-tested list of gotchas specific to your codebase.

What goes in CLAUDE.md versus CLAUDE.local.md?

CLAUDE.md is for the team and the repository. For yourself, keep a machine-local CLAUDE.local.md that captures recurring PR feedback and your personal habits — the quirks that are about how you work, not about the project. Prune it as those habits become automatic. This personalizes the agent to you without cluttering the shared guidance everyone else inherits.

When should you turn something into a Skill?

Skills are how you move Claude Code from general-purpose to specialized. The rule of thumb from the daily-driver guide is memorable: "If you do something more than once a day, turn it into a skill."

The payoff is twofold. First, you stop re-explaining the same multi-step procedure. Second — and this is the part teams underrate — you should check skills into version control. Once they live in the repo, new team members inherit your accumulated practices the moment they clone it, instead of rediscovering them. That matches the glossary's framing of a skill as a portable, on-demand package of everything needed to accomplish a goal, distinct from a single tool, which is just one action.

What are subagents good for?

Subagents shine when you need work done in isolated context. The standout pattern from the daily-driver guide is independent review: have one session implement a change, then invoke a fresh subagent to review it. Because the reviewer starts clean, it avoids the implementation bias that creeps in when the same context both writes and judges the code. Give the reviewing subagent read-only tool permissions so it critiques rather than quietly "fixes" things.

This lines up with the glossary definition: a subagent reasons independently with its own model and scaffold and returns a result to the orchestrator. The practical lesson is to reach for a subagent when independence or parallelism is the point — high-stakes reviews, exploring a separate thread of work — not as a default wrapper around every task.

How do you use plugins and MCP without bloat?

Plugins and MCP (Model Context Protocol) servers connect Claude Code to the outside world — live database queries, design tools, error tracking — without leaving the terminal. The discipline the guide insists on: avoid bloat. Every tool you add expands the model's reasoning surface, and a crowded toolset makes the agent slower and less precise about which tool to reach for.

The recommended starting point is deliberately small: GitHub, Context7, and one domain-specific server for your stack. Add more only when a concrete, repeated need justifies the extra surface area. In glossary terms, tool use is how the agent reaches outside itself and the harness routes each call — so think of every MCP server as a permanent addition to what the agent has to reason about, and budget accordingly.

What does a good daily Claude Code workflow look like?

Tying the primitives together, the daily-driver guide describes a repeatable loop:

Use plan mode for exploration before any code changes, so the approach is agreed on first.
Implement with verification checkpoints, rather than letting a long unsupervised run drift.
Review with fresh eyes — invoke /pr-review or a brand-new session so the review is not contaminated by implementation context.

For leverage, the guide suggests maintaining roughly three to five parallel worktrees, so independent streams of work proceed without stepping on each other. The throughline of the whole setup is the same one behind a lean CLAUDE.md and a small MCP roster: keep context focused, and verify instead of trusting a single long run.

Where are the limits — what should you not let Claude Code do?

A daily driver is only trustworthy if you are honest about its ceiling, and the strongest counterweight comes from the argument that Claude is not your architect. The thesis: engineers should design, and agents should implement.

The reasons are worth internalizing:

No contextual judgment. Architecture requires weighing trade-offs against the team, the constraints, the production environment, and even organizational politics. An AI-designed system instead reflects "the median of everything Claude has seen" — generic best practices that may be wrong for your specific situation.
Pathological agreeability. Agents do not push back. They will enthusiastically lay out a design for a questionable approach, where a real architect challenges the requirement and resists unnecessary complexity.
No accountability. When a system fails, "Claude doesn't get paged at 3am." Engineers inherit the consequences of architectures they did not design.

The practical guidance follows directly: use the agent for speed within human-determined parameters, challenge its suggestions with appropriate skepticism, and protect the messy human disagreement that actually produces good architecture. Let Claude Code implement; keep the design decisions yours.

Key takeaways

A productive Claude Code setup is mostly about restraint. Keep CLAUDE.md minimal and let it grow from real mistakes; promote anything you do daily into a checked-in skill; use subagents for independent, isolated review; add MCP servers sparingly; and run a plan → implement-with-checkpoints → fresh-review loop. Above all, draw the line at architecture — the agent is a fast, tireless implementer, not a decision-maker who will be accountable for the result.

If your agent setup touches untrusted data, external tools, or multiple coordinating agents, read the companion piece on AI agent security: supply-chain and multi-agent injection attacks — scoping tools and permissions the way this guide recommends is also your first line of defense. To start building real agent workflows, try Clawvard, and follow our updates for more hands-on Claude Code guidance.