This post links to Claude Code (an affiliate link) and to my own Claude Code cookbooks. I pay for Claude Max out of pocket and run Claude Code every day, so the recommendations would be the same without the affiliate program.
A guide called "Claude Code as a Daily Driver" hit the top of Hacker News this week, 300-plus points and 200-plus comments, walking through five things you can layer onto Claude Code: CLAUDE.md, Skills, Subagents, Plugins, and MCP servers. It's a good post. But the comment section split the way these threads always do. Half the room treats those five features as five different magic buttons. The other half says "I type into the box and it works fine."
Both are half right. I run an autonomous system on Claude Code. It operates a stack of small products, deploys to Cloudflare, and edits its own config without me babysitting it. So I've had to work out which of these five features earn their place and which are cargo cult. Here's the honest version.
The mental model nobody states up front
These five features aren't a menu of equals. They're layers, and each answers a different question:
-
CLAUDE.mdis always-on context. What should Claude know on every single task? - Skills are on-demand context. What should Claude pull in only when a task matches?
- Subagents are isolation. What work should happen in a fresh context so it doesn't pollute the main one?
- MCP is reach. What systems outside the filesystem should Claude be able to touch?
- Plugins are packaging. How do you install bundles of the above without hand-wiring each piece?
Internalize that much and you'll make better decisions than most of the people arguing in the thread. Everything below is detail.
CLAUDE.md: write less than you think
CLAUDE.md is the file Claude reads at the start of every session. It's persistent, always-on context. The instinct is to write a 400-line codebase tour. That's the mistake.
The filter I use, the one the original post credits to Anthropic's own team, is this: "Would removing this line cause Claude to make a mistake?" If the answer is no, cut it. Anthropic's published CLAUDE.md leans on build commands and workflow order (use bun not npm, typecheck before you commit, the pre-PR ritual) rather than prose about architecture. Always-on context isn't free. Every token in there gets spent on every task, whether it's relevant or not.
The compounding trick: after Claude makes a mistake, tell it to update CLAUDE.md so it doesn't do that again. It's good at writing terse rules for itself. Over a few weeks the file stops being something you maintain and becomes something the tool maintains. That one habit did more for my hit-rate than any prompt tweak.
Skills: the part most people skip, and shouldn't
A Skill is a directory, .claude/skills/<name>/, with a SKILL.md file (YAML frontmatter plus markdown instructions) and optional supporting scripts. The key difference from a plain slash command is that Skills load progressively. Claude reads the one-line description always, but only pulls the full instructions into context when your task matches. So unlike CLAUDE.md, a Skill costs almost nothing until it fires.
The rule of thumb that's served me well: if you do something more than once a day, make it a Skill. Scaffolding an endpoint to your conventions, a TDD loop, a structured debugging routine, anything where you keep re-typing the same brief. Skills can also carry tool restrictions and permission gates that commands can't, so a "do the risky thing" Skill can be scoped tighter than your default session.
This is the layer with the best effort-to-payoff ratio, and the one beginners ignore because CLAUDE.md got all the blog coverage.
Subagents: fresh eyes, on purpose
A Subagent is a separate Claude instance with its own context window. It does a scoped job and returns only the result to your main session. The intermediate reasoning never bloats your main context.
The pattern that matters is chaining for independence. Session A writes the code. Then you invoke a code-reviewer subagent in a clean context with read-only tools and no memory of the implementation, so it reviews the diff without the bias of having written it. I run mine restricted to Read/Grep/Glob/Bash at a higher model tier and told not to nitpick style. It catches the missing null check before a human ever sees the PR. The isolation is the feature. A reviewer that watched you write the code argues for your code.
MCP: the difference between "writes code" and "operates my stack"
MCP (Model Context Protocol) is Anthropic's open standard, out since late 2024, for wiring external tools and data into the model as first-class tools. The USB-for-AI analogy is overused but accurate: one protocol, many tools, many clients.
This is the layer that turned Claude Code from a code generator into something that runs my products. With MCP servers connected, Claude can query a live database, ship a Cloudflare deploy, manage Stripe, or read my notes, not by me pasting output back and forth but as native tool calls. That's the whole reason an autonomous system is possible at all. File editing alone gets you a smart intern. MCP gets you an operator.
The trap, and the comment section was right about this, is that every MCP server you add dilutes tool-selection quality. More tools means more chances to pick the wrong one. The starter set I'd defend is a language-server plugin for code intelligence, a GitHub MCP, and one domain-specific server for whatever you do. Add the fourth only when you feel the pain of not having it.
Plugins: packaging, not magic
A Plugin bundles Skills, hooks, subagents, and MCP servers into one installable unit, namespaced (/my-plugin:review) so two plugins can't collide. You install it from the marketplace.
There's nothing a Plugin does that you couldn't wire by hand. It's distribution, not new capability. Which is exactly why it's useful: a good /code-review or feature-workflow plugin is someone else's tuned setup, shipped to you on day one. Same caution as MCP, though. A bloated tool list degrades decision quality, so install selectively and treat it as part of onboarding, not a sticker collection.
What I'd tell a new user
Start with three lines in CLAUDE.md. Add a Skill the second time you re-type a brief. Add a code-reviewer subagent before you trust it on anything that ships. Add MCP servers one at a time, only when file-editing isn't enough. Ignore Plugins until you've felt the wiring pain yourself. The people getting 10x out of this tool aren't using more features. They're using fewer, on purpose.
If you want the working configs instead of the theory, the CLAUDE.md patterns, Skill templates, subagent definitions, and hook scripts I run, I packaged them in my Claude Code cookbooks. And if you're still deciding between tools, here's my honest Cursor vs Claude Code vs Aider decision tree.
Tool used (affiliate link): Claude Code.
Top comments (0)