Claude Code Best Practices, in Plain English

Quick answer: Claude Code best practices, as Anthropic now describes them, come down to four habits. Tell Claude what it cannot see in the code. Give it a check that returns pass or fail. Enforce rules that must never bend with hooks and permission rules, not stronger wording. Only change the defaults when a task costs more time, tokens or interruptions than it should.

If you search for Claude Code best practices you will find a lot of older advice: shout in capitals, manage the context window obsessively, tell the model to "think harder". Anthropic's own best practices page has moved on. (The older engineering blog post at anthropic.com now redirects there.) This is our plain-English summary of what it says today, plus a short note on how we use it at Pocket Grove.

This post is part of our series on the AI software development lifecycle (SDLC), simply explained.

What does Anthropic say actually goes wrong?

The guide starts from a useful observation. Claude Code's defaults already handle a lot: it starts in an "auto mode" where a separate classifier model reviews risky actions, it hands side work to subagents (helper sessions), and it compacts (summarises) long conversations automatically.

So when a session goes badly, Anthropic says it is usually one of four things:

1. Claude built the wrong thing, or keeps rediscovering the same fact. It was missing information that is not in the repository.
2. Claude said "done" and it was not. It had no way to check its own work.
3. Claude broke a rule that must never be broken. A prompt alone cannot guarantee that.
4. Claude got it right but used more time, tokens or permission prompts than the job was worth.

The rest of the guide is a fix for each.

Is it "Claude decides" or "Claude Code enforces"?

This is the idea that makes everything else click. Anthropic splits every instruction into two kinds:

• Non-deterministic: you write it and the model reads it. Your prompt, CLAUDE.md and skills are all this kind. Claude usually follows them, but it is still Claude's call.
• Deterministic: you configure it and the harness (the Claude Code program itself) runs it every time. Hooks, permission deny rules, the sandbox and managed settings are this kind.

Anthropic's advice is to let Claude decide most things, because it can see the actual code in front of it. Use the enforced kind only for things that must always or never happen. Their tip: if you keep adding emphasis to a CLAUDE.md line and Claude still misses it, that line probably belongs in a hook.

The Claude Code best practices checklist

Here is the guide condensed into a numbered checklist, each with a one-line "why".

#	Practice	Why it matters
1	Give Claude a check to run (tests, build, linter, a fixture diff, a screenshot)	Without one, "looks done" is all it has, and you become the test suite.
2	Ask for evidence: the command it ran and the output	"All tests pass" on its own tells you little; output is quicker to read than rerunning.
3	Write specific prompts: name the file, the symptom and what "fixed" looks like	It saves a round of corrections later.
4	For fuzzy work, ask Claude to interview you and write a spec, then build in a fresh session	The build starts with a clean context and a written definition of done.
5	Keep CLAUDE.md short, holding only what Claude cannot find in the repo	Every line costs a little attention on every task.
6	Put rules for one area in .claude/rules/ with a paths: filter	They load only when Claude works on matching files.
7	Put team procedures (releases, runbooks) in skills	Claude sees only the name and description until a task needs the full text.
8	Turn "never" and "always" rules into hooks or deny rules	Those apply every time, whatever the model decides.
9	Use /clear between unrelated tasks	The next task stops paying for the last one's history.
10	Watch the first minute; press Esc when it drifts	Stopping early keeps the work done so far and lets you redirect.
11	After two failed corrections, /clear and write a better prompt	A third correction just adds more failed attempts for Claude to re-read.
12	Use subagents for parallel work, noisy output or an independent review	They cost extra tokens and do not make the answer smarter on their own.
13	Run parallel sessions in separate git worktrees	Separate checkouts mean edits cannot collide.
14	Before an unattended run, set "done", a check, limits on access and spend, and a human sign-off	Nobody is there to catch mistakes overnight.

The sections below expand on the parts people most often get wrong.

How do you give Claude a way to check its work?

Anthropic calls this the most useful thing you can do. If Claude has something to run that comes back pass or fail, it can make a change, run the check, read the failure and fix it, without you watching.

The guide lists a range of strictness:

• In the prompt: "run the auth tests after, and keep going until they pass". No setup needed.
• As a goal: /goal sets a condition that a separate model checks after every turn. It matters most for long background runs.
• As a Stop hook: a script that runs whenever Claude tries to finish and sends it back to work if the check fails. This one is enforced by the harness.
• By a fresh reviewer: /code-review reviews the diff in a subagent that never saw your conversation, so it is not swayed by the reasoning that produced the code.

