CLAUDE.md best practices & template

CLAUDE.md is the memory file Claude Code reads every session — your conventions, commands and rules. A good one stops you from repeating yourself. Here is a template and the practices that matter.

Copy-paste template

# Project: <name>

## Commands
- Install: <cmd>   · Dev: <cmd>   · Test: <cmd>   · Lint/format: <cmd>

## Conventions
- Language / framework and version
- File layout and where things go
- Naming, imports, error handling style

## Do / Don't
- Do: small focused changes, match existing patterns
- Don't: reformat unrelated files, add new deps without asking

## Context
- Architecture in 3-5 lines, key modules, gotchas

Best practices

Keep it short and specific

CLAUDE.md is injected every session — long files waste context. State rules, not essays.

Put the commands first

Install / dev / test / lint commands are what Claude reaches for constantly.

Write do's and don'ts

Encode the mistakes you keep correcting ("don't reformat unrelated files") so you stop repeating them.

Use project + personal files

A project CLAUDE.md is shared with your team; a home one applies everywhere you work.

Update it when you correct Claude

If you fix the same thing twice, it belongs in CLAUDE.md.

Skip the setup

Browse ready-made CLAUDE.md templates and other Claude Code configs on ConfigDeck.

Browse the marketplace →

FAQ

How long should CLAUDE.md be?

Short — state rules, not essays. If it keeps growing, split detail into skills instead.

Project or personal CLAUDE.md — which do I need?

Project-level for team-shared conventions; a home-folder one for personal preferences across every project.

What belongs in it?

Commands, conventions, do's/don'ts and short architecture context — things Claude can't infer from the code alone.

When should I update it?

The moment you correct Claude for the same mistake twice, add a rule for it.