The prompt is not the skill. It's the part everyone practices and the part that matters least.
What actually determines whether Claude Code ships something reliable or something that merely looks finished happens before and after the prompt: what it read before you asked, what it's allowed to touch without asking, and what closes the loop when it says it's done. Get those three right and the wording barely matters — vague prompts and precise ones converge on similar output. Get them wrong and no amount of prompt engineering saves you.
The reason to trust this framing isn't just Anthropic's documentation. It's that Anthropic's documentation and how the tool's own creator, Boris Cherny, actually works day to day land on the same small set of habits independently. When the people who wrote the manual and the person who uses the tool hardest converge on the same three or four things, that's a stronger signal than either source alone.
TL;DR
- CLAUDE.md is an onboarding doc, not a wishlist. Curate it down, check it into git, and update it the moment Claude gets something wrong — Cherny's team edits their shared CLAUDE.md multiple times a week for exactly this reason.
- Produce a written plan before Claude writes any code. Anthropic's docs get there by having Claude interview you; Cherny gets there by writing the spec himself and negotiating it in Plan mode. Different routes, same non-negotiable discipline.
- Plan mode isn't a suggestion; it's a hard tool-level lock. The write tools are unavailable until you approve a plan, not just discouraged.
- "Looks done" is not a verification method. Give Claude a concrete pass/fail check every time, or you become the verification loop yourself.
- Match the permission mode to what's actually at stake, not to how much you trust the model that day — the six modes exist because each one trades oversight for autonomy differently, from reviewing every action to running unattended in a locked-down script or an isolated container.
- Delegate research to subagents to protect your context, not just to go faster — an isolated context window is the actual mechanism, speed is the side effect.
| Permission mode | What runs without asking | Use it when |
|---|---|---|
| Manual (default) | Reads run without asking; edits, commands, and network requests still execute once you approve each one | New codebase, anything sensitive, first session with a repo |
| Plan | Reads only — writes are physically unavailable | Before any change bigger than a one-line fix |
| Accept edits | File edits + safe filesystem commands | You've already agreed on the plan and are reviewing via diff |
| Auto | Reads and in-scope edits run automatically; everything else goes through a separate classifier | Long unattended runs where you trust the direction, not the specifics |
| Bypass permissions | Nearly everything, with a few built-in exceptions (explicit ask rules, some interactive MCP tools, a circuit breaker on root/home-directory deletions) | Isolated containers or VMs only — never your host machine |
Write CLAUDE.md like an onboarding doc, not a wishlist
CLAUDE.md is the one file Claude reads automatically at the start of every session — the highest-leverage tokens in your entire setup, because good context up front prevents dozens of exploratory tool calls later. The trap is treating it like a dumping ground: the entire architecture, every past incident, every edge case, until it's 600 lines and Claude starts ignoring half of it because the signal-to-noise ratio collapsed.
Anthropic's own guidance draws the line clearly: include bash commands Claude can't guess, code style that differs from language defaults, testing instructions, repo etiquette, and non-obvious gotchas. Exclude anything Claude can figure out by reading the code, and anything that changes frequently. The test for every line: would removing this cause Claude to make a mistake? If not, cut it.
What makes this a habit rather than a one-time setup task is the maintenance loop. Cherny's team keeps a single CLAUDE.md for the Claude Code repo itself, checked into git, and the whole team edits it multiple times a week — the described practice is blunt: anytime Claude does something incorrectly, they add a line so it doesn't happen again. That's the pattern worth copying, independent of team size: CLAUDE.md isn't a file you write once during setup. It's a running log of every mistake you've already paid for once and don't intend to pay for twice.
Produce a written plan before Claude writes any code
This is one of the strongest pieces of evidence in this entire guide, because two sources land on the same underlying discipline by different routes, without citing each other. Anthropic's own best-practices documentation recommends starting a larger feature with a prompt like: "I want to build [brief description]. Interview me in detail using the AskUserQuestion tool... Don't ask obvious questions, dig into the hard parts I might not have considered. Keep interviewing until we've covered everything, then write a complete spec to SPEC.md."
Cherny's own habit, described in a 2026 interview about how he actually works, gets to the same destination a different way: rather than being interviewed, he front-loads a detailed spec and full task context himself, then uses Plan mode to go back and forth with Claude — refining scope, edge cases, and what the change should and shouldn't touch — until he's satisfied with the plan. Only then does he switch to auto-accept edits and let Claude write the code, which he says it can usually do in one shot at that point.
The mechanism differs — one produces the spec by being interviewed, the other by writing it upfront and negotiating it in plan mode — but the discipline underneath is identical: neither approach lets code get written before a written plan exists to check the implementation against. That's the part worth copying regardless of which route gets you there. Once the spec or plan exists, start a fresh session to execute it — clean context, focused entirely on implementation, with a document to check against instead of a memory of the conversation that produced it.
Plan mode is a lock, not a suggestion
The distinction matters more than it sounds like it should. In plan mode, Claude's write tools are not merely discouraged from running — they're unavailable at the tool level. Claude can read files, run read-only shell commands, and propose a plan, but it cannot touch your source until you explicitly approve and exit the mode. That's a materially different guarantee than a system prompt asking politely for restraint.
Cherny's own workflow leans on this distinction directly: most sessions start in plan mode, he iterates with Claude until he likes the plan, and only then switches to auto-accept — at which point, in his words, Claude can usually one-shot the implementation. The planning conversation is where the expensive back-and-forth happens; by the time editing starts, the ambiguity is already resolved.
The judgment call worth making explicit: plan mode is overhead, and overhead isn't free. For a typo fix or a one-line change you could describe in a single sentence, skip it — the ceremony costs more than the mistake it would prevent. Reach for it when you're uncertain of the approach, when the change touches multiple files, or when you don't know the code well enough to spot a wrong turn without seeing it written down first.
"Looks done" is not a verification method
Claude stops when the work looks finished. Without something that returns a concrete pass or fail, "looks done" is the only signal available — and you become the verification loop, catching every mistake by re-reading the diff yourself. Give Claude a check it can run instead — a test suite, a build, a linter, a script that diffs output against a fixture, a screenshot compared against a design — and the loop closes on its own: Claude does the work, runs the check, reads the result, and iterates until it passes.
Cherny has called this probably the most important practice in his entire workflow: giving Claude a way to verify its own work. His team pushes this past unit tests into the browser itself — Claude opens the Chrome extension, navigates the actual interface, and iterates until it visibly works, not just until the code compiles. Nobody writes that test script; Claude just knows how to drive the browser and check its own result.
The diagnostic catch most people skip: Claude Code's own checkpoint system only reverses file edits — it does not, and cannot, undo anything that happened through a Bash command, a database migration, or an API call Claude made on your behalf. That asymmetry is exactly why verification matters more than the safety net. A checkpoint gets you back to clean source. It does nothing about the state Claude already changed in a system it doesn't control. Test cases and a real check are the only thing that catches that class of problem before it ships.
Delegate research to subagents — the context isolation is the point, not the speed
Exploring a large or unfamiliar codebase means reading a lot of files, and every file read becomes tokens sitting in your context window, whether or not it ends up being relevant. A subagent handles that exploration in its own, completely separate context and reports back a summary — the isolation is why subagents help with long sessions specifically, not primarily because they run in parallel.
The pattern worth building into a default, after running this across a build-and-publish pipeline, product work, and experiment tooling: anything read-heavy that doesn't need your judgment mid-task is a subagent candidate first, not an afterthought. The alternative — reading everything into your main thread because delegating feels like extra setup — is how a session's context fills with tool output you'll never look at again, degrading the exact thing (Claude's attention to your actual instructions) you're trying to protect. Managing that budget deliberately once context is already full is its own detailed topic; the habit here is upstream of that — keep the junk out in the first place by routing exploration through a subagent by default.
Match the permission mode to what's actually at stake
Claude Code ships with a genuine spectrum, not a single on/off switch: Manual reviews every action, Plan blocks writes entirely, Accept Edits auto-approves file changes and safe filesystem commands, Auto auto-approves reads and in-scope edits directly and routes everything else through a separate classifier that blocks scope escalation, unrecognized infrastructure, and actions that look driven by hostile content Claude read, and Bypass Permissions skips nearly every check — a mode explicitly meant for isolated containers, never a host machine.
The methodology call that actually matters: pick the mode based on the blast radius of the task, not on how well the last ten runs went. A scoped refactor in a feature branch is a reasonable Auto-mode candidate. Anything touching deploy configuration, a production database, or secret rotation stays on Manual or Plan regardless of how good Claude's track record has been that week — the cost of one unattended mistake in that category isn't symmetric with the time saved on the other nine successful runs.
Bottom line
None of this is about becoming a better prompter. It's about building the harness the prompt runs inside: a CLAUDE.md that's actually maintained instead of written once and abandoned, a spec produced by interviewing yourself before code gets written, a plan mode that's a real lock instead of a formality, a verification check instead of a visual scan of the diff, a permission mode chosen for the stakes instead of habit, and subagents used to keep your own context clean. Anthropic's documentation describes this set of habits. Independently, so does the person who built the tool. That convergence is the closest thing to proof this list is right, and it's worth building into your default workflow before you spend more time tuning prompts that were never the bottleneck.
FAQ
Do I need to use plan mode for every task?
No — for anything you could describe as a single-sentence diff (a typo, a log line, a renamed variable), skip it. Plan mode earns its overhead on multi-file changes, unfamiliar code, or genuine uncertainty about the approach. Using it on everything just slows down the trivial stuff.
What actually goes in CLAUDE.md versus what doesn't?
Include what changes Claude's behavior and what it can't guess: non-default bash commands, code style that differs from language conventions, testing instructions, repo etiquette, and known gotchas. Leave out anything Claude can cheaply rediscover by reading the code, and anything that changes often — a stale instruction is worse than no instruction, because it actively misleads.
Is auto mode actually safe, or is it just autoaccept with better branding?
It's a materially different mechanism. A separate classifier model reviews each action before it runs and blocks categories that warrant a human — scope escalation, unfamiliar infrastructure, content that looks like it's responding to instructions smuggled in from a file Claude read. It's a real safety layer, not a rebrand — but it's still a layer, not a replacement for keeping sensitive operations on Manual.
How is the "interview yourself" technique different from just writing a detailed prompt?
A detailed prompt still relies on you knowing what to specify up front. The interview flips that — Claude asks the questions, including the ones you wouldn't have thought to answer, and the two of you produce a written spec together before any code exists. The spec becomes the thing you check the implementation against, in a fresh session with no history to bias it.
What's the single highest-leverage habit if I can only change one thing?
Verification. A tight CLAUDE.md and a real plan reduce how often Claude goes wrong; a concrete check — a test, a build, a screenshot comparison — is what catches it when it does, and it's the one habit that turns a session you have to babysit into one you can actually walk away from.
Sources: Anthropic — Best practices for Claude Code, Anthropic — How Claude Code works, Anthropic — Common workflows, Anthropic — Choose a permission mode, John Kim, "How the Creator of Claude Code Actually Uses It", Push To Prod (interview with Boris Cherny), fetched 2026-07-15.