Editor's Note: The biggest problem many people face when using Claude Code isn't that the model isn't powerful enough, but that they start from scratch every time.

You need to repeatedly tell it the project background, tech stack, code conventions, which parts must not be touched, and which approaches have already been tried. As long as this information isn't fixed, Claude will work by guessing, potentially modifying files it shouldn't, refactoring code you didn't ask it to, or even recommending tools unsuitable for the current project.

The CLAUDE.md introduced in this article is a user manual written for Claude Code. You just need to place it in your project's root directory, and Claude will automatically read it on each startup. It tells Claude in advance: how to answer, how to write code, when to ask questions first, which operations cannot be performed without permission, what tech stack the project uses, and what important decisions were made in the past.

In short, the purpose of CLAUDE.md is to: reduce repeated explanations, limit the model's overreach, and make AI programming more stable and controllable.

If you are using Claude Code, you can start with the 4 rules summarized by Karpathy: ask if unsure, do the simplest solution first, don't touch unrelated code, and clearly state uncertainty. Start by writing these rules into CLAUDE.md, then gradually add to it based on your project, and you'll see a clear improvement in your experience.

The original text follows:

A file named CLAUDE.md topped GitHub's Trending list.

82k stars, 7.8k forks.

This began with Andrej Karpathy. He is the former Head of AI at Tesla and a founding member of OpenAI. He summarized four behaviors that would cause Claude Code to fail and wrote them into a file.

Later, a developer expanded upon these four rules and publicly released this file. It quickly went viral.

The reason is straightforward: coding accuracy increased from 65% to 94%.

But most developers who use Claude Code daily have never actually set this up. They start from zero every session: re-explaining the same context, cleaning up unnecessary scope changes, rolling back unrequested refactors.

Here is the complete file.

The Setup Most Developers Miss

Every time you open Claude Code, it starts knowing nothing by default.

It doesn't know your tech stack, your coding conventions, your project background, what you've already tried, let alone decisions you explicitly ruled out three sessions ago.

So it can only guess. And once it starts guessing, it might refactor code you didn't ask to be touched, recommend frameworks that would break your existing architecture, delete files without confirmation, or even overturn decisions you've already made.

CLAUDE.md is a plain text file placed in the project's root directory. Claude Code will automatically read it at the start of every session.

Set it up once, avoid repeated explanations, and fix three types of costly errors.

Default Settings: You're Spending $375 a Week Just Repeating Yourself

The average developer spends about 30 minutes a day re-explaining context to Claude.

Tech stack, coding conventions, project background, methods already tried—unless you write this information down once and have Claude read it automatically each time, it won't persist across sessions.

At a developer's hourly rate of $150:

· 30 minutes a day is $75;

· $375 per week.

· For a 5-person team, that's $1,875 in hidden costs weekly.

The following 7 rules should be placed at the top of the CLAUDE.md file.

→ Skip the Fluff

Don't start answers with "Great question," "Sure," "No problem," or similar prefaces. Get straight to the answer. No pleasantries, no restating the question.

→ Match Answer Length to Task

Answer length should match task complexity. Simple questions get direct, short answers; complex tasks get complete, detailed explanations. Don't pad length by restating the question or adding repetitive concluding remarks.

→ Give Options Before Acting

Before starting any significant task, first present 2–3 viable paths. Wait for my selection before proceeding.

→ Admit Uncertainty Before It Costs

If you are uncertain about any fact, data, date, or technical information, explicitly say so before referencing it. Don't fill knowledge gaps with plausible-sounding information. When in doubt, simply say you're unsure.

→ Who I Am, What I Know

About Me: [Name] / Role: [Your Role] / Background: [Domain].

I'm Proficient At: [What you're familiar with].

I'm Still Learning: [Knowledge gaps].

Adjust the depth of each answer based on this information. Don't over-explain what I already know, and don't skip context I need.

→ Current Project Context

