CLAUDE.md = A Manual for the AI
When a new colleague joins the team, what do you give them? Probably a βteam operations guideβ of some kind. βUse this format for reports, follow this deployment process, donβt touch this folderβ β that sort of thing.
CLAUDE.md serves exactly that role. Itβs the very first document Claude Code reads when it βjoinsβ your project. Write your project info, rules, and warnings in this file, and Claude Code automatically reads and follows them.
| For a new colleague | For Claude Code (CLAUDE.md) |
|---|---|
| Hand them the team operations guide | Create a CLAUDE.md file |
| "Use this format for reports" | "Follow this coding style" |
| "Don't touch this folder" | "No modifications to node_modules/" |
| "Deploy only after team lead approval" | "Push only after PR review" |
| "Ask me if you're unsure" | "Stop and ask if you're unsure" |
One-line summary
CLAUDE.md = Your projectβs official documentation. Claude Code reads it first at the start of every new conversation. Write it well and youβll never need to βexplain from scratch.β
Why Do You Need It?
βCanβt I just explain things during conversation?β Sure, you can. But there are 3 problems with that.
Problem 1: You repeat yourself every time
Without CLAUDE.md
Every new conversation: βThis project uses Next.js 14, TypeScript strict mode, Tailwindβ¦β from scratch.
With CLAUDE.md
βCreate a button componentβ β one sentence, and it matches your project style.
Problem 2: It makes mistakes without knowing the rules
Without CLAUDE.md
βOh, you donβt use CSS modules here? I didnβt know it was Tailwind-only.β You get results and have to fix them.
With CLAUDE.md
It knows the rules from the start and writes in Tailwind. No corrections needed.
Problem 3: Different team members explain differently
Without CLAUDE.md
Team member A says βuse functional style,β B says βuse classes.β Same project, inconsistent styles.
With CLAUDE.md
Everyone shares the same CLAUDE.md, so coding style stays consistent.
CLAUDE.md vs Auto Memory
Auto Memory (previous chapter) is a personal notepad Claude Code writes automatically.CLAUDE.md is an official manual that you write yourself. Auto Memory only works on your computer, but CLAUDE.md can be shared with your entire team via Git.
CLAUDE.md = The AIβs Official Textbook
Write it once and itβs automatically read in every conversation, benefiting the whole team
Creating Your First CLAUDE.md
Creating a CLAUDE.md is simple. Just create a file named CLAUDE.mdin your project root folder. The name must be exactly CLAUDE.md β case-sensitive.
Method 1: Auto-generate with /init (Easiest)
Running /init in Claude Code analyzes your project and auto-generates a CLAUDE.md. The easiest way to start.
/initClaude Code analyzes your file structure, package.json, config files, etc. and creates a CLAUDE.md draft. Just modify what you need.
Method 2: Ask Claude to Create It
Analyze this project and create a CLAUDE.md.
Include build methods, file structure, and coding rules.Method 3: Write It Yourself
You can write it manually in a text editor or VS Code. Start with this template:
# CLAUDE.md
## Project Overview
This project is [one-line description].
## Tech Stack
- Framework: Next.js 14
- Styling: Tailwind CSS
- Language: TypeScript (strict mode)
## Commands
```bash
npm run dev # Dev server
npm run build # Production build
npm run lint # Code linting
```
## File Structure
- src/app/ β Pages
- src/components/ β Reusable components
- src/lib/ β Utility functions
- public/ β Static files
## Coding Rules
- Components: export default function (no arrow functions)
- Styling: Tailwind classes only
- State management: zustand
- Import order: React > Next > external libs > internal modules
## Cautions
- Do not commit .env files
- No modifications to node_modules//init is the fastest
Starting from a blank page can feel overwhelming. Auto-generate with /init first, then just modify what you need β most efficient.
CLAUDE.md File Priority
CLAUDE.md can exist in multiple locations, each applying at different scopes. Like company policy β team policy β personal settings, they merge from broadest to narrowest scope.
Set by company admins. Top-level rules individuals can't override. Not applicable to most users.
Applies to all your projects. Personal preferences like "respond in English" or "use conventional commits."
Applies to this project only. Most commonly used location. Shareable with team via Git.
Applies only to a specific folder. Used in large projects with different rules per module.
Applies only on your machine. Personal settings not committed to Git.
In most cases, you only need #2 (global) and #3 (project root). The rest are for larger projects.
| Location | Scope | Typical Use |
|---|---|---|
| ~/.claude/CLAUDE.md | All my projects | Language, commit style |
| project/CLAUDE.md | This project only | Build methods, coding rules |
| project/src/CLAUDE.md | When working in src/ only | Frontend-specific rules |
| project/api/CLAUDE.md | When working in api/ only | Backend-specific rules |
What if they conflict?
If the global CLAUDE.md says βwrite comments in Frenchβ but the project CLAUDE.md says βwrite comments in Englishβ βthe more specific (narrower scope) rule wins.Project rules override global rules.
Reference Other Files with @import
As CLAUDE.md grows longer, it can become hard to read. Use @import to split content across multiple files.
# CLAUDE.md
## Project Overview
This project is an e-commerce platform.
@import docs/coding-rules.md
@import docs/api-guide.md
@import docs/deployment.mdWhen Claude Code reads CLAUDE.md, it also reads the @imported files, treating them as one big document.
When to use @import?
@import is useful when
- CLAUDE.md exceeds 200+ lines
- You want to separate coding rules, API guides, deployment procedures
- Different team members need different reference docs
- You want to reuse existing docs (README, etc.)
Fine without @import when
- CLAUDE.md is under 100 lines
- Personal project without complex rules
- Managing everything in one file is easier
project/
βββ CLAUDE.md # Main (overview + @import list)
βββ docs/
β βββ coding-rules.md # Detailed coding rules
β βββ api-guide.md # API integration guide
β βββ deployment.md # Deployment procedures
βββ src/
βββ CLAUDE.md # src-folder-specific rules@import paths must be relative
File paths after @import must be relative pathsbased on the CLAUDE.md fileβs location. Absolute paths (/Users/me/docs/...) wonβt work. Nested @imports (imports within imported files) are supported.
.claude/rules/ β Conditional Rules
You can create rules like βonly apply this when editing .ts files.β Create a .claude/rules/ folder in your project root and add rule files inside.
Folder Structure
project/
βββ .claude/
β βββ rules/
β βββ typescript.md # Applied when working on .ts files
β βββ testing.md # Applied when working on test files
β βββ deployment.md # Applied for deployment tasks
βββ CLAUDE.md
βββ src/Rule File Example
Add metadata between --- markers at the top of each rule file. Use globs to specify which files it applies to and description for a brief explanation.
---
description: TypeScript file writing rules
globs: "**/*.ts,**/*.tsx"
---
# TypeScript Rules
- Strict mode: no any types
- Interfaces without I prefix (UserProps OK, IUserProps X)
- Use const object + as const instead of enum
- Always specify function return types---
description: Test file writing rules
globs: "**/*.test.ts,**/*.spec.ts"
---
# Testing Rules
- Test framework: Jest + React Testing Library
- Use describe > it structure
- Write test names in English
- Mocking: use jest.mock(), mock external librariesWith this setup, Claude Code automatically references the TypeScript rules when editing .ts files, and the testing rules when writing .test.ts files. No need to say βremember, strict mode, no anyβ every time.
Not needed at first
.claude/rules/ is an advanced feature. A single CLAUDE.md at project root is enough to start. Split rules when the project grows and rules get complex.
CLAUDE.md Examples by Project Type
CLAUDE.md content varies by project type. Here are 3 ready-to-use examples. Copy the one that fits and customize it.
1. Website Project (Next.js)
Company homepage, personal blog, landing page, etc.
# CLAUDE.md
## Project
Company homepage. 5 pages (Home, About, Services, Blog, Contact).
## Tech Stack
- Next.js 14 (App Router)
- Tailwind CSS
- TypeScript
## Commands
- Dev: npm run dev (port 3000)
- Build: npm run build
- Deploy: git push β Vercel auto-deploy
## File Structure
- app/ β Pages (App Router)
- components/ui/ β Reusable UI components
- lib/ β Utility functions
- public/ β Images, fonts
## Design Rules
- Font: Pretendard
- Primary color: #171a20 (near-black)
- Accent color: #3e6ae1 (blue)
- Corners: rounded-xl (cards), rounded-md (buttons)
- Spacing: py-20 between sections
## Coding Rules
- Components: export default function
- CSS: Tailwind only (no inline styles)
- Images: next/image required
- English content
## Cautions
- Never commit .env.local
- No files over 10MB in public/2. Automation Script Project (Python)
Data collection, report automation, Excel processing, etc.
# CLAUDE.md
## Project
Work automation script collection. Data scraping, Excel processing, email sending.
## Environment
- Python 3.12
- Virtual env: .venv (python -m venv .venv)
- Packages: requirements.txt
## Running
```bash
source .venv/bin/activate # Mac/Linux
.venv\Scripts\activate # Windows
pip install -r requirements.txt
python main.py
```
## File Structure
- scripts/ β Individual automation scripts
- data/ β Input data (CSV, Excel)
- output/ β Execution results (gitignore)
- utils/ β Common utility functions
- .env β API keys (gitignore)
## API Integrations
- DART: https://opendart.fss.or.kr/guide/main.do
- Gemini: https://ai.google.dev/docs
- All API keys read from .env
## Rules
- Error handling: try/except required
- Logging: use logging module instead of print
- Type hints: required in function signatures
- Large files (>10MB) go to output/3. Personal Learning Project (Simple)
Practice project while learning Claude Code
# CLAUDE.md
## Project
Claude Code learning/experimental project.
A space for free experimentation.
## Environment
- Node.js 22
- No framework
## Rules
- Experiment freely (breaking things is OK)
- Save outputs to output/ folder
- Write comments in English
## Notes
- Lessons from this project will be applied to real projects laterStart short
Longer isnβt better for CLAUDE.md.3-line project description + commands + file structure is enough to start. Add more when you think βI should tell it about this too.β
Try It Yourself
Create a CLAUDE.md right now. 5 minutes is all you need.
Exercise 1: Auto-generate with /init
Run Claude Code in an existing project folder and type /init.
cd my-project-folder
claude/initClaude Code analyzes your project and creates CLAUDE.md. Check the content and add anything missing.
Exercise 2: Create a Global CLAUDE.md
Create personal settings that apply to all projects.
Create a ~/.claude/CLAUDE.md file.
Contents:
- Respond in English
- Commit messages in conventional commit format
- Code comments in EnglishExercise 3: Experience CLAUDE.md in Action
After creating CLAUDE.md, start a new conversation and check if rules apply automatically.
# If CLAUDE.md says "use arrow functions for components":
Create a button component.
# β Claude Code should use arrow functions.
# If not, CLAUDE.md wasn't read properly.Verification Checklist
If /init doesnβt work, check your Claude Code version. Run claude --version and update with npm update -g @anthropic-ai/claude-code.
CLAUDE.md Writing Tips + Sources
Practical tips for more effective CLAUDE.md usage.
1. The 4 must-haves
Include at minimum these 4 things. They alone deliver 80% of the value.
1. One-line project description
βE-commerce platform backendβ
2. Build/run commands
npm run dev, npm run build
3. Key file structure
What goes where
4. Things never to do
No .env commits, no direct push to main
2. Keep it concise
CLAUDE.md isnβt a novel. Use bullet points and code blocks to keep it brief. Claude reads long text fine, but key points can get buried.
3. Write in directive form
Instead of βThis project uses TypeScript,β write βUse TypeScript strict mode. The any type is prohibited.β Direct instructions are more effective. Claude follows clear directives better.
4. Commit it to Git
CLAUDE.md is part of the project. Always commit it to Git to share with teammates. Donβt add it to .gitignore! This ensures everyone works under the same rules.
5. Treat it as a living document
CLAUDE.md isnβt a one-time thing. Update it as the project evolves. Add new rules, remove outdated ones. You can even ask Claude Code to βupdate the CLAUDE.md.β
6. No sensitive info
CLAUDE.md goes into Git. Never include API keys, passwords, or internal server addresses. Instead, write βAPI keys read from .envβ β just reference the method.
| Content | Should you include it? |
|---|---|
| Build/run commands | Essential — add this first |
| File structure description | Essential — helps Claude find files faster |
| Coding style rules | Recommended — ensures consistent code |
| Prohibited actions | Recommended — prevents mistakes proactively |
| API keys, passwords | Never — separate into .env files |
| Design tokens (colors, fonts) | Recommended — maintains design consistency |
| Deployment procedures | Recommended — especially for team projects |
| Personal preferences | Goes in global CLAUDE.md — not project-level |
CLAUDE.md + Auto Memory = Ultimate Combo
When CLAUDE.md (official rules) and Auto Memory (learned experience) combine, Claude Code becomes the ultimate expert on your project. Set it up once and never repeat explanations again.
Today's task: Create one CLAUDE.md
If you have a project youβre working on right now, just run /init once. 5 minutes of investment changes every future conversation. You have to try it to feel why itβs needed.
References
- Claude Code CLAUDE.md Official Docs β docs.anthropic.com/en/docs/claude-code/memory#claudemd-files
- CLAUDE.md Best Practices β docs.anthropic.com/en/docs/claude-code/memory#best-practices
- .claude/rules/ Conditional Rules β docs.anthropic.com/en/docs/claude-code/memory#rules