The complete guide to using Claude Code like a pro — whether you're opening the terminal for the first time or shipping production apps.

Most people treat Claude Code like a chatbot that writes code. The ones getting real results treat it like a junior dev on their team — one that needs structure, memory, and a clear plan. This guide gives you both sides.

🟢 Beginner Section: The Foundation

If you're new to Claude Code, start here. These five rules will save you hours of frustration and get you building faster than 95% of people who just wing it.

1. Use CLAUDE.md — Give Claude Permanent Memory

Claude Code reads a file called CLAUDE.md before every single task. Think of it as a cheat sheet about YOUR project that Claude checks every time it wakes up.

What to put in your CLAUDE.md:

  • Your tech stack — frameworks, languages, versions (e.g. "Next.js 14, TypeScript, Tailwind, Supabase")
  • Coding style — naming conventions, formatting preferences, patterns you follow
  • File structure — where things live in your project so Claude doesn't guess
  • Rules and constraints — "Never use inline styles" or "Always use server components unless state is needed"
  • Common commands — how to run dev, build, test, deploy

Example CLAUDE.md:

# Project: SaaS Dashboard

## Stack
- Next.js 14 (App Router)
- TypeScript (strict mode)
- Tailwind CSS
- Supabase (auth + database)
- Vercel (deployment)

## Coding Style
- Use functional components only
- Prefer named exports
- Use 'cn()' utility for conditional classNames
- All API calls go through /lib/api/

## File Structure
/app → pages and layouts
/components → reusable UI components
/lib → utilities, API helpers, types
/supabase → migrations and seed files

## Rules
- Never use 'any' type
- Always handle loading and error states
- Use Zod for form validation
- Write comments only when logic is non-obvious

Why this matters: Without a CLAUDE.md, you're repeating yourself every single prompt. With one, Claude already knows your project before you say a word.

Beginner tip: Create your CLAUDE.md in the root of your project folder. Claude Code automatically detects it. Start simple — even 10 lines is better than nothing. You can grow it over time.

2. Plan Before You Build

This is the #1 mistake beginners make: jumping straight to "build me an app."

Instead, say this:

"Let's plan this first. Don't write any code yet."

Let Claude map out the architecture — the files it will create, the order of operations, the dependencies. Then you approve it.

The planning prompt formula:

I want to build [THING]. Before writing any code:
1. Outline the file structure
2. List the key components/modules
3. Describe the data flow
4. Flag any decisions I need to make
5. Then wait for my approval before coding

Why this matters:

  • A better plan means less fixing later
  • You catch wrong assumptions before they become 500 lines of code
  • You stay in control of the architecture instead of letting Claude guess

Common beginner mistake: Saying "build me a full-stack app" in one prompt. Claude will try — but it'll make dozens of assumptions you didn't agree to. Break it into phases. Plan → Approve → Build → Review → Repeat.

3. Use Checkpoints — Your Unlimited Undo Button

Claude Code saves checkpoints after every change it makes. If something breaks, type:

/undo

It rolls back instantly. No git stress. No panic. Think of it like unlimited save states in a video game.

When to use /undo:

  • Claude refactored something and now the app is broken
  • You don't like the approach it took
  • You want to try a different direction without losing your current state

Pro workflow:

  1. Ask Claude to make a change
  2. Test it
  3. If it works → move on
  4. If it doesn't → /undo and try a different prompt

Beginner tip: Don't be afraid to experiment. Checkpoints mean you can always go back. The worst thing you can do is avoid trying something because you're scared of breaking things.

4. Give It Context — The More You Share, The Less It Guesses

Claude Code is powerful, but it's not psychic. The quality of what it builds is directly tied to the context you give it.

Bad prompt:

"Fix this bug."

10x better prompt:

"Fix this bug. Here's the error message, the file it's in, and what I expected to happen instead."

Types of context you can drop in:

The golden rule: If you're thinking "Claude should know this" — it probably doesn't. Give it the context. Every time.

5. Start Small, Then Stack

Don't try to build your entire app in one conversation. Build in layers:

  1. Get the foundation working — basic layout, routing, auth
  2. Add one feature at a time — test it, confirm it works
  3. Then layer on complexity — integrations, edge cases, polish

This keeps Claude focused, keeps your codebase clean, and keeps you in control.

🔴 Expert Section: Level Up Your Claude Code Game

Already comfortable with the basics? These advanced techniques will 10x your speed and output quality.

Advanced CLAUDE.md Strategies

Layer your memory files:

  • Root CLAUDE.md → project-wide rules and stack info
  • Folder-level CLAUDE.md → specific rules for /components, /api, /tests, etc.
  • Claude reads the most specific one first, then falls back to root

Add anti-patterns:

## Anti-Patterns (DO NOT DO)
- Never use useEffect for data fetching (use server components)
- Never store sensitive keys in .env.local without .gitignore
- Never create files outside the established folder structure

This prevents Claude from falling into common traps with your specific codebase.

Advanced Planning: The Spec-Driven Approach

Instead of describing what you want in chat, create a spec file and point Claude to it:

Read the spec in /docs/feature-spec.md and implement Phase 1. 
Don't start Phase 2 until I approve Phase 1.

Your spec file should include:

  • User stories or acceptance criteria
  • Wireframe descriptions or links
  • API contracts (request/response shapes)
  • Edge cases to handle
  • Out-of-scope items (so Claude doesn't gold-plate)

Power User Slash Commands

Beyond /undo, here are commands that separate pros from beginners:

Context Window Management

Claude Code has a context limit. Pros manage it intentionally:

  • Start new conversations for new features (don't pile everything into one thread)
  • Use /compact when you notice Claude losing track of earlier decisions
  • Reference files by path instead of pasting full contents: "Look at /lib/api/users.ts and refactor the error handling"
  • Summarize decisions at the start of a new session: "In our last session, we decided to use Zod for validation and server actions for mutations. Continue from there."

The Feedback Loop Method

Pros don't just accept Claude's first output. They refine:

  1. Generate → Let Claude build the first version