Workflows
Stop Re-Explaining Your Project Every Session
You shouldn't have to introduce yourself to Claude every single time. Five minutes setting up a CLAUDE.md gets you a Claude Code that already knows your project, your stack, and your preferences before you type a word.
On this page (5 sections)
How it works
Step 1 of 6
You're in your project folder.
Any folder with a package.json, pyproject.toml, or similar. Five minutes is all you need.
Step 2 of 6
You drop the prompt into Claude Code.
One paste. No setup, no configuration files to write yourself.
Step 3 of 6
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.
Step 4 of 6
Claude writes the CLAUDE.md.
Sections for Project, Stack, Conventions, How I work, and Things to never do.
Step 5 of 6
You tweak anything that's off.
Just open it, fix what's wrong, save.
Step 6 of 6
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.
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
I read your package.json, README.md, and the src/ and app/ folders. Here's the CLAUDE.md I drafted. Have a look:
# 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 oneA couple of things I wasn't sure about, so I made guesses you can correct:
- I noticed both
vitestandplaywrightin 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.
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.
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.
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?
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.
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 follow on Substack