You've been using Claude Code long enough to know it works, and now you're hunting for every edge you can find. I put together 50 Claude Code best practices and tips that help whether you're one week in or several months deep, sourced from Anthropic's official docs, Boris Cherny (the person who built it), community experience, and a year of my own daily usage.
This is how I start every Claude Code session. Add this to your ~/.zshrc (or ~/.bashrc):
alias cc='claude --dangerously-skip-permissions'Run source ~/.zshrc to load it. Now you type cc instead of claude, and you skip every permission prompt. The flag name is intentionally scary. Only use it after you fully understand what Claude Code can and will do to your codebase. I covered this and more aliases in customizing Claude Code.
Type !git status or !npm test and the command runs immediately. The command and its output land in context, so Claude can see the result and act on it. It's faster than asking Claude to run a command.
Esc stops Claude mid-action without losing context. You can redirect immediately.
Esc+Esc (or /rewind) opens a scrollable menu of every checkpoint Claude has created. You can restore the code, the conversation, or both. "Undo that" works too. Four restore options: code and conversation, conversation only, code only, or summarize from a checkpoint forward.
This means you can try the approach you're only 40% sure about. If it works, great. If not, rewind. Zero damage done. One caveat: checkpoints only track file edits. Changes from bash commands (migrations, database operations) aren't captured.
To pick up where you left off, claude --continue resumes your most recent conversation and claude --resume opens a session picker.
Give Claude a feedback loop so it catches its own mistakes. Include test commands, linter checks, or expected outputs in your prompt.
Refactor the auth middleware to use JWT instead of session tokens.
Run the existing test suite after making changes.
Fix any failures before calling it done.Claude runs the tests, sees failures, and fixes them without you stepping in. Boris Cherny says this alone gives a 2-3x quality improvement. For UI changes, set up the Playwright MCP server so Claude can open a browser, interact with the page, and verify the UI works as expected. That feedback loop catches issues that unit tests miss.
LSP plugins give Claude automatic diagnostics after every file edit. Type errors, unused imports, missing return types. Claude sees and fixes issues before you even notice them. This is the single highest-impact plugin you can install.
Pick yours and run the install command:
/plugin install typescript-lsp@claude-plugins-official
/plugin install pyright-lsp@claude-plugins-official
/plugin install rust-analyzer-lsp@claude-plugins-official
/plugin install gopls-lsp@claude-plugins-officialPlugins for C#, Java, Kotlin, Swift, PHP, Lua, and C/C++ are also available. Run /plugin and go to the Discover tab to browse the full list. You'll need the corresponding language server binary installed on your system (the plugin will tell you if it's missing).
The gh CLI handles PRs, issues, and comments without a separate MCP server. CLI tools are more context-efficient than MCP servers because they don't load tool schemas into your context window. Same applies to jq, curl, and other standard CLI tools.
For tools Claude doesn't know yet: "Use 'sentry-cli --help' to learn about it, then use it to find the most recent error in production." Claude reads the help output, figures out the syntax, and runs the commands. Even niche internal CLIs work.
It's a keyword that sets effort to high and triggers adaptive reasoning on Opus 4.6. Claude dynamically allocates thinking based on the problem. Use it for architecture decisions, tricky debugging, multi-step reasoning, or anything where you want Claude to think before acting.
You can also set effort permanently with /effort. For less complex tasks, lower effort levels keep things fast and cheap. Match the effort to the problem. There's no point burning thinking tokens on a variable rename.
Skills are markdown files that extend Claude's knowledge on demand. Unlike CLAUDE.md which loads every session, skills load only when relevant to the current task. This keeps your context lean.
Create skills in .claude/skills/ or install plugins that bundle pre-built skills (run /plugin to browse what's available). Use skills for specialized domain knowledge (API conventions, deployment procedures, coding patterns) that Claude needs sometimes but not always.
Run claude remote-control to start a session, then connect to it from claude.ai/code or the Claude app on iOS/Android. The session runs locally on your machine. The phone or browser is just a window into it. You can send messages, approve tool calls, and monitor progress from anywhere.
If you're using the cc alias from tip #1, Claude already has full permissions and won't need approval for each action. That makes remote control even smoother: kick off a task, walk away, and check in from your phone only when Claude finishes or hits something unexpected.
Both Sonnet 4.6 and Opus 4.6 support 1M token context windows. On Max, Team, and Enterprise plans, Opus is automatically upgraded to 1M context. You can also switch models mid-session with /model opus[1m] or /model sonnet[1m].
If you're concerned about quality at larger context sizes, start at 500k and work up gradually. Higher context means more room before compaction kicks in, but response quality can vary depending on the task. Use CLAUDE_CODE_AUTO_COMPACT_WINDOW to control when compaction triggers, and CLAUDE_AUTOCOMPACT_PCT_OVERRIDE to set the percentage threshold. Find the sweet spot for your workflow.
Use Plan Mode for multi-file changes, unfamiliar code, and architectural decisions. The overhead is real (a few extra minutes upfront), but it prevents Claude from spending 20 minutes confidently solving the wrong problem entirely.
Skip it for small, clear-scope tasks. If you can describe the diff in one sentence, just do it directly. You can switch into Plan Mode anytime with Shift+Tab to cycle between Normal, Auto-Accept, and Plan permission modes without leaving the conversation.
A clean session with a sharp prompt beats a messy three-hour session. Different task? /clear first.
I know it feels like throwing away progress, but you'll get better results starting fresh. Sessions degrade because accumulated context from earlier work drowns out your current instructions. The five seconds it takes to /clear and write a focused starting prompt saves you from 30 minutes of diminishing returns.
Describing a bug in words is slow. You watch Claude guess, correct it, and repeat.
Paste the error log, CI output, or Slack thread directly and say "fix." Claude reads logs from distributed systems and traces where things break. Your interpretation adds abstraction that often loses the detail Claude needs to pinpoint the root cause. Give Claude the raw data and get out of the way.
This works for CI too. "Go fix the failing CI tests" with a paste of the CI output is one of the most reliable patterns. You can also paste a PR URL or number and ask Claude to check the failing checks and fix them. With the gh CLI from tip #6 installed, Claude handles the rest.
You can also pipe output directly from the terminal:
cat error.log | claude "explain this error and suggest a fix"
npm test 2>&1 | claude "fix the failing tests"/btw pops up an overlay for a quick question without entering your conversation history. I use it for clarifications about the current session: "Why did you choose this approach?" or "What's the tradeoff with the other option?" The answer shows in a dismissible overlay, your main context stays lean, and Claude keeps working.
claude --worktree feature-auth creates an isolated working copy with a new branch. Claude handles the git worktree setup and cleanup for you.
The Claude Code team calls this one of the biggest productivity unlocks. Spin up 3-5 worktrees, each running its own Claude session in parallel. I usually run 2-3. Each worktree gets its own session, its own branch, and its own file system state.
The ceiling on local worktrees is your machine. Multiple dev servers, builds, and Claude sessions all competing for CPU. Builder.io moves each agent to its own cloud container with a browser preview, so your machine stays free for the work that needs your brain.
You're halfway through writing a long prompt and realize you need a quick answer first. Ctrl+S stashes your draft. Type your quick question, submit it, and your stashed prompt restores automatically.
When Claude kicks off a long bash command (a test suite, a build, a migration), press Ctrl+B to send it to the background. Claude continues working while the process runs, and you can keep chatting. The result appears when the process finishes.
The status line is a shell script that runs after every Claude turn. It displays live information at the bottom of your terminal: current directory, git branch, context usage color-coded by how full the window is.
The fastest way to set one up is /statusline inside Claude Code. It'll ask what you want to display and generate the script for you. I covered the full setup with a copy-paste script in customizing Claude Code.
"Use subagents to figure out how the payment flow handles failed transactions." This spawns a separate Claude instance with its own context window. It reads all the files, reasons about the codebase, and reports back a concise summary.
Your main session stays clean with plenty of room to build something. A deep investigation can consume half your context window before you write any code. Subagents keep that cost out of your main session. Built-in types include Explore (Haiku, fast file search) and Plan (read-only analysis). For the full picture, see our guide on subagents and agent teams.
Experimental but powerful. Enable it first by adding CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS to your settings or environment. Then tell Claude to create a team: "Create an agent team with 3 teammates to refactor these modules in parallel." A team lead distributes work to teammates, each with their own context window and a shared task list. Teammates can message each other directly to coordinate.
Start with 3-5 teammates and 5-6 tasks per teammate. Avoid assigning tasks that modify the same files. Two teammates editing the same file leads to overwrites. Start with research and review tasks (PR reviews, bug investigations) before attempting parallel implementation.
When context compacts (automatically or via /compact), tell Claude what to preserve: "/compact focus on the API changes and the list of modified files." You can also add standing instructions to your CLAUDE.md: "When compacting, preserve the full list of modified files and current test status."
/loop 5m check if the deploy succeeded and report back schedules a recurring prompt that fires in the background while your session stays open. The interval is optional (defaults to 10 minutes) and supports s, m, h, and d units. You can also loop over other commands: /loop 20m /review-pr 1234. Tasks are session-scoped and expire after 3 days, so a forgotten loop won't run forever. Use /loop for monitoring deploys, watching CI pipelines, or polling an external service while you focus on something else.
Run /voice to enable push-to-talk, then hold Space to dictate. Your speech transcribes live into the prompt, and you can mix voice and typing in the same message. Spoken prompts naturally include more context than typed ones because you explain the background, mention constraints, and describe what you want without cutting corners to save keystrokes. Requires a Claude.ai account (not API key). You can rebind the push-to-talk key to a modifier combo like meta+k in ~/.claude/keybindings.json to skip the hold-detection warmup.
When you and Claude are going down a rabbit hole of corrections and the issue still isn't fixed, the context is now full of failed approaches that are actively hurting the next attempt. /clear and write a better starting prompt that incorporates what you learned. A clean session with a sharper prompt almost always outperforms a long session weighed down by accumulated dead ends.
Use @ to reference files directly: @src/auth/middleware.ts has the session handling. The @ prefix resolves to the file path automatically, so Claude knows exactly where to look.
Claude can grep and search your codebase on its own, but it still has to narrow down candidates and identify the right file. Every search step costs tokens and context. Pointing Claude at the right files from the start skips that entire process.
"What would you improve in this file?" is a great exploration prompt. Not every prompt needs to be specific. When you want fresh eyes on existing code, a vague question gives Claude room to surface things you wouldn't have thought to ask about.
I use this when onboarding onto an unfamiliar repo. Claude points out patterns, inconsistencies, and improvement opportunities that I'd miss on a first read.
When Claude presents a plan, Ctrl+G opens it in your text editor for direct editing. Add constraints, remove steps, redirect the approach before Claude writes a single line of code. Useful when the plan is mostly right but you want to tweak a few steps without re-explaining the whole thing.
CLAUDE.md is a markdown file at the root of your project that gives Claude persistent instructions: build commands, coding standards, architectural decisions, repo conventions. Claude reads it at the start of every session. /init generates a starter version based on your project structure. It picks up build commands, test scripts, and directory layout.
The output tends to be bloated. If you can't explain why a line is there, delete it. Trim the noise and add what's missing. For more on structuring these files, see how to write a great CLAUDE.md file.
For every line in your CLAUDE.md, ask: would Claude make a mistake without this? If Claude already does something correctly on its own, the instruction is noise. Every unnecessary line dilutes the ones that matter. There's roughly a 150-200 instruction budget before compliance drops off, and the system prompt already uses about 50 of those.
When Claude makes a mistake, say "update the CLAUDE.md file so this doesn't happen again." Claude writes its own rule. Next session, it follows it automatically.
Over time your CLAUDE.md becomes a living document shaped by real mistakes. To keep it from growing indefinitely, use @imports (tip #32) to reference a separate file like @docs/solutions.md for patterns and fixes. Your CLAUDE.md stays lean, and Claude reads the details on demand.
Place markdown files in .claude/rules/ to organize instructions by topic. By default, every rule file loads at the start of each session. To make a rule load only when Claude works on specific files, add paths frontmatter:
---
paths:
- "**/*.ts"
---
# 50 Claude Code Tips and Best Practices For Daily Use
Prefer interfaces over types.This keeps your main CLAUDE.md lean. TypeScript rules load when Claude reads .ts files, Go rules when it reads .go files. Claude never wades through conventions for languages it isn't touching.
Reference docs with @docs/git-instructions.md. You can also reference @README.md, @package.json, or even @~/.claude/my-project-instructions.md.
Claude reads the file when it needs it. Think of @imports as "here's more context if you need it" without bloating the file Claude reads every session.
Stop clicking "approve" on npm run lint for the hundredth time. /permissions lets you allowlist trusted commands so you stay in flow. You'll still get prompted for anything not on the list.
Run /sandbox to enable OS-level isolation. Writes are restricted to your project directory, and network requests are limited to domains you approve. It uses Seatbelt on macOS and bubblewrap on Linux, so restrictions apply to every subprocess Claude spawns. In auto-allow mode, sandboxed commands run without permission prompts, which gives you near-full autonomy with guardrails.
For unsupervised work (overnight migrations, experimental refactors), run Claude in a Docker container. Containers give you full isolation, easy rollback, and the confidence to let Claude run for hours.
Different from using subagents on the fly (#19), custom subagents are pre-configured agents saved in .claude/agents/. For example, a security-reviewer agent with Opus and read-only tools, or a quick-search agent with Haiku for speed.
Use /agents to browse and create them. You can set isolation: worktree for agents that need their own file system.
The MCP servers worth starting with: Playwright for browser testing and UI verification, PostgreSQL/MySQL for direct schema queries, Slack for reading bug reports and thread context, and Figma for design-to-code workflows.
Claude Code supports dynamic tool loading, so servers only load their definitions when Claude needs them. For a comprehensive list of what's available, see our guide on the best MCP servers in 2026.
Run /config and select your preferred style. The built-in options are Explanatory (detailed, step-by-step), Concise (brief, action-focused), and Technical (precise, jargon-friendly).
You can also create custom output styles as files in ~/.claude/output-styles/.
Every time Claude edits a file, your formatter should run automatically. Add a PostToolUse hook in .claude/settings.json that runs Prettier (or your formatter) on any file after Claude edits or writes it:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "npx prettier --write \\\\"$CLAUDE_FILE_PATH\\\\" 2>/dev/null || true"
}
]
}
]
}
}The || true prevents hook failures from blocking Claude. You can chain other tools too — add npx eslint --fix as a second hook entry.
If you have an editor open to the same files, consider turning off format-on-save while Claude is working. Some developers have reported that editor saves can invalidate the prompt cache, forcing Claude to re-read files. Let the hook handle formatting instead.
Block rm -rf, drop table, and truncate patterns with a PreToolUse hook on Bash. Claude won't even try. The hook fires before Claude executes the tool, so destructive commands get caught before they cause damage.
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"type": "command",
"command": "if echo \\\\"$TOOL_INPUT\\\\" | grep -qE 'rm -rf|drop table|truncate'; then echo 'BLOCKED: destructive command' >&2; exit 2; fi"
}
]
}
}Add this to .claude/settings.json in your project. You can set it up interactively with /hooks, or just tell Claude: "Add a PreToolUse hook that blocks rm -rf, drop table, and truncate commands."
When context compacts during long sessions, Claude can lose track of what you're working on. A Notification hook with a compact matcher automatically re-injects your key context every time compaction fires.
Tell Claude: "Set up a Notification hook that after compaction reminds you of the current task, modified files, and any constraints." Claude will create the hook in your settings. Good candidates for re-injection: the current task description, the list of files you've modified, and any hard constraints ("don't modify migration files").
This is most valuable during multi-hour sessions where you're deep in a feature and can't afford Claude losing the thread.
Claude is good at code. These decisions need a human. Auth flows, payment logic, data mutations, destructive database operations. Review these regardless of how good the rest looks. A wrong auth scope, a misconfigured payment webhook, or a migration that drops a column silently can cost you users, money, or trust. No amount of automated testing catches every one of these.
/branch (or /fork) creates a copy of your conversation at the current point. Try the risky refactor in the branch. If it works, keep it. If it doesn't, your original conversation is untouched. This is different from rewind (#3) because both paths stay alive.
You know what you want to build, but you feel like you don't have all the details Claude needs to build it well. Let Claude ask the questions.
I want to build [brief description]. Interview me in detail
using the AskUserQuestion tool. Ask about technical implementation,
edge cases, concerns, and tradeoffs. Don't ask obvious questions.
Keep interviewing until we've covered everything,
then write a complete spec to SPEC.md.Once the spec is done, start a fresh session to execute with clean context and a complete spec.
First Claude implements the feature, second Claude reviews from fresh context like a staff engineer. The reviewer has no knowledge of the implementation shortcuts and will challenge every one of them.
Same idea works for TDD. Session A writes tests, Session B writes the code to pass them.
Don't ask Claude for a one-shot PR review (although you can if you want). Open the PR in a session and have a conversation about it. "Walk me through the riskiest change in this PR." "What would break if this runs concurrently?" "Is the error handling consistent with the rest of the codebase?"
Conversational reviews catch more issues because you can drill into the areas that matter. One-shot reviews tend to flag style nits and often miss the architectural problems.
/rename auth-refactor puts a label on the prompt bar so you know which session is which. /color red or /color blue sets the prompt bar color. Available colors: red, blue, green, yellow, purple, orange, pink, cyan. When you're running 2-3 parallel sessions, naming and coloring them takes five seconds and saves you from typing into the wrong terminal.
Add a Stop hook that plays a system sound when Claude completes a response. Kick off a task, switch to something else, and hear a ping when it's done.
{
"hooks": {
"Stop": [
{
"matcher": "*",
"hooks": [
{
"type": "command",
"command": "/usr/bin/afplay /System/Library/Sounds/Glass.aiff"
}
]
}
]
}
}On Linux, replace with paplay or aplay. Other good macOS sounds: Submarine.aiff, Purr.aiff, Pop.aiff.
Loop through a list of files with non-interactive mode. --allowedTools scopes what Claude can do per file. Run them in parallel with & for maximum throughput.
for file in $(cat files-to-migrate.txt); do
claude -p "Migrate $file from class components to hooks" \\\\
--allowedTools "Edit,Bash(git commit *)" &
done
waitThis is great for converting file formats, updating imports across a codebase, and running repetitive migrations where each file is independent of the others.
While Claude thinks, the terminal shows a spinner with verbs like "Flibbertigibbeting..." and "Flummoxing...". You can replace them with whatever you want. Tell Claude:
Replace my spinner verbs in user settings with these: Hallucinating responsibly, Pretending to think, Confidently guessing, Blaming the context window
You don't have to provide a list either. Just tell Claude what vibe you're going for: "Replace my spinner verbs with Harry Potter spells." Claude generates the list. It's a small thing that makes the wait more enjoyable.
You don't need all 50. Pick the one that solves the thing that annoyed you most in your last session, and try it tomorrow. One tip that sticks is worth more than fifty you bookmarked.
Builder.io visually edits code, uses your design system, and sends pull requests.
Builder.io visually edits code, uses your design system, and sends pull requests.
Connect a Repo