I'm Working On: [Project Name] / Goal: [Specific Outcome] / Audience: [Who will use it] / Tech Stack Context: [Relevant Constraints] / Avoid: [List].

Apply this context to every task. If a request conflicts with the context, point it out before executing.

→ Lock Down Your Writing Style

My Writing Style Is: [Describe your style].

Sentence Length: [Preference].

Words I Use Often: [Examples].

Words I Never Use: [Examples].

Format: [Prose or Structured].

When writing anything on my behalf, you must strictly match this style. Do not default to your own expressive patterns.

Daily time spent re-explaining context: 30 minutes

At $150/hour developer rate: $75 / day

Weekly: $375 per developer

5-person team: $1,875 per week

Time to set up this part of CLAUDE.md: 45 minutes total

Mistake to avoid: Don't write CLAUDE.md from scratch. Start with the prompt below, then edit the output:

Based on what I've told you about myself, my project, and how I want to work, please write a complete CLAUDE.md file for me. Include: who I am, my technical background, my communication preferences, and default behaviors to follow each session. Be specific, plain text, under 500 words.

Behavioral Constraints: Those Unauthorized $150/Hour Changes

You ask Claude to fix a function.

It ends up refactoring three files, renaming variables, reorganizing imports, and rewriting comments you spent time on.

All without your confirmation.

Reviewing and rolling back these unnecessary changes might take an hour, which is $150. Happening three times a week is $450. For a 5-person team, that's $2,250 per week spent cleaning up unauthorized changes.

The following 7 rules should go in the Behavioral Constraints section of CLAUDE.md.

→ Strict Scope Control

Only modify files, functions, and lines of code directly relevant to the current task. Do not refactor, rename, reorganize, reformat, or "optimize" anything I have not explicitly asked you to change.

If you see something else worth fixing, note it at the end. Do not touch it. Never.

→ Ask Before Major Changes

Before making significant changes to content I've already created—including rewriting sections, deleting paragraphs, restructuring, changing tone—you must pause, precisely state what you plan to change and why. Wait for my confirmation before proceeding.

→ Must Confirm Before Any Destructive Action

Before deleting any file, overwriting existing code, deleting database records, or removing dependencies, you must pause, list what will be specifically affected, and request my explicit confirmation. You may proceed only if I say "yes" in the current message.

"You mentioned earlier" does not equal confirmation.

→ Mandatory Pause for Production Operations

The following operations require explicit confirmation within the current session, without exception:

· Deploying or pushing to any environment;

· Running migrations or database schema changes;

· Sending any external API calls;

· Executing any command with irreversible side effects.

· I must explicitly say "yes" in the current message.

→ Always Show What Changed

After completing any coding task, the end must include:

Files Modified: List all touched files;

What Changed: One sentence per file;

Files Intentionally Not Modified;

Follow-Up Items.

→ Do Not Act on My Behalf Without Explicit Confirmation

Do not send, post, share, or schedule anything on my behalf without my explicit confirmation in the current message. This includes emails, calendar invites, document shares, or any action happening outside the current conversation. I must explicitly say "yes" in the current message.

→ Think Before Coding

For tasks involving architectural decisions, complex problem debugging, or non-trivial feature development, first reason through the problem step-by-step before writing code. Show your reasoning, point out uncertainties, and then execute.

Weekly rollback of unnecessary scope changes: $150

Weekly manual diff checks: $75

Behavior-related waste per developer: $225 / week

5-person team: $1,125 / week

Time to set up CLAUDE.md Behavior section: 30 minutes

Memory & Tech Stack: The Setup That Makes Claude Code Truly Reliable

Claude forgets everything between sessions.

Every decision you've made, every approach that failed, why you chose Prisma over Drizzle six months ago, and why a particular constraint comes from a specific client requirement—it forgets it all.

Then, it re-proposes options you've long since ruled out.

This section is the closest thing to providing Claude with "real memory" for the current context, while also locking down your tech stack to prevent it from recommending tools that would break your existing architecture.

