47 Claude Code Tips, Tricks, and Power-User Patterns

Claude Code is an agentic coding tool - it reads your files, runs commands, and works through problems while you watch, redirect, or walk away. Most people use a fraction of what it can do. This is a working reference of 47 tips, from the everyday habits that quietly double your output to the obscure mechanics that only surface after hundreds of hours in the tool.

They're grouped so you can jump to what you need. You don't need all 47 - pick the ones that solve whatever annoyed you in your last session.

Context & Token Management

Nearly every best practice traces back to one constraint: Claude's context window fills up fast, and quality degrades as it fills. Manage context well and most other problems disappear.

1. Run /clear between unrelated tasks

A session is a context window, not a persistent assistant. When you start on a bug fix, drift to a docs update, then return to the bug, all three tasks pollute each other's context. New task, new /clear. It feels like throwing away progress, but a clean session with a sharp prompt almost always beats a long one weighed down by stale history.

2. After two failed corrections, start fresh

When you've corrected Claude twice on the same issue and it's still wrong, the context is now full of failed approaches that are actively hurting the next attempt. Don't push for a third try. /clear and write a better opening prompt that bakes in what you just learned.

3. Run /compact before you need it, not after

Most people run /compact once output starts degrading - which is too late. The better habit is running it proactively at natural breakpoints: after finishing a feature, before starting a new module. It replaces the full history with a structured summary and frees up room while quality is still high.

4. Guide compaction with explicit instructions

When you compact, tell Claude what to keep: /compact focus on the API changes and the list of modified files. You can also add a standing rule to CLAUDE.md - "When compacting, always preserve the full list of modified files and any test commands" - so critical context survives every summarization automatically.

5. Watch the context meter and intervene around 70%

Claude Code shows context usage in the UI. Actually watching it - rather than waiting for degradation to show up in the output - lets you act before quality drops. Around 70% full is the moment to either compact or wrap up and start fresh.

6. Use /btw for quick side questions

While Claude is mid-task, /btw lets you ask something without growing your conversation history. The answer appears in a dismissible overlay and never enters context. It's single-turn with no tool calls, but it has full context of the conversation - perfect for "why did you choose this approach?" without derailing the main thread.

7. Use subagents to keep your main context clean

A deep codebase investigation can consume half your context window before you write a line of code. Offload it: "Use subagents to investigate how our auth system handles token refresh." The subagent explores in its own separate context and reports back a concise summary, leaving your main session clean for building.

8. Keep your MCP server list lean

Every enabled MCP server's tool definitions get included in context on every request. Most people accumulate servers they rarely use. Disabling the ones you're not actively using is free token savings with zero prompting required - and it adds up fast in long sessions.

Planning & Prompting

The single highest-leverage thing you can do before Claude writes code is shape the input. Assume Claude makes the right call 80% of the time on any one decision; a feature with 20 decision points then has roughly a 1% chance of getting everything right. Planning collapses those decisions into a reviewed spec, where each one lands near certainty.

9. Explore, then plan, then code

Letting Claude jump straight to code often produces a confident solution to the wrong problem. Use plan mode to force a sequence: first it reads files and answers questions without changing anything, then it writes a detailed plan, then - and only then - it implements. The few minutes of overhead routinely save much more debugging downstream.

10. Skip planning when the diff fits in one sentence

Plan mode has real overhead. If you can describe the change in a single sentence - fix a typo, add a log line, rename a variable - just ask Claude to do it directly. Planning earns its keep when the approach is uncertain, the change spans multiple files, or you're unfamiliar with the code.

11. Front-load constraints, not just goals

Most prompts describe what to build. The good ones also describe what not to do, which patterns to follow, and which conventions to respect. Compare "add authentication" with "add authentication using the existing JWT pattern in auth.ts, no new dependencies, following the error-handling pattern already in the codebase." Constraints given upfront produce a far better first draft than corrections made after.

12. Give Claude a feedback loop to check its own work

This is the highest-impact tip in this entire list. Claude stops when the work looks done - without a check it can run, "looks done" is the only signal it has, and you become the verification loop. Give it something that returns pass or fail (a test suite, a build exit code, a linter, a screenshot to diff) and the loop closes on its own. Anthropic's team considers this the one practice to adopt if you adopt nothing else.

13. Have Claude show evidence, not assert success

Don't accept "done." Ask Claude to show the test output, the command it ran and what it returned, or a screenshot of the result. Reviewing evidence is faster than re-running the verification yourself, and it works for sessions you weren't watching.

14. Make Claude critique its own output

