Claude Code Best Practices: 15 Tips from Running 6 Projects (2026)

I've been running 6 production projects with Claude Code for the past year. Not toy projects — real SaaS products with users, payments, and deployments.

These 15 practices are the ones that survived. I tried dozens more that didn't make the cut. Some I learned the hard way (tip #9 after losing 3 hours of work).

The single highest-impact thing? Writing a CLAUDE.md file. 10 minutes of setup saves hours of repeated explanations every session.

Still deciding between AI coding tools? I wrote an honest Cursor vs Claude Code comparison — spoiler: I use both.

---

Quick summary of all 15:

1. Write a CLAUDE.md file
2. Use .claude/rules/ for domain-specific rules
3. Add custom commands
4. Set up .claudeignore
5. Start with "what" and "why", not "how"
6. Break large tasks into phases
7. Reference existing patterns
8. Ask for plans before execution
9. Commit before big changes
10. Use /compact regularly
11. Let Claude Code run tests
12. One task per session
13. Use hooks for automation
14. Build project-specific kits
15. Review before approving

Project Setup

1. Write a CLAUDE.md File

This is the single highest-impact thing you can do. CLAUDE.md lives in your project root and Claude Code reads it at the start of every session.

Without it, every session starts from zero. With it, Claude Code immediately knows your stack, patterns, and rules.

# Project Name

Brief description of what this project does.

## Tech Stack
- Next.js 15 (App Router)
- Supabase (auth + database)
- Stripe (payments)
- Tailwind CSS v4

## Architecture
- /src/app — pages and API routes
- /src/lib — shared utilities and services
- /src/components — React components (use shadcn/ui)

## Rules
- Always use TypeScript strict mode
- Use server components by default, 'use client' only when needed
- Error handling: use Result pattern, not try/catch
- Tests: use Vitest, co-locate with source files

## Commands
- Dev: pnpm dev
- Test: pnpm test
- Build: pnpm build

10 minutes to write. Hours saved in every subsequent session.

2. Use .claude/rules/ for Domain Rules

CLAUDE.md covers the whole project. For domain-specific rules, use .claude/rules/:

.claude/rules/
├── api-routes.md      # How to write API routes
├── database.md        # Migration and query patterns
├── testing.md         # Testing conventions
└── components.md      # Component patterns

Each file loads when relevant. Claude Code reads api-routes.md when working on API routes, not when styling a button. Focused context = better results.

3. Add Custom Commands

Custom commands turn repetitive prompts into one-word shortcuts:

# .claude/commands/new-feature.md

Create a new feature following our standard pattern:
1. Create the API route in /src/app/api/
2. Create the database migration in /supabase/migrations/
3. Create the React component in /src/components/
4. Add a Vitest test file next to each new file
5. Update the sidebar navigation if needed

Now /new-feature does it all. I have about 15 custom commands across my projects — they're the single biggest time saver after CLAUDE.md.

4. Set Up .claudeignore

Like .gitignore for Claude Code. Reduces noise, keeps context focused:

node_modules/
.next/
dist/
*.lock
*.log
coverage/
.env*

Less context to scan = faster, more accurate responses.

Prompting Patterns

5. Start with "What" and "Why"

Bad prompt:

Create a file called auth.ts in src/lib with a function called verifyToken that takes a JWT string and returns the decoded payload using jose library

Good prompt:

I need JWT verification for my API routes. Users authenticate via Supabase, but I need to verify tokens in edge functions where the Supabase client isn't available.

The second gives Claude Code room to think. It might suggest a different approach. It might notice you already have a verification pattern elsewhere. Let it make architectural decisions.

6. Break Large Tasks into Phases

Don't ask for an entire feature in one prompt:

1. Plan: "I need to add billing with Stripe. What's your plan?"
2. Review the plan, adjust if needed
3. Execute phase 1: "Let's start with the webhook handler"
4. Verify (run tests, check the code)
5. Execute phase 2: "Now add the pricing page"

Each phase gets full attention. Claude Code won't rush step 5 because it's trying to remember step 1.

7. Reference Existing Patterns

Add a new API route for /api/projects. Follow the same pattern as /api/teams — same error handling, same auth middleware, same response format.

Claude Code reads the referenced file and replicates the pattern. Far more reliable than describing it in words.

8. Ask for Plans First

