Book
Best practices for Claude Code
by Anthropic (documentația Claude Code) · 2026 · 3 reading cards
3 cards
Best practices for Claude Code · 2026
After two failed corrections: /clear and a better prompt, not a third correction.
The five patterns. The kitchen-sink session: unrelated tasks in one context, each leaving residue — /clear between them. Endless correcting: after two failed corrections the context is full of failed approaches and every answer is worse — /clear and a new prompt that incorporates what you learned, not a third correction. The over-specified CLAUDE.md: rules Claude ignores because they drown in noise — cut, or turn the rule into a hook. Trust without verification: code that "looks fine" and is wrong — tests, scripts, screenshots. Infinite exploration: "investigate" with no scope fills the window with hundreds of files — narrow the scope or use a sub-agent that returns only the conclusion. The productivity tweaks from the same guide, in the order you use them: Esc stops without losing context; Esc Esc or /rewind returns the conversation, the code or both to a checkpoint (every prompt creates one) and can summarize just a slice; /compact with instructions chooses what survives; /btw for side questions that stay out of the history; /rename so sessions become working branches; /usage shows what eats the limits; /permissions and the sandbox for fewer interruptions; a status line with context consumption. The guide ends with the antidote to recipes: when a session went well, notice what worked — the prompt, the context, the mode — and why.
“A clean session with a better prompt almost always outperforms a long session with accumulated corrections.”
Best practices for Claude Code · 2026
If you can describe the diff in one sentence, skip the plan; otherwise explore and plan first.
The recommended flow has four phases. Explore: in plan mode (Shift+Tab until "plan mode on", or --permission-mode plan at launch) Claude reads and answers but changes nothing — you can let it investigate without fear of a premature edit. Plan: ask for a concrete plan and, with Ctrl+G, open it in your editor before it continues. Implement: leave plan mode and let it code while checking against the plan. Commit: a descriptive message, a pull request. The cost is real — planning adds a whole turn — hence the rule in the quote: for a typo, a log line or a rename, go straight to code. For large features the guide proposes "interview to spec": ask it to interview you with questions until implementation, interface and edge cases are covered, then write a spec and start a fresh, clean session just for execution. Useful specs name files and interfaces, state explicitly what is out of scope, and end with an end-to-end check. A good prompt is specific: the file, the failing scenario, what "fixed" means, an existing pattern to follow. References with @file instead of descriptions, pasted images instead of "it looks roughly like this", documentation URLs instead of guesses.
“Planning is most useful when you're uncertain about the approach, when the change modifies multiple files, or when you're unfamiliar with the code being modified. If you could describe the diff in one sentence, skip the plan.”
Best practices for Claude Code · 2026
Evidence, not assertions: the test output, the command run, the compared screenshot.
The guide calls this the single most important thing you can do for quality. A check is anything that returns a readable pass/fail into the conversation: a test suite, a build's exit code, a linter, a script that diffs output against a fixture, a screenshot compared against a design. There are four levels of rigor. First: in the prompt ("run the tests and iterate until they pass"). Second: /goal — a separate evaluator re-checks the result after every turn and pushes back until it is met. Third: a Stop hook, a deterministic script that blocks the end of the turn until it passes; after eight consecutive blocks Claude Code gives up, so an impossible check cannot hold a session hostage. Fourth: a verification sub-agent or a dynamic workflow in which another model tries to disprove the result. Ask for evidence, not assertions: the test output, the command run and what it returned, the compared screenshot. The guide says it plainly: if you can't verify it, don't ship it. And for review, ask only for what affects correctness — a reviewer asked for gaps will always find gaps.
“Give Claude a check it can run: tests, a build, a screenshot to compare. It's the difference between a session you watch and one you walk away from.”