Using Claude Code Without Losing Your Flow

I've been pairing with Claude Code on infrastructure work for a while now, and the difference between "a neat demo" and "a tool I rely on" came down to setup. Out of the box it's capable; with a few conventions in place it stops interrupting me and starts saving me hours. Here's the configuration I land on for every repo.

#Start with a CLAUDE.md

The single highest-leverage thing you can do is write a CLAUDE.md at the repo root. It's loaded into context every session, so it's where you encode the things you'd otherwise have to repeat in every prompt: the stack, the commands that actually exist, and the conventions you care about.

Keep it honest. A CLAUDE.md full of aspirational rules that don't match the code is worse than none at all — the agent will trust it and you'll spend your time correcting course.

# Scaffold one interactively
claude
> /init

A good starting skeleton:

## Stack
- Next.js 16 (App Router) + React 19 + TypeScript (strict)
- Styling: CSS Modules + design tokens — NOT Tailwind

## Commands that exist
- npm run type-check   # primary correctness gate
- npm run build        # verify before declaring done

## Conventions
- Server Components by default; 'use client' only when necessary
- Don't introduce new dependencies without asking

Why this matters: every line here is a line you don't have to type again, and a mistake you don't have to catch in review.

#Scope permissions once, not per-prompt

Constantly approving the same npm and git commands gets old fast. Allowlist the read-only and routine ones in your project settings so Claude can run them without a prompt, while still pausing on anything destructive.

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm run type-check)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ]
  }
}

The goal isn't to remove all friction — it's to remove the friction you've already decided is safe, so the approvals that remain actually mean something.

#The commands I reach for daily

A typical session looks like this:

# 1. Plan first — no edits until I approve the approach
> plan: add a /blog route backed by markdown files

# 2. Let it implement, then gate on the build
> npm run type-check && npm run build

# 3. Review the diff before committing
> /review

#Use plan mode for anything non-trivial

For a one-line fix, just ask. For anything that touches more than a couple of files, ask Claude to plan first. You get a written approach you can correct before any code is written — which is far cheaper than unwinding a wrong implementation afterward.

#Let it verify its own work

The thing that turned Claude Code from "assistant" into "teammate" for me was wiring it to its own feedback loop. If it can run type-check, build, and the tests, it will catch its own mistakes instead of handing them to you:

npm run type-check && npm run build

Point it at that command, tell it "done means this passes," and most of the back-and-forth disappears.

#The short version

• Write a truthful CLAUDE.md — it's the cheapest context you'll ever buy.
• Allowlist the safe, repetitive commands so real approvals stand out.
• Plan before editing anything non-trivial.
• Give it a verification command and hold it to a green result.

None of this is exotic. It's just the difference between fighting the tool and forgetting it's there — which is exactly where you want to be.