12 Claude Code Tips That Actually Work

Before you start

Tip 1: Write a CLAUDE.md file for every project

Claude Code reads a file called CLAUDE.md at the start of every session. Put your tech stack, coding conventions, commands to run the project, and what not to touch in that file. Without it, Claude Code starts each session cold — it has to rediscover your project structure before it can be useful. With it, the first message is already in context. This single habit probably does more for output quality than anything else on this list.

Keep it honest and specific. "We use Tailwind CSS, not custom stylesheets" is far more useful than "we care about good code quality." Under 500 lines is the right target — a CLAUDE.md that is too long starts working against you.

Tip 2: Start each session with a clear single goal

"Build the whole app" is not a task — it's a wish. Claude Code works best when the goal for a session is concrete and bounded: "Add user authentication with email and password using Supabase." That has a clear start, a clear end, and a way to verify it's done. Vague goals produce vague work. You end up with code that sort of heads in the right direction but isn't actually finished.

If the task feels too big to articulate precisely, that's a signal to break it down first. Spend five minutes writing a numbered task list before you open Claude Code. You'll ship faster.

Tip 3: Give Claude Code the project structure first

Before handing over a complex task, run claude and say: "Look at the current file structure and tell me what you see." This gives Claude Code an accurate map of your project before it starts writing or editing anything. It catches assumptions early — like Claude Code not knowing you already have an auth module, or assuming you're using a different database. One orienting message at the start saves several correction rounds later.

While working

Tip 4: Use /compact before the context fills up — not after

The /compact command summarises the current conversation to free up context window space. The mistake most people make is waiting until they see warnings or notice Claude Code forgetting earlier decisions. By that point the damage is already happening — you may get incomplete edits or contradictory outputs.

Use /compact proactively: before starting a new major task in the same session, or after a long back-and-forth debug cycle. Think of it like saving your work — you do it before you need to, not after something goes wrong.

Tip 5: Don't interrupt unless something is clearly wrong

When Claude Code is mid-task — reading files, writing code, running commands — let it finish the step before you redirect it. Interrupting mid-execution often leaves the codebase in a half-edited state that's harder to recover from than whatever the original problem was. If you see something heading the wrong way, wait for it to pause, then course-correct. Your instinct to jump in is usually right, but the timing matters.

Tip 6: Use follow-up prompts to refine, not restart

Claude Code holds context between messages. Use that. "That's good, but make the button style match the existing components in /components/Button.tsx" is much faster than starting a new session and explaining everything from scratch. Refinement prompts — small, specific, additive — get you to done faster than trying to get everything right in one big prompt. Think of your session as an iterative conversation, not a single-shot request.

Tip 7: Ask Claude Code to explain what it's about to do before confirming

Before approving a significant action — especially database changes, file deletions, or refactors that touch many files — ask: "Before you do this, tell me exactly what files you'll change and why." This catches misunderstandings while they're still cheap to fix. If the plan doesn't match your intent, a quick correction now is far less work than reverting changes after the fact. It also helps you learn — you'll start anticipating what Claude Code needs to know upfront.

Getting better outputs

Tip 8: Include examples in your prompts when you have a specific style

Descriptions of style are hard to interpret. Examples are easy. If you want error messages written a certain way, show one: "Write error messages like this: Error: user not found. Check the email and try again." The same applies to variable naming, comment style, API response shape — anything where "like the rest of the codebase" is too vague. One concrete example is worth a paragraph of instruction.

Tip 9: Reference existing files as anchors

"Make this component consistent with /components/Button.tsx" gives Claude Code something concrete to match against. It's not guessing at your design system — it's reading it. This works for styling, component structure, prop naming, error handling patterns, and more. The more you point Claude Code at real examples in your codebase, the less it falls back on generic conventions that may not fit your project.

Tip 10: Use Opus for planning, Sonnet for execution

Sonnet is the default model and handles the vast majority of coding tasks well — it's fast, accurate, and cost-efficient. But for genuinely complex work — architectural decisions, nuanced refactors, or situations where Sonnet keeps getting something subtly wrong — switch to Opus with /model opus. Opus is slower and uses more tokens, but its reasoning on hard problems is noticeably better. Switch back to Sonnet once the plan is clear. Use the right tool for each phase.

Avoiding common mistakes

Tip 11: Never say "fix everything"

Asking Claude Code to "fix everything," "clean up the code," or "refactor the app" is an invitation for changes you didn't intend. Claude Code will make decisions you weren't asked for — renaming variables, restructuring files, changing logic that was working fine. Be specific about what to fix and where. "Fix the login form validation in /components/LoginForm.tsx — do not touch other files" is the right shape of instruction. Scope is your friend. Explicit scope boundaries are even better.

If you do want a broad cleanup, do it in stages. Fix one thing, review it, then move to the next. This keeps you in control of what changed and why, and gives you a clean git history you can actually read.

Tip 12: Review database migration files before confirming

Claude Code is genuinely excellent at generating database migrations — the SQL is usually correct and well-structured. But migrations run against production data, and that deserves human eyes. Before confirming any migration, read it fully. Check that it does what you intended, that rollback is possible if needed, and that it won't silently destroy data that looks unused but isn't. A two-minute review of a migration file is cheap insurance. A botched migration on live data is not.

The same principle applies to any operation Claude Code proposes that is difficult to reverse — file deletions, environment variable changes, permission modifications. Pause, read, confirm.