The CLAUDE.md Vault
Curated templates for different project types — web apps, CLI tools, data pipelines, monorepos. Start from proven configs.
Staring at a blank CLAUDE.md is brutal. You know you need one. You know it matters. But the blank page wins and you end up with three bullet points that say nothing useful.
Below are starter templates for the most common project types. Copy one, gut it, reshape it for your stack. Ten times faster than starting from scratch.
Start with /init
Before touching any template, run /init in your project directory. Claude Code scans your codebase, detects the build system, test framework, code patterns, package manager, and generates a CLAUDE.md with actual commands from your project.
Already have a CLAUDE.md? Running /init suggests improvements instead of overwriting.
Try it: Run /init on a project you have been working on. Compare what it generates to the templates below. You will probably want to merge them: keep the auto-detected commands, layer in the opinionated rules.
The /init output is a solid foundation but it plays it safe. It captures the "what" (build commands, test runners) but not the "how" (your preferences, team conventions, the things that bit you last month). The templates fill that gap.
Template 1: Next.js Web App
Typical TypeScript React app with Tailwind and ESLint. Adjust versions and package manager to match yours.
# Project Instructions
## Stack
- Next.js 15 with App Router, TypeScript strict mode
- Tailwind CSS v4 (config in globals.css, not tailwind.config.js)
- PostgreSQL with Drizzle ORM
- pnpm as package manager
## Build and Test
- Build: pnpm build (must pass zero errors before committing)
- Test: pnpm vitest run (prefer single test files, not full suite)
- Lint: pnpm lint
- Typecheck: pnpm tsc --noEmit
## Code Style
- Server components by default. Only add "use client" for interactivity.
- Use ES modules (import/export), never require()
- 2-space indentation, single quotes, trailing commas
- Prefer early returns over nested if/else
- Name booleans with is/has/should prefix (isLoading, hasError)
## Git
- Conventional commits: feat:, fix:, chore:, docs:
- Never push directly to main
- Run typecheck before committing
## Gotchas
- Tailwind v4 has no config file. All theme config is in app/globals.css.
- Environment variables need NEXT_PUBLIC_ prefix for client-side access.That "Gotchas" section at the bottom? Probably the most valuable part of the entire file. Things Claude Code can't figure out from reading your code. Non-obvious behaviors. Framework quirks. The stuff that cost you an afternoon the first time.
Template 2: Python CLI Tool
Python projects have messier needs. Package management alone has like five competing solutions. A starting point using modern tooling:
# Project Instructions
## Stack
- Python 3.12+ with type hints everywhere
- Click for CLI framework
- pyproject.toml for project config (no setup.py)
- uv for package management
## Build and Test
- Install: uv sync
- Test: uv run pytest tests/ -x (stop on first failure)
- Single test: uv run pytest tests/test_foo.py::test_bar -v
- Lint: uv run ruff check . --fix
- Format: uv run ruff format .
- Typecheck: uv run mypy src/
## Code Style
- Use pathlib for all file paths, never os.path
- Prefer dataclasses over plain dicts for structured data
- Use logging module, never print() for status output
- All public functions need docstrings (Google style)
- Type hints on all function signatures
## Project Layout
- Source code in src/mytool/
- Tests mirror source structure in tests/
- CLI entry point is src/mytool/cli.py
## Gotchas
- Tests require TEST_API_KEY env var. Use .env.test for local runs.
- The config parser expects YAML, not JSON. Check conftest.py for fixtures.See how every command has exact flags? Not "run the tests" but uv run pytest -x. Claude Code can't guess your flags.
Template 3: Go Microservice
Go is more opinionated about structure out of the box, but team-specific conventions still need documenting.
# Project Instructions
## Stack
- Go 1.22, standard library preferred over third-party deps
- Chi for HTTP routing
- sqlc for database queries (do not write raw SQL strings)
- Docker for local development
## Build and Test
- Build: go build ./cmd/api
- Test: go test ./... -race -count=1
- Single package: go test ./internal/auth/ -v -run TestName
- Lint: golangci-lint run
- Generate: go generate ./...
## Code Style
- Follow standard Go conventions (gofmt, govet)
- Errors: return errors, do not panic. Wrap with fmt.Errorf("doing X: %w", err)
- Context: pass ctx as first parameter to all functions that do IO
- Naming: use MixedCaps, not underscores. Acronyms stay uppercase (HTTP, ID, URL).
- Tests: table-driven tests preferred. Use t.Helper() in test helpers.
## API Conventions
- All endpoints return JSON with {"data": ...} or {"error": ...} envelope
- Use middleware for auth, logging, request ID injection
- Health check endpoint: GET /healthz
## Gotchas
- Run go generate before building. sqlc models are generated code.
- Docker compose mounts vendor/ directory. Run go mod vendor after adding deps.Template 4: Monorepo
Monorepos are where CLAUDE.md files earn their keep. Higher complexity, multiple packages, different build targets, workspace-specific rules. Scoped CLAUDE.md files become essential.
# Project Instructions (Root)
## Stack
- Turborepo monorepo with pnpm workspaces
- Packages: apps/web, apps/api, packages/ui, packages/shared
## Build and Test
- Build all: pnpm build
- Build one: pnpm --filter @myorg/web build
- Test all: pnpm test
- Test one: pnpm --filter @myorg/api test
## Workspace Rules
- Shared types go in packages/shared, never duplicated across apps
- UI components go in packages/ui with Storybook stories
- Each package has its own tsconfig.json extending the root
- Cross-package imports use workspace protocol: "@myorg/shared"
## Git
- PRs must pass CI for all affected workspaces
- Changesets required for packages/ui and packages/shared changes
- Branch naming: feat/ticket-123-description, fix/ticket-456-descriptionFor monorepos, also set up scoped rules. A .claude/rules/api-rules.md file can specify paths: ["apps/api/**"] in its frontmatter and include API-specific conventions. Keeps the root CLAUDE.md lean.
Making These Your Own
These are starting points, not sacred texts.
Pick the template closest to your stack. Copy it in. Run /init and compare. Merge: keep the exact commands from /init, keep the opinionated rules from the template. Add your gotchas (every project has at least three weird things). Keep it short. Every template above is under 25 lines. Your final CLAUDE.md should stay under 200.
Try it: Drop one of these into a real project, start a Claude Code session, ask it to make a change. Watch how it respects the conventions. Tweak based on what it gets right and what it misses.
Quick Reference
/initfirst for auto-detected commands, then layer in opinions from a template.- Exact commands with flags. Always. Claude Code can't guess
uv run pytest -x. - The "Gotchas" section is the highest-value real estate in any CLAUDE.md.
- Under 25 lines per template, under 200 for your full file.
@pathfor anything longer. - Monorepos need scoped rule files in
.claude/rules/to keep things targeted.
Mastering Claude Code
Lesson 12 of 70