A nice detail: when you ask a reviewer for problems, Anthropic suggests adding "skip style". Their point is that a reviewer asked to find problems will always find something, and fixing every finding leads to needless layers and tests.

If your repo already has a test command, the guide says the single most useful line in CLAUDE.md is that command.

What happened to "explore, then plan, then code"?

Older versions of this advice told you to have Claude explore, plan and only then code. The current page frames it differently. Claude already reads the code first, and Anthropic says current models are very good at it. What you add is the information it cannot read: decisions made in meetings, a deploy process in one person's head, the environment variable your tests need.

When you do not yet know what you want, the guide suggests asking Claude to interview you until it could write the spec, saving that to a file such as SPEC.md, then starting a fresh session to build from it. That is the plan step, written down. The /rewind menu then makes it cheap to try a bolder approach and roll back the code, the conversation or both. Anthropic notes that checkpoints only cover files Claude edited with its own file tools, so they work alongside git rather than replacing it.

What belongs in CLAUDE.md?

Anthropic's test before writing anything down: could Claude find this by reading the code, and would it actually go and look? If both answers are yes, leave it out. Good candidates are exact test, typecheck and lint commands, places where the code is misleading, team decisions not in the repo, and anything you have corrected twice. The memory guide suggests staying under 200 lines, and /init can generate a starting draft that you then trim.

We have written more on this in Stop putting everything in CLAUDE.md, so we will not repeat it here. If you also use OpenAI's Codex, see AGENTS.md vs CLAUDE.md.

How should you handle permissions?

The guide describes a range. In manual mode you approve every edit and command; Anthropic notes that after enough prompts people start approving without reading. At the other end, bypassPermissions approves almost everything and, the guide says, only makes sense in a disposable container. Auto mode sits between them, with a classifier blocking risky actions such as production deploys or force pushes over someone else's work.

The key point is that auto mode is a model making a judgement, so it can be wrong. Your real "never" rules belong in permission deny rules, which hold in every mode, and in the sandbox, which limits shell commands at the operating-system level. Anthropic's example is blocking reads of .env files with a deny rule. It also warns that rules match tool calls, not intent: a deny rule will not stop a script that opens the file itself.

Keep the enforced set small. The guide's rule of thumb is that if you reach forty hooks and deny rules, most are probably preferences.

When are subagents and parallel sessions worth it?

Anthropic is refreshingly direct here. Subagents pay off when you want independent work running at the same time, when you want long output (a full test run, a wide search) kept out of your main conversation, when you want a reviewer who has not seen how the code was written, or when you want a task limited to fewer tools. They cost tokens, and a fresh subagent has to gather context first, so it can be slower than doing the work yourself. The guide states plainly that delegating the same task does not make the answer better.

For parallel sessions, give each its own git worktree (a separate checkout of the same repository). claude -w <name> starts one. A second session also makes an easy independent reviewer: one writes, the other reviews without having watched.

What advice can you stop following?

The guide ends with a table of habits that current models no longer need. In short: you rarely run out of context now, though /clear between tasks still helps; capitals and "IMPORTANT" tend to make Claude over-apply a rule; "think harder" is just text, and the effort setting is the real control; "don't be lazy, keep going" is more likely to cause over-work; and describing your file layout in CLAUDE.md is unnecessary because Claude reads the repo.

What we do at Pocket Grove

In our studio, Cong Le maintains about 53 iOS and Android apps with Claude Code and Codex. Our version of this guide looks like this:

• One shared instruction file (AGENTS.md, with CLAUDE.md as a symlink) holding invariants and commands, not procedures.
• A TASKS.md per app as the written "done" for each piece of work.
• Skills for repeatable procedures such as screenshots and releases.
• Headless tests as the check Claude runs before it reports back.
• Subagents only for real parallel work or to keep large searches out of the main session.
• A human approval gate before anything reaches an app store, which matches Anthropic's "a person signs off" step for unattended work.

It is not a perfect system, and the official guide keeps changing, so we re-read it rather than relying on memory. More on the day-to-day in how we maintain 53 iOS apps.

Sources

• Best practices for Claude Code — Anthropic — https://code.claude.com/docs/en/best-practices
• Claude Code best practices (now redirects to the page above) — Anthropic — https://www.anthropic.com/engineering/claude-code-best-practices
• How Claude remembers your project — Anthropic — https://code.claude.com/docs/en/memory