For any task touching more than 3 files:

Plan how you'd implement user notifications. Don't write code yet — just outline the approach.

Review the plan. Catch problems before 15 files change. Then say "looks good, execute it."

Saves significant time on reverts.

Workflow Habits

9. Commit Before Big Changes

Before any significant refactor:

git add -A && git commit -m "checkpoint before refactor"

If it goes wrong: one git reset away from safety. Without this, you're manually undoing changes across 20 files.

I learned this the hard way — lost 3 hours of work to a botched migration that touched every model file. Now I checkpoint religiously.

10. Use /compact When Context Gets Long

Long conversations degrade quality. Claude Code spends tokens processing old, irrelevant context instead of focusing on the current task.

Rule of thumb: compact after every major task completion. When responses get slower or less accurate, that's your signal.

11. Let Claude Code Run Tests

Don't copy-paste test output. Put your test command in CLAUDE.md:

## Commands
- Test: pnpm vitest run
- Test watch: pnpm vitest

Then: "Run the tests and fix any failures." Claude Code runs the suite, reads failures, fixes them, re-runs. This loop is 5x faster than manual copy-paste.

12. One Task Per Session

Don't do this:

Fix the login bug, then add dark mode, then refactor the API routes, then write tests.

Instead: fix the login bug. Compact or start fresh. Add dark mode. Each task gets focused context.

Advanced Tips

13. Use Hooks for Automation

Hooks run shell commands automatically before or after Claude Code actions:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write 2>/dev/null; exit 0"
          }
        ]
      }
    ]
  }
}

This auto-formats every file Claude Code writes. No more "fix the linting errors" follow-ups.

I wrote a complete hooks guide with 20+ examples if you want to go deeper — hooks are the most underused Claude Code feature.

14. Build Project-Specific Kits

If you repeat the same setup across projects, package it:

.claude/
├── commands/
│   ├── new-feature.md
│   ├── deploy.md
│   └── test-all.md
├── rules/
│   ├── api-patterns.md
│   └── testing.md
├── knowledge/
│   └── architecture.md
└── CLAUDE.md

Copy this .claude/ directory to any new project and Claude Code instantly knows your standards. I've packaged mine into reusable kits — one for each domain I work in (development, marketing, QA, product).

15. Review Before Approving

Claude Code is fast, not infallible. Before accepting large changes:

1. git diff — see everything that changed
2. Check for hardcoded values, missing error handling, security issues
3. Run the full test suite
4. Build the project to catch type errors

Trust but verify. Claude Code handles 90% of the work. Your job is catching the 10% it misses.

Bonus: What My Actual Workflow Looks Like

Here's the thing — I don't type any of this anymore.

Not the git commands. Not the CLAUDE.md file. Not even these prompts. I use Wispr Flow for voice input, so my "coding" sessions look like me talking to my laptop.

"Commit what we have and push to staging." Done.

"Write a CLAUDE.md for this project, check the tech stack from package.json." Done.

"Run the tests, fix whatever fails, then run them again." Done.

My hands are for code review. That's it.

I run multiple Claude Code sessions in parallel using Warp — one session refactoring the API, another writing tests, a third updating docs. Each session has its own context, its own task. I switch between them, review diffs, approve or reject.

My actual workflow looks like this:

1. Open Warp with 2-3 Claude Code sessions
2. Voice-assign each session a task via Wispr Flow
3. Switch between sessions, reviewing output
4. Approve good work, redirect bad work — by voice
5. Commit and move on

I write maybe 10-20 lines of code per day. By hand, I mean. Claude Code writes thousands. My job is architecture decisions and code review.

This isn't the future. This is Tuesday.

The 15 tips above get you started. But if you really want to see what's possible — stop typing and start directing.

The Compound Effect

Any single tip saves a few minutes. Combined, they transform the workflow. A well-configured project with CLAUDE.md, custom commands, hooks, and proper prompting ships features 5-10x faster than vanilla Claude Code.

Add voice input and parallel sessions on top, and you're not 5x faster — you're operating at a completely different scale.

The setup takes an afternoon. The savings compound every day.

What's your Claude Code setup? Do you use voice input? I'm always looking for patterns from other practitioners.

---

I'm Lukas — I run 6 SaaS projects solo using Claude Code. I write about Claude Code workflows and developer productivity on my blog.