→ MEMORY.md Decision Log

Maintain a file named MEMORY.md in the project. Whenever an important decision is made, add a new entry:

· What was decided;

· Why it was decided that way;

· What was ruled out, and why.

Read MEMORY.md at the start of each session. Do not conflict with recorded decisions without prompting.

→ Session End Summary

When I say "session end," "wrapping up," or "let's stop here," write a session summary to MEMORY.md, including:

· What was handled;

· What was completed;

· What is still in progress;

· What decisions were made;

· Priorities for the next session.

→ ERRORS.md Failure Log

Maintain a file named ERRORS.md. When an approach has been tried more than twice without success, record it:

· What didn't work;

· What finally worked;

· What to watch for next time.

Check ERRORS.md before proposing solutions for similar tasks.

→ Permanent Fact List

The following facts are always true for this project and must be applied to every session without exception:

[Your permanent constraints, architectural decisions, and rules]

If a task conflicts with these facts, point it out before executing.

→ Lock Down the Tech Stack

The project's tech stack is as follows. Always use these tools. Do not recommend alternatives unless I explicitly ask:

Language: [e.g., TypeScript]

Framework: [e.g., Next.js 14]

Package Manager: [e.g., pnpm]

Database: [e.g., PostgreSQL with Prisma]

Testing: [e.g., Vitest]

Styling: [e.g., Tailwind CSS]

If a tool seems unsuitable, you can point it out. But unless I explicitly state otherwise, you must use the defined tech stack.

→ Enable Extended Thinking for Difficult Decisions

For problems involving system architecture, performance trade-offs, database design, or long-term technical decisions, use the extended thinking mode.

Analyze the problem step-by-step, point out trade-offs I might not have considered, identify assumptions that might not hold at scale, and then give your recommendation.

→ The 4 Viral Rules

Karpathy summarized 4 behaviors that cause Claude Code to fail. A developer distilled them into these 4 lines of rules. Coding accuracy increased from 65% to 94% as a result.

Ask, don't assume.
If anything is unclear, ask before writing the first line of code. Do not make silent assumptions about intent, architecture, or requirements.

Do the simplest thing first.
Always implement the simplest solution that works first. Do not add abstraction layers or flexibility not explicitly requested.

Don't touch unrelated code.
If a file or function is not directly related to the current task, don't modify it. Even if you think it could be optimized, leave it alone.

Explicitly mark uncertainty.
If you are unsure about a solution or technical detail, state it before proceeding. Acting confident without certainty causes more damage than admitting a knowledge gap.

· Weekly recovery cost from forgotten decisions and bad advice: $300 per developer

· Wrong tech stack recommendations and incompatible tools: $75 per week

· Memory-related waste per developer: $375 / week

· 5-person team: $1,875 / week

· MEMORY.md + ERRORS.md + Tech Stack setup time: 20 minutes

Conclusion

The full cost breakdown is as follows:

· Weekly cost of re-explaining context: $375

· Weekly cost of rolling back unauthorized changes: $225

· Weekly cost of handling problems from forgotten decisions: $375

· Total waste per developer per week: $975.

For a 5-person dev team: $4,875 per week. $253,500 per year.

Setting up CLAUDE.md only takes 2 hours in total.

Karpathy's 4 rules alone increased coding accuracy from 65% to 94%.

A plain text file, 21 rules, two hours of work.

Developers who complete this setup are effectively using a more reliable Claude: one that remembers decisions, controls task scope, asks for confirmation before destructive actions, and doesn't recommend frameworks that would break the existing architecture.

Those who haven't set it up are still spending $975 a week repeating themselves.

P.S.: Start with Karpathy's 4 rules. Just these 4. Paste them into a new file named CLAUDE.md in your project's root directory right now. It takes 2 minutes. Then gradually supplement it each week based on the gaps you discover.

Bookmark this before it gets lost in your feed. And if you find it useful, share it with someone who genuinely needs it.