Claude Code Guide
docsworkflows1 min read

Stop Re-Explaining Your Project Every Session

Stop introducing yourself to Claude every session. Five minutes on a CLAUDE.md and Claude Code knows your project, stack and preferences up front.

Shadman RahmanShadman RahmanPrincipal PM
5 minutes CLAUDE.md Opus 4.7 or Sonnet 4.6By Shadman Rahman

how it works

  1. 01 / 06

    You're in your project folder.

    Any folder with a package.json, pyproject.toml, or similar. Five minutes is all you need.

  2. 02 / 06

    You drop the prompt into Claude Code.

    One paste. No setup, no configuration files to write yourself.

  3. 03 / 06

    Claude reads your repo and asks two quick questions.

    About your testing approach, your style, the rules you want enforced. Two or three questions, not a survey.

  4. 04 / 06

    Claude writes the CLAUDE.md.

    Sections for Project, Stack, Conventions, How I work, and Things to never do.

  5. 05 / 06

    You tweak anything that's off.

    Just open it, fix what's wrong, save.

  6. 06 / 06

    Next session, Claude already knows.

    Loaded automatically every time you open Claude Code in this project. No more re-explaining.

The prompt

Copy this, paste it into Claude Code from inside your project folder, and answer the two or three questions Claude asks you.

Try this prompt
I want a CLAUDE.md file for this project. Read the package.json, the README, and the top three folders so you understand the stack. Then ask me 2 or 3 quick questions about my preferences (like coding style, testing approach, or rules I want enforced). When you have answers, write a CLAUDE.md with these sections: Project, Stack, Conventions, How I work, and Things to never do.

What you get back

From Claude

I read your package.json, README.md, and the src/ and app/ folders. Here's the CLAUDE.md I drafted. Have a look:

markdown
# CLAUDE.md

## Project
Acme Dashboard. Internal admin panel for the support team.
Next.js 16 + Drizzle + Postgres on Vercel.

## Stack
- TypeScript strict mode
- Tailwind v4
- shadcn/ui for primitives
- Drizzle ORM (no Prisma here)

## Conventions
- React Server Components by default; client components opt-in with 'use client'
- Use cn() from lib/utils for class merging
- Tests live next to the file, named *.test.ts
- Conventional commits

## How I work
- Plan first for anything touching 3+ files
- Verify the build passes before declaring done

## Things to never do
- Never log secrets or tokens
- Never use `any` (use `unknown` and narrow)
- Never rewrite a working migration; add a new one

A couple of things I wasn't sure about, so I made guesses you can correct:

  • I noticed both vitest and playwright in your devDependencies. I assumed unit tests use Vitest and end-to-end uses Playwright. Right call?
  • You mentioned "no Prisma here," so I added that as a hard rule. Want me to also rule out raw SQL queries, or is that fine ad hoc?

Variations

Same shape, small twists.

For a team, not just yourself
Write a CLAUDE.md for this project that the whole team will use. Read the .github/CONTRIBUTING.md and our PR template. Pull conventions from there. Mark any rule that's debatable so we can decide together, and any rule that's a hard line so nobody softens it later.
For a CLAUDE.md that's gone stale
Read my existing CLAUDE.md and compare it against the current state of this codebase. Find anything stale: libraries we removed, patterns we no longer use, rules that were aspirational but never followed. Suggest deletions, suggest additions, and ask before changing anything.
For a personal project where you want Claude to push back
Write a CLAUDE.md for this project. I want you to be opinionated, not deferential. Push back when I'm doing something wrong. Suggest the cleaner path even if I didn't ask. Keep the file under 80 lines so it stays loadable forever without burning context.

Tips and gotchas

Keep it short. A CLAUDE.md over 200 lines burns context every single session. Aim for 80 to 150 lines. If yours grows past that, split it into shards and load only the relevant one for the task at hand.

Update it when Claude makes the same mistake twice. If you correct the same thing in two different sessions, that correction belongs in CLAUDE.md as a permanent rule. The file is a memory, not a manifesto.

Don't paste in your secrets. API keys, tokens, environment variables, customer data. None of it goes in CLAUDE.md. The file ships with your repo and gets read into Claude's context every time. Treat it like a public README.

Ready to try?

Copy and paste
I want a CLAUDE.md file for this project. Read the package.json, the README, and the top three folders so you understand the stack. Then ask me 2 or 3 quick questions about my preferences (like coding style, testing approach, or rules I want enforced). When you have answers, write a CLAUDE.md with these sections: Project, Stack, Conventions, How I work, and Things to never do.
Found this useful?Star claudecode-guide on GitHub

New guides, when they ship

One email, roughly weekly. CLAUDE.md templates, workflows I actually use, and the cut-for-length stuff that does not make the public guides. One-click unsubscribe.

Or read Product Field Notes, the Substack

On this page

The promptWhat you get backVariationsTips and gotchasReady to try?