Claude Code Best Practices: 25 Tips From Daily Use

The Claude Code best practices that pay off most are few and unglamorous: plan before large changes, give Claude a check it can run, clear the context between unrelated tasks, read the diff before you commit, pre-approve only what is safe, and keep the list of work somewhere other than the chat. Anthropic’s own best practices guide↗ (opens in a new tab) starts from one constraint that explains most of them: the context window fills fast, and Claude’s performance drops as it fills. The 25 tips below come from daily use, grouped by the part of the work they improve. Each is short and links to the guide that covers it properly.

Planning

1. Explore, then plan, then code. For a change that touches several files or code you do not know, start in plan mode so Claude reads and proposes before it edits. If you could describe the diff in one sentence, skip the plan and ask for it directly.
2. Give Claude a check it can run. A test suite, a build, a linter or a screenshot to compare turns “looks done” into pass or fail, and Claude keeps iterating until it passes. Ask for the evidence too, the command and its output, as verifying AI-generated work describes.
3. Say where, what and what “fixed” means. “Login fails after session timeout; check the token refresh in src/auth/; write a failing test first” gets a better result than “fix the login bug”, and reads fewer files on the way. How to write a task for an AI agent has a template.
4. For a bigger feature, let Claude interview you first. Ask it to question you about edge cases and trade-offs and write the answers into a spec, then start a fresh session to build from that spec with a clean context.
5. Split large work into tasks before anyone starts. A job Claude can finish and verify in one sitting goes better than one it has to hold in its head for hours; AI agent task decomposition shows how to cut it.

Context

1. Run /clear between unrelated tasks. Old conversation costs tokens on every message and crowds out what the next task needs. If you have corrected Claude twice on the same point, clear and start again with a better prompt rather than piling on a third correction.
2. Keep CLAUDE.md short and specific. For each line, ask whether removing it would cause a mistake; if not, cut it. Commands Claude cannot guess and conventions that differ from the defaults earn a place, and Claude Code project structure shows what goes where.
3. Send research to a subagent. “Use a subagent to find how token refresh works” keeps a hundred file reads out of your main conversation and returns a summary. Claude Code subagent examples has definitions to copy.
4. Point, do not describe. Mention files with @, paste the actual error, and pipe logs in with cat error.log | claude -p "explain". Claude reads what you point at instead of searching for it.
5. Watch the window and the meter. /context shows what is using the context and /usage shows what the session has cost; how to reduce Claude Code token usage covers what to do about each.

Review

1. Read the diff before you commit. /diff shows every change in the working tree, and /code-review checks it for correctness bugs in a fresh context. Neither replaces your own read of the change.
2. Review in a fresh context. A reviewer that did not write the code is not anchored to its reasoning, so use a subagent or a second session and tell it to report only gaps that affect correctness or the stated requirements. AI agents for PR review covers doing this on pull requests.
3. Correct early. Press Esc the moment Claude heads the wrong way; the work so far is kept and you can redirect. How to stop a Claude Code task covers the other ways to interrupt.
4. Use checkpoints for experiments, and git for everything else. Double Esc or /rewind restores code and conversation, but the checkpointing documentation↗ (opens in a new tab) is clear that changes made by shell commands are not tracked. Commit before anything risky.
5. Name sessions and resume them. /rename oauth-migration today and claude --resume oauth-migration tomorrow brings the conversation back without re-explaining it, as handing work between agents and people shows.

Permissions

1. Know which mode you are in. On current versions, the permission modes documentation↗ (opens in a new tab) says interactive terminal and VS Code sessions start in auto mode, where a classifier reviews actions instead of you. Shift+Tab cycles the modes; auto-approve in Claude Code explains each one.
2. Pre-approve narrowly. An allow rule such as Bash(npm run test *) removes a prompt you answer twenty times a day; Bash(*) removes every safeguard. The bundled /fewer-permission-prompts skill scans your past sessions for common read-only commands and MCP calls and adds an allowlist for them to the project’s settings.
3. Deny the files that must never be read. Read(./.env) and Read(./secrets/**) in .claude/settings.json keep Claude’s file tools away from secrets in every session, whoever runs it.
4. Turn on the sandbox. /sandbox puts shell commands inside an operating-system boundary for files and network, which holds even when a command slips past a rule. Security controls for AI coding agents covers the settings.
5. Keep bypassPermissions for containers. It skips the checks that protect your machine, and Anthropic says to use it only in isolated environments. On your laptop, auto mode or narrow allow rules get you most of the speed; AI agent security best practices explains why.

Recording the work

The last group is where most teams have a gap. A session’s transcript is thousands of lines; what you need afterwards is a short list of what was done, what is blocked and what was noticed. Claude Code’s own to-do checklist lives in the session, so it does not help the next person, or the next session.

1. Keep the work list on a board, not in a TODO file or the chat. A file in the repository changes per branch and records no author; a board connected over MCP is shared and keeps history. A task-tracking workflow for Claude Code walks through it.
2. Put the rhythm in CLAUDE.md. Four lines turn a board it can use into one it does use: read the board at the start, move the task when you begin, comment with the commit when you finish, and move it to Completed only when the tests pass. The Claude Code integration connects it in one command.
3. Use hooks for what must happen every time. CLAUDE.md is advice Claude tries to follow; a hook runs whatever Claude decides. Anthropic’s hooks guide↗ (opens in a new tab) has the basics, and Claude Code hooks that update a board applies them to recording work.
4. Ask Claude to file what it notices but does not fix. An assistant deep in one bug sees three others; a line saying “create a task for anything you notice” turns them into real entries with context, as tracking bugs and feature requests in one board describes.
5. Review the day from the history, not the transcript. On fenbs, every change the assistant makes is recorded as “Claude via” the person it acts for, so five minutes on the History page tells you what moved and why. An audit trail for AI agents explains why that record has to come from the tool.

None of these needs to be adopted at once. Start with the three that cost nothing, /clear between tasks, a runnable check in every prompt and a glance at /diff before each commit, and add the rest as the sessions get longer.