Claude Code Tips & Tricks

keep context clean, not just short

One conversation per logical task. Debugging a flaky test and then immediately asking for a new feature in the same session means Claude is still carrying the failed hypotheses and dead ends from the first problem into the second. /clear between unrelated tasks costs nothing and removes an entire class of "why did it suggest that?" moments — see Avoiding Usage Limits for what actually fills a context window in the first place.

be precise, not verbose

Paste the actual error text and stack trace instead of paraphrasing it — a paraphrase drops the one detail (an exact exception type, a line number, a variable name) that would have pointed straight at the cause. Reference src/auth.py:142 instead of "the login function." A concrete, minimal repro ("run pytest tests/test_auth.py -k expired, it fails with X") beats a paragraph describing the symptom, because Claude can run it instead of inferring it.

say what not to do, once

If Claude keeps drifting toward an approach you've already ruled out, naming it explicitly ("don't add a new dependency for this, use the stdlib") stops the loop faster than repeating the correction after every attempt. If the same correction would apply to every session in this project, it belongs in CLAUDE.md instead of being retyped — a rule stated once in a file Claude reads every session beats being restated once per conversation.

review before you trust

Read the diff before accepting it, the same way you'd review a colleague's PR — Claude is confident whether or not it's right, and confidence isn't the signal to watch for. If a change is opaque, "explain what this does and why" is a cheap way to catch a misunderstanding before it ships, not after. And a suggested destructive command (a force-push, a DROP TABLE, an rm -rf) is worth reading in full before approving it, not reflexively confirming because the last five suggestions were fine.

run more than one session at once, with worktrees

The single highest-leverage habit here: a git worktree is a separate directory with its own branch checked out, sharing one repo's history — which means a separate Claude Code session running in it can't collide with one running in your main checkout. Instead of waiting on a long task before starting the next one, or context-switching a single session between two unrelated pieces of work, each gets its own directory, its own branch, and its own conversation.

git worktree add ../myapp-feature-x feature-x || creates a sibling directory with "feature-x" checked out, sharing this repo's history — run from your main checkout | 'wt_tip1'

Then, in a second terminal:

cd ../myapp-feature-x && claude || starts an independent Claude Code session scoped to that worktree, while your original session keeps working in the main directory | 'wt_tip2'

A worktree shares git history but not working-directory state — dependencies, build artifacts, and .env files usually need their own install step the first time. Worth it for anything that would otherwise mean idling one session to babysit another: a long-running migration in one worktree while you keep reviewing PRs in the main one, or two genuinely independent features that don't touch the same files.

let plan mode carry the expensive thinking

For anything large or risky, agreeing on the approach in plan mode before Claude writes a single line costs a fraction of what re-doing a wrong implementation costs. It's also the cheapest place to catch a misunderstanding of the task — a wrong plan is a two-line correction; a wrong implementation is a re-review.

push long tasks to the background

A task that's going to take ten minutes doesn't need you watching the whole time — running it in the background and coming back to check, covered in Avoiding Usage Limits, keeps you unblocked for everything else instead of turning a coffee break into a stare at the terminal.

Two ways to actually do it: ask Claude directly to run the command in the background, or press Ctrl+B while a Bash command it already started is running to move that one command to the background mid-flight (tmux users press it twice, since tmux intercepts the first one as its own prefix key). Either way you get a background task ID back immediately instead of a blocked turn.

/tasks || lists every running background shell and subagent, so you can check progress or pull output on demand instead of it landing in your context unasked | 'bg_tip1'