The Best Super Powers for Claude Code

Most people I see complaining that Claude Code “feels mid” are using maybe 20% of what it can actually do.

They type a prompt, accept the diff, type another prompt, accept the diff. That is autocomplete with extra steps.

The thing that turned Claude Code from a fancy autocomplete into something I trust on real work is a small set of features that nobody bothers to read about. They are sitting in the docs. They take an hour to learn. After running this setup daily for months, here are the ones I would not give up.

Subagents

Subagents are the single biggest token win I have measured.

Each subagent has its own context window, its own prompt, and its own tool permissions. The main agent plans and integrates. The subagent does the dirty work and returns a summary. According to Anthropic’s docs, they inherit MCP tools by default, so you can scope them tightly without losing capability.

I use them mostly for two patterns. Open-ended file searches like “find every place we call the Stripe webhook” go to an Explore subagent. The thrown-away pile of file reads stays out of my main context. Independent verification, where I want a second opinion on a migration or a security review, goes to a fresh subagent that has not seen my reasoning. That gives me an honest read instead of a yes-machine.

The cost is real. Subagents have startup overhead. For a one-shot grep, just grep. For a five-minute open-ended dig, spawn the agent.

Hooks

Hooks are deterministic code that runs around tool calls and session events. PreToolUse, PostToolUse, SessionStart, Stop, PreCompact.

The reason this matters is hooks cannot hallucinate. If a prompt says “always run typecheck before stopping”, Claude will obey it about 80% of the time. If a Stop hook runs typecheck, it runs 100% of the time. As one writeup put it, hooks are how you turn a soft rule into a hard one.

The ones I keep. A PostToolUse hook that runs tsc --noEmit after any TypeScript edit. A Stop hook that auto-saves session retros to disk so the next session can load them. A PreToolUse hook that blocks edits to generated files.

I use maybe five hooks total. The point is not to automate everything. The point is to stop doing the same three things by hand at the start and end of every session.

Skills

Skills are reusable slash commands packaged as a SKILL.md file with YAML frontmatter and instructions.

The trick is the frontmatter tells Claude when to invoke the skill on its own. So /blog-post runs the full publishing pipeline, but I do not even need to type the slash. If I say “write a post about X”, Claude reads the description, matches it, and runs the skill.

The big shift in 2026 was that custom slash commands got merged into skills. As the docs explain, files in .claude/commands/ still work, but skills in .claude/skills/ are now the recommended approach because the body only loads when invoked. Long reference material costs almost nothing until needed.

What I keep skills for. Multi-step playbooks I run more than twice a week. A /commit skill that drafts the message, runs verify, and stages. A /review skill that loads my review checklist. A /blog-post skill that handles research, voice-matching, and image fetching.

Skills you set with disable-model-invocation: true are user-only. Useful for anything with side effects like deploys or sending Slack messages, where you do not want the model deciding to run it.

Plan mode

Plan mode separates research from execution. Claude analyzes, reads files, and writes a plan to disk. Nothing changes until you approve.

Armin Ronacher noted that a plan in Claude Code is effectively a markdown file in Claude’s plans folder. That framing helped me. It is not magic. It is just a file you read, edit, and approve.

When I use it. Anything multi-file. Anything refactor-shaped. Anything touching production or auth. Skip it for trivial mechanical edits where the plan would be longer than the diff.

The single rule that has improved my outcomes the most. Add this to CLAUDE.md: “if execution diverges from the approved plan, stop and re-enter Plan Mode.” Without this, the model will quietly extend scope mid-task and you will not notice until something breaks.

Press Alt+T while in plan mode to enable extended thinking. For migrations, architecture, and anything where being wrong is expensive, the extra reasoning budget pays for itself.

MCP servers

MCP is how Claude Code reaches outside the terminal. The protocol is the same. The servers are pluggable.

The five I would not work without.

github for PRs, diffs, issues, and file reads without leaving the terminal. supabase for SQL, migrations, and schema reads from chat. context7 for current library docs instead of stale training data. This one alone has cut my “wrong API version” bugs to almost zero. playwright so Claude can browse the deployed site, take screenshots, and verify its own work. sentry for production error triage from chat.

The warning from Anthropic’s best-practices doc still applies. Ten or more MCP servers slows startup and adds token overhead. Install what you actually use and remove the rest. I have culled mine twice this year.

Persistent memory

Memory is what lets Claude carry knowledge across sessions without you writing CLAUDE.md by hand.

It lives in ~/.claude/projects/<project>/memory/ as typed markdown files prefixed with user_, feedback_, project_, and reference_, with a one-line index in MEMORY.md. Claude decides what is worth saving based on whether the fact would be useful in a future conversation.

What it is good for. Facts that survive across sessions. Deployment quirks. Naming conventions. Prior decisions you keep wanting to look up. Feedback the user has given that should not need repeating.

What it is not good for. Code patterns and file paths. Those live in the code. Saving them just creates duplicate truth that goes stale.

The other half of this is CLAUDE.md at the repo root. Stack overview, ownership matrix, hard rules. Aim for under 200 lines. Past that you are putting code-pattern detail in a place where it does not belong.

Where to start

Pick three.

Write a CLAUDE.md with your stack, your conventions, and your “do not touch” list. Add the rule about re-entering plan mode if execution diverges.

Set up two or three skills for the playbooks you run most. Start with whatever you keep pasting into chat.

Use subagents for any task that starts with “find every place where” or “check whether the codebase does”. Those are the open-ended searches that destroy your context if you do them in the main thread.

Hooks, MCP, and memory are all worth adding. Just not on day one. The reason a tight setup works is because the model has fewer distractions, not because every component on a list is installed.

The model is not the variable. The harness is.

Sources: