Skip to main content

Guide

Writing Your First CLAUDE.md Rules File

Create a rules file that makes Claude Code follow your project conventions from the first session.

By The Codegen Team · Updated June 2026

Key insight
CLAUDE.md is a markdown file in your project root that Claude Code reads at the start of every session. Include your commands, conventions, and restrictions in under 50 lines. The /init command generates a starter file you can refine.
Key takeaways
  • Run /init in your project directory to generate a starter CLAUDE.md, then cut what is obvious and add what is missing.
  • Your file needs four sections (project context, commands, conventions, restrictions) and works best at 20 to 50 lines total.
  • Conciseness directly affects rule adherence because the file injects into the context window on every turn.
  • Scoped files under .claude/rules/ load selectively and cost fewer tokens per turn than keeping everything at the project root.

How to Generate a Starter File

The fastest way to start is the /init command. Open Claude Code in your project directory and run it.

# Inside your project directory
$ claude

# Once Claude Code starts, type:
/init

Claude examines your codebase, detects your build system, test framework, and code patterns, then generates a CLAUDE.md tailored to what it finds. The generated file is a starting point. Review every line, cut what is obvious, and add what is missing from how you actually work.

If you prefer writing from scratch, create a file named CLAUDE.md in your project root. The filename is case-sensitive. It must be exactly CLAUDE.md, uppercase, with a lowercase .md extension.

What Should Your CLAUDE.md Include?

A productive CLAUDE.md covers four things. Project context, build commands, code conventions, and restrictions. Here is a complete example for a TypeScript project:

# CLAUDE.md

## Project
Next.js 14 app with TypeScript, Tailwind CSS, and Prisma ORM.
Postgres database. Deployed on Vercel.

## Commands
- Dev server: npm run dev
- Run all tests: npm test
- Run single test: npx jest path/to/test.ts
- Lint: npm run lint
- Type check: npx tsc --noEmit

## Code Conventions
- Use functional components with hooks. No class components.
- Named exports only. No default exports.
- TypeScript strict mode. No `any` types.
- Colocate test files: Component.test.tsx next to Component.tsx.

## Do Not
- Do not commit directly to main. Use feature branches.
- Do not delete or modify migration files.
- Do not install new dependencies without asking first.

This file is 20 lines. That is intentional. Every line in CLAUDE.md loads into every request as recurring input cost, so each line competes for attention with the actual work you are asking Claude to do. The most effective CLAUDE.md files stay between 20 and 50 lines. Beyond roughly 50 lines, instructions start getting partially ignored as context fills with other information from your codebase and conversation history.

For each line you consider adding, ask one question. Would removing this cause Claude to make a mistake it would not make otherwise? If Claude already follows a convention by default (like using async/await in modern JavaScript), writing it down adds noise without improving output.

How to Verify Your Rules Are Working

After creating your CLAUDE.md, test it by giving Claude a task that would normally trigger one of your rules. If you wrote “No default exports,” ask Claude to create a new component and check whether it uses a named export.

You can also ask Claude directly:

# Ask Claude what it knows about your project
> What conventions does this project follow?

# Check context budget
/context

The /context command shows how much of the context window your session is consuming (for example, “450k/1000k tokens”). If CLAUDE.md is eating a disproportionate share on a project with a small codebase, the file is probably too long.

When a rule is not working, the most common causes are ambiguous phrasing and file length. “Format code properly” is vague. “Run prettier after editing .ts files” is actionable. If Claude keeps ignoring a specific instruction despite clear phrasing, the file may be too long for Claude to weigh every rule consistently. Prune first, then re-test.

When Should You Move Rules to .claude/rules/?

CLAUDE.md at the project root loads into every single request. For a 30-line file, the cost is negligible. For teams with extensive standards (style guides, architecture docs, testing protocols), the root file can grow past the point where it is effective.

The alternative is .claude/rules/. Files in this directory load selectively based on what Claude is working on. A rule about database migrations loads when Claude touches migration files. A rule about API conventions loads when Claude edits endpoint handlers. The per-request cost drops because only relevant rules enter the context.

my-project/
├── CLAUDE.md                     # Universal rules (20-30 lines)
└── .claude/
    └── rules/
        ├── database.md            # Loads when touching DB code
        ├── api-conventions.md     # Loads when editing endpoints
        └── testing.md             # Loads when writing tests

Start with everything in the root CLAUDE.md. Move rules to scoped files only when the root file grows past 50 lines or when you notice Claude dropping instructions. The next lesson covers adding skills, which is the next layer of customization beyond rules.

What's next

Keep building on what you just learned.

Frequently Asked Questions

Build faster with AI-powered agents

See how Codegen automates the full development workflow — from ticket to pull request.

Get Started →