Six real CLAUDE.md starters tuned to specific stacks and roles. Copy the one closest to yours, swap the specifics, ship in five minutes.
Most templates online are fill-in-the-blank skeletons with sections like "Project Overview" and "Coding Standards." That gets you a file Claude technically reads and mostly ignores. The instructions are too generic to change behavior.
A CLAUDE.md template earns its keep when it encodes decisions you've made — the framework version, the lint rule that breaks your build, the folder Claude keeps editing that it shouldn't. Below are six starters with those decisions pre-loaded. Pick the one closest to your stack, paste it at your repo root, spend ten minutes swapping specifics.
# Project
Next.js 14 with App Router, TypeScript strict mode, Tailwind CSS, shadcn/ui components.
Postgres via Drizzle ORM. Deployed on Vercel.
# Stack constraints
- All data fetching in Server Components unless explicitly marked client
- No `use client` in layout files — client boundaries belong at leaf components
- Drizzle schema is source of truth; never modify the DB directly
- Tailwind only — no custom CSS files, no inline style props
- shadcn/ui for all UI primitives; don't rebuild what's already in /components/ui
# Code style
- TypeScript strict: no `any`, no `@ts-ignore` without a comment explaining why
- Named exports everywhere; no default exports except page.tsx files
- Error boundaries on all async server components
- Server actions for mutations; no API routes for first-party data
# What I'm working on
[Replace with: current sprint goal, what's in progress, what's blocked]
# Don't do this
- Don't suggest moving to Pages Router
- Don't use `fetch` directly in components — all API calls go through /lib/api
- Don't add dependencies without noting them
# Project
FastAPI service, Python 3.11, Pydantic v2, SQLAlchemy 2.0 with async sessions.
Alembic for migrations. Deployed as a Docker container.
# Stack constraints
- All models inherit from Base in /models/__init__.py
- Pydantic schemas in /schemas/ — never use ORM models directly in responses
- Async all the way: no sync database calls in async endpoints
- Alembic handles all schema changes; no raw DDL in runtime code
# Code style
- Type hints everywhere — no bare `dict` or `list` return types
- FastAPI dependency injection for database sessions and auth
- HTTPException with status codes from the starlette.status constants
- Tests in /tests/ with pytest and pytest-asyncio
# Don't do this
- Don't use Flask patterns here — this is FastAPI
- Don't write sync SQLAlchemy calls inside async endpoints
- Don't return ORM objects directly — always run through the schema
# Project
Go 1.22 HTTP service. Standard library only for HTTP (net/http).
Postgres via pgx/v5. Structured logging with slog.
# Architecture
- handlers/ — HTTP handlers, one file per resource
- services/ — business logic, no HTTP concepts
- store/ — all database access, queries return domain types
- No global state outside of main.go
# Code style
- Errors are values: check every error, wrap with context using fmt.Errorf("context: %w", err)
- No panic in library code
- Context propagated to every function that does I/O
- slog for all logging — no fmt.Print in production paths
# Don't do this
- Don't use goroutines without managing their lifecycle
- Don't ignore errors with _
- Don't reach into store/ from handlers — go through services/
# Project
CLI tool written in Node.js with Commander.js. Distributed via npm.
Target: developers. Needs to work on macOS, Linux, and Windows.
# Conventions
- All commands in /src/commands/, one file per command
- Shared utilities in /src/utils/ — no business logic here
- Config reads from ~/.toolname/config.json and .toolnamerc in project root
- Process exits: 0 for success, 1 for user error, 2 for system error
# Output style
- Plain text by default, --json flag for structured output
- Errors to stderr, results to stdout
- No color unless --color flag or TTY detection says it's safe
- Progress indicators only in TTY mode
# Don't do this
- Don't use process.exit() in library functions — throw and let the CLI layer handle it
- Don't write to ~/.toolname without checking for dry-run flag
- Don't assume paths — use path.join(), never string concatenation
# Role
I'm the founder of [company], a [describe the product in one sentence].
Primarily writing: investor updates, customer emails, blog posts, product briefs.
# Voice
Direct and specific. No buzzwords (disruptive, ecosystem, leverage, unlock).
No throat-clearing — start with the point. Short paragraphs, active voice.
Read like a founder writing to another founder, not a PR team writing to the press.
# My audience
[Describe: investors / customers / team / press — whoever you write to most]
# My recurring formats
- Investor update: metrics → narrative → ask. 200–300 words.
- Customer email: context → what changed → what they need to do. Under 150 words.
- Product brief: problem → current state → proposed change → open questions. 1 page max.
# Don't do this
- Don't hedge: "it might be worth considering" → "consider this"
- Don't use passive voice
- Don't summarize what I just told you — just respond
# Role
Independent researcher / analyst. Primary output: written analysis, literature reviews,
data summaries for [describe your domain]. Audience: [specialists / generalists / clients].
# Output norms
- Cite sources inline when synthesizing multiple inputs
- Distinguish clearly between established findings and inference
- Flag low-confidence claims explicitly — don't smooth over uncertainty
- Structure: claim → evidence → caveats
# What I use Claude for
- Synthesizing papers and reports into structured summaries
- Drafting sections of longer analysis documents
- Reviewing arguments for logical gaps
- Translating technical content for non-specialist audiences
# What I don't need
- No executive summaries unless I ask for them
- No bullet-pointed conclusions — give me prose
- No "this is a complex topic" hedges — just engage with the complexity
Do I need to use all the sections?
No. Start with Role/context and the Don't-do list. Add sections only when Claude keeps missing something that a written rule would fix.
What's the right file length?
Under 2,000 tokens reliably. That's roughly 1,500 words or 6–8 solid sections. Longer files risk position bias — rules near the bottom get less attention.
Can I have multiple CLAUDE.md files?
Yes. Claude Code supports nested CLAUDE.mds: the root file sets project-wide rules, sub-directory files handle module-specific conventions. Useful when your monorepo has a backend, frontend, and shared library with different standards.
How do I know if my CLAUDE.md is working?
Start a new conversation, give Claude a representative task, and evaluate the output before prompting anything. If Claude needs corrections you've already written in the file, the instructions aren't landing — rewrite them to be more direct or move them higher in the file.
You have a template. You don't have a CLAUDE.md tuned to your specific codebase yet. CoworKit's Create tab takes a short questionnaire — stack, team size, what Claude keeps getting wrong — and writes a first draft you can edit in place. If your file has grown unwieldy, paste it into the Optimize tab for a tightened rewrite, or the Trim tab to cut it to a target length. Both run in-browser, no signup. Start at coworkit.online/generator.
Practical guides and prompt patterns — no fluff, unsubscribe any time.