After Claude produces something, ask: "What's wrong with this? What edge cases does it miss? What would a senior engineer flag in code review?" This surfaces real problems. It works far better than "does this look right?" - which almost always gets a yes.

15. Push back on the first solution

Don't accept the first answer when quality matters. Prompts that work: "Grill me on these changes and don't make a PR until I pass your test" forces Claude to validate your understanding before shipping. "Prove to me this works" - have it diff behavior between main and your branch. "Knowing everything you know now, scrap this and implement the elegant solution" after a mediocre first attempt.

16. Stop interpreting bugs - paste the raw data

Describing a bug in words is slow and lossy. Paste the raw error log, CI output, or stack trace and say "fix." Your interpretation adds abstraction that often strips the detail Claude needs to find the root cause. You can also pipe directly: npm test 2>&1 | claude "fix the failing tests".

17. Address root causes, not symptoms

When you hand Claude an error, tell it explicitly to fix the underlying cause and not suppress the error. "The build fails with this error: [paste]. Fix it and verify the build succeeds. Address the root cause, don't suppress the error" produces durable fixes instead of a swallowed exception that resurfaces later.

18. Reference files with @ instead of describing them

Use @src/auth/middleware.ts and Claude reads that exact file before responding. Claude can grep and search on its own, but every search step narrows candidates and burns context. Pointing it at the right files from the start skips that entirely.

19. Use vague prompts on purpose when exploring

Not every prompt should be precise. "What would you improve in this file?" is a great exploration prompt - it gives Claude room to surface things you wouldn't have thought to ask about. This is especially useful when onboarding onto an unfamiliar repo and you want fresh eyes.

20. Add ultrathink for genuinely hard problems

Typing ultrathink (no slash, just the word) pushes Claude into extended, high-effort reasoning. It's slower and uses more tokens, but for architecture decisions, tricky debugging, or algorithm design the quality difference is real. There's a graduated scale - think, think hard, think harder, ultrathink - each step deeper than the last. Don't waste it on a variable rename.

21. Set your effort level explicitly

Beyond per-prompt thinking, /effort sets a session-wide level: low (fast, cheap), medium (default), high, and max. Match it to the work - low for a formatting fix, max for hard debugging. Max burns through usage limits faster, so it's best activated per session rather than left on.

22. Let Claude interview you when you can't fully spec a feature

When you know what you want but can't articulate every detail, flip it: "I want to build [description]. Interview me in detail using the AskUserQuestion tool. Ask about implementation, edge cases, and tradeoffs. Don't ask obvious questions. Keep going until we've covered everything, then write a complete spec to SPEC.md." Then start a fresh session to execute with clean context and a finished spec.

23. Feed Claude diagrams, not just prose

LLMs read Mermaid diagrams far more efficiently than English. A few hundred tokens of Mermaid syntax (a flowchart, sequence diagram, or ER diagram) can convey architecture that would cost thousands of tokens to describe in words. Preload a compact diagram of your data flow so each session starts already understanding how the pieces connect.

CLAUDE.md & Memory

CLAUDE.md is a markdown file Claude reads at the start of every conversation. It's the highest return-on-effort setup task in the whole tool: write it once, benefit every session.

24. Run /init, then cut the result down

/init generates a starter CLAUDE.md by analyzing your build system, test framework, and code patterns. The output tends to be bloated. Treat it as a first draft: trim anything you can't justify, and add what's missing.

25. Apply the litmus test to every line

For each line in CLAUDE.md, ask: "Would removing this cause Claude to make a mistake?" If Claude already does the thing correctly on its own, the line is noise. This matters more than it sounds - a bloated CLAUDE.md causes Claude to ignore your actual instructions because the important rules get lost in the clutter. Ruthless pruning makes the file work better, not worse.

26. Turn mistakes into rules automatically

When Claude does something wrong, end your correction with: "Update your CLAUDE.md so you don't make that mistake again." Claude is very good at writing rules for itself. Over time the file becomes a living document shaped by real failures - Anthropic's team calls this "compounding engineering," where every correction makes every future session better.

27. Use @imports to keep it lean

Reference other files with @docs/git-instructions.md, @README.md, or even @~/.claude/my-project-instructions.md. Claude reads them on demand. This lets your main CLAUDE.md stay short while detailed context - solution logs, conventions - lives in separate files pulled in only when needed.

28. Use multiple CLAUDE.md files in a monorepo

Claude Code reads CLAUDE.md files at multiple levels. In a monorepo, a root file holds global conventions while subdirectory files hold package-specific rules. Frontend rules load when Claude reads frontend code, backend rules when it reads backend code - no mixing, no bloat.

29. Use .claude/rules/ for rules that apply only sometimes

Drop topic-specific markdown into .claude/rules/. Add paths frontmatter so a rule loads only when Claude touches matching files - TypeScript conventions when it reads .ts files, Go conventions when it reads .go files. Claude never wades through rules for languages it isn't touching.

30. Version-control your CLAUDE.md

Check CLAUDE.md into git and have the whole team contribute. It evolves as your conventions evolve, so commit changes to it alongside the code changes that motivated them. New teammates inherit the accumulated knowledge, and you can trace why each rule exists.

31. Configure auto-memory and auto-dream

Run /memory to set up the built-in memory system. Auto-memory saves preferences, corrections, and patterns between sessions automatically. Auto-dream runs a subagent that periodically reviews accumulated memory - pruning outdated assumptions, merging overlapping notes, and keeping only what matters - so your memory doesn't rot into noise. The naming mirrors how REM sleep consolidates short-term memory into long-term storage.

32. Keep a task log file for long sessions

Have Claude maintain a TASK.md during long work, updating it with what's done, what's in progress, and what's next. If the session dies or you compact, the log gives you a clean resumption point that doesn't depend on conversation history surviving.

Parallel Development & Multi-Agent Patterns

Once you're effective with one Claude, you can multiply output by running several at once. The Claude Code team calls parallel sessions the single biggest productivity unlock.

33. Run multiple sessions in git worktrees

Worktrees let you run several Claude sessions on separate branches of the same repo simultaneously, each in its own isolated checkout, with no collisions. Claude Code has native support: claude --worktree (or claude --worktree my-feature) starts a session in an isolated worktree. Most power users run two to five.

34. Name and color-code parallel sessions

When you're juggling several sessions, lost orientation is the real cost. Name your worktrees, set shell aliases (za, zb, zc) to jump between them, run /rename auth-refactor to label a session, and use /color to tint the prompt bar. Five seconds of setup saves you from typing into the wrong terminal.

35. Use the Writer/Reviewer pattern

Have one Claude implement a feature, then a second Claude review it from a fresh context like a staff engineer. The reviewer has no knowledge of the implementation's shortcuts and will challenge every one of them. A fresh context genuinely improves review quality because the model isn't biased toward code it just wrote. The same idea works for TDD: session A writes tests, session B writes code to pass them.

36. Add an adversarial review step before "done"

The longer Claude works unattended, the more an independent check matters. Run a subagent over the diff in a fresh context: "Review the rate limiter diff against PLAN.md. Check every requirement is implemented, the edge cases have tests, and nothing outside scope changed. Report gaps, not style preferences." One caveat: a reviewer told to find gaps will usually find some even when the work is sound, so scope it to correctness and stated requirements to avoid over-engineering.

37. Give subagents worktree isolation for big batched changes

Custom subagents can run in their own worktree. Add isolation: worktree to the agent's frontmatter, then prompt naturally: "Migrate all sync IO to async. Batch the changes and launch 10 parallel agents with worktree isolation. Each agent should test end to end, then open a PR." No merge conflicts, because each agent owns its own filesystem state.

38. Use /batch for large migrations

The /batch command interviews you about a migration, then fans the work out across as many worktree agents as needed - dozens or hundreds. Each works in isolation, tests its own changes, and opens its own PR. > /batch migrate src/ from Solid to React and it takes over the orchestration.

39. Commit a checkpoint before handing off between agents

When one agent finishes a phase and another takes over, commit the current state first. It gives the next agent a clean baseline, makes rollback trivial if something breaks, and keeps your git history readable across the handoff.

40. Fan out with claude -p for batch operations

For independent, repetitive work, loop over non-interactive mode. Generate a file list, then run Claude once per file, scoping permissions with --allowedTools and parallelizing with &:

for file in $(cat files-to-migrate.txt); do
  claude -p "Migrate $file from class components to hooks. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" &
done
wait

Test on two or three files first, refine the prompt based on what goes wrong, then run at scale.

Hooks, Permissions & Safety

CLAUDE.md is advisory - Claude follows it most of the time. Hooks are deterministic. If something must happen every time without exception, it belongs in a hook, not in your instructions.

41. Auto-format with a PostToolUse hook

Every time Claude edits a file, your formatter should run automatically. A PostToolUse hook matching Edit|Write that runs Prettier (or your formatter) keeps CI from failing on style. End the command with || true so a formatter hiccup never blocks Claude. One subtlety: if your editor also formats on save, the two can fight and a save can invalidate Claude's prompt cache by rewriting a file mid-edit - let the hook own formatting while Claude works.

42. Block destructive commands with a PreToolUse hook

A PreToolUse hook on Bash can scan for dangerous patterns - rm -rf, drop table, truncate - and block them before they ever run by exiting non-zero. Claude won't even attempt the command. You can set it up by just telling Claude: "Add a PreToolUse hook that blocks rm -rf, drop table, and truncate."

43. Re-inject context after compaction with a hook

A PostCompact (or Notification) hook can automatically re-inject your key context every time compaction fires - the current task, the list of modified files, any hard constraints like "don't touch migration files." This matters most in multi-hour sessions where Claude losing the thread mid-feature is expensive.

44. Pre-approve safe commands instead of skipping permissions

Stop clicking "approve" on npm run lint for the hundredth time. Run /permissions to allowlist trusted commands and check the list into your team's .claude/settings.json. Wildcards work - "Bash(npm run *)" or "Edit(/docs/**)". This is the recommended alternative to disabling permissions wholesale: fewer prompts, but an auditable, version-controlled list of exactly what's allowed.

45. Use /sandbox for OS-level isolation

/sandbox enables an open-source sandbox runtime that restricts filesystem writes to your project directory and limits network access to domains you approve. It uses Seatbelt on macOS and bubblewrap on Linux, so the restrictions apply to every subprocess Claude spawns. In auto-allow mode you get near-full autonomy with real guardrails. For unsupervised overnight work, a Docker container gives even fuller isolation and easy rollback.

46. Always manually review auth, payments, and data mutations

Claude is good at code, but some decisions need a human regardless of how clean the output looks. Auth flows, payment logic, and destructive database operations are where a subtle mistake - a wrong auth scope, a misconfigured webhook, a migration that silently drops a column - costs you users, money, or trust. No amount of automated testing catches every one of these. Review them by hand, every time.

How Caching Actually Works (and How Not to Break It)

This is the 1,000-hour material. Prompt caching is the architectural constraint the entire product is built around - it's why a long Opus session costs ~$19 instead of ~$100, and why a few innocent-looking habits can quietly 5× your costs.

Every message re-sends the whole conversation to the API. Caching stores the computation from previous tokens (the KV cache) so the model skips re-reading what it's already seen - cached reads cost about 10% of normal input price. But the cache matches from the start of the prefix forward: change a single byte early in the prompt and everything after it is invalidated and recomputed. In one experiment, changing two letters from lowercase to uppercase threw away 2,727 tokens of cached computation. The cache also expires after roughly five minutes of inactivity, and each hit resets that timer.

47. Protect your cache: don't mutate the prefix mid-session

Three habits break the cache and cost you real money, and all three have a workaround:

• Don't switch models mid-session. Caches are per-model - Opus and Haiku compute the KV cache differently, so switching means a cold rebuild from scratch that often costs more than just staying put. (Claude Code handles this internally by spawning a separate Haiku subagent with its own cache when it needs a quick search, leaving the parent Opus cache untouched.)
• Don't add or remove tools mid-session, including MCP tools. Tool definitions sit in the cached prefix between the system prompt and the conversation. Adding one changes the prefix and invalidates the entire conversation history. This is why Claude Code locks the tool list at startup.
• Don't put changing data at the top of a custom system prompt. A timestamp or git status near the top busts the cache on every single request. Move volatile data to the bottom, or better, into a user message - this is exactly why Claude Code injects dates and file state as <system-reminder> tags in messages rather than editing the system prompt. One user recovered 20+ percentage points of cache hit rate just by moving a timestamp from the top of their prompt to the bottom.

If you build on the API directly, log cache_read_input_tokens and cache_creation_input_tokens after every call and treat an unexpected zero cache read like a failed health check.

Wrapping Up

You don't need to adopt all 47 at once. The highest-leverage cluster, if you want a starting point: give Claude a way to verify its own work (#12), manage context aggressively with /clear and proactive /compact (#1, #3), invest in a lean CLAUDE.md that grows from real mistakes (#25, #26), and once those are habit, scale out with worktrees (#33). Everything else compounds from there.

Pick the one tip that fixes the thing that annoyed you most last session, and try it tomorrow. One trick that sticks beats fifty you bookmarked.

Sources: Anthropic's official Claude Code best-practices documentation and the broader Claude Code power-user community. Claude Code ships frequently - verify version-specific commands against the official docs before relying on them.