How Should Beginners Set Rules for Claude Code?

Many people new to Claude Code put their effort into writing a smarter prompt, rewording again and again, and the results still swing: sometimes the change is far too broad, sometimes working code gets broken, and sometimes an hour of fixing ends with the bug still there.

The cause is often the missing working rules in the project, which Claude Code can't read, and the prompt is only part of it. It works willingly, yet it doesn't know which pitfalls your team already hit, which directory is off limits, or that some code that looks redundant is there for legacy compatibility.

A CLAUDE.md in the project can explain all of that. What to put in it and how to write it so it works can be worked out from a few questions, and twelve beginner-friendly working rules plus a template you can adapt give you a quick start.

More rules aren't always better. What matters is that Claude Code follows a process.

01 Why You Need CLAUDE.md

Many beginners who start with Claude Code focus on "how to write a smarter prompt." That matters, but it isn't enough.

What really decides whether Claude Code is reliable is whether your project has a clear set of working rules. Without rules, it behaves like a new hire nobody is mentoring: it can work and wants to work, but it easily misjudges the project's background, changes too much, and may even break code that was working fine.

CLAUDE.md writes those rules down. It's a project handbook for Claude Code. Every time it enters the project, Claude Code reads it first and learns how the project runs, which files matter, what to do before changing code, and how to verify after changing it.

If you're just starting with Claude Code, the first thing to do is write an actionable CLAUDE.md for your project, not learn more advanced commands.

02 Four Common Beginner Mistakes

Claude Code is powerful, but it doesn't know your project. It doesn't know which pitfalls your team has hit, which directory must not be touched, or that some code that "looks redundant" is actually there for compatibility with old logic.

Beginners commonly make four kinds of mistakes.

Giving a goal without background

For example, saying "fix the login problem." That instruction is too rough. Claude Code first guesses where the login logic is, then guesses why it fails, and finally makes a change that looks reasonable but doesn't fit how your project actually works.

Asking for code changes without asking for verification

Much code looks correct but doesn't run. Without tests, a build, lint, or reproduction steps, Claude Code tends to stop at "I've made the change" instead of "I've shown it works."

Asking it to do too much at once

For example: "Refactor the user system, optimize the API while you're at it, and fix the page styling too." The scope is too big. Claude Code handles several directions at the same time, and in the end it's hard to tell whether each change was necessary.

Having no prohibitions

If you don't say "don't refactor unrelated code," it may tidy up a pile of files along the way. If you don't say "don't delete existing tests," it may remove failing cases just to make the tests pass.

CLAUDE.md exists to solve these problems.

03 Five Questions CLAUDE.md Should Answer

An effective CLAUDE.md answers at least five questions.

First, what is this project? Claude Code needs to know the project type, the tech stack, and the core business. For example, is it a Next.js app, a Node.js service, a Python script, or a documentation project?

Second, how does the project run? The commands to start, test, build, and format must be written out clearly. Don't make Claude Code guess every time whether to use npm, pnpm, or yarn.

Third, what should it look at before changing code? In some projects the entry point is in src/app, in others in pages, and in some the key logic is hidden in lib or services. Write out the key directories to cut down on pointless searching.

Fourth, what are the boundaries for changes? For example: don't edit database migration files, don't edit generated files, don't do unrelated refactoring, don't change the public API, and don't add new dependencies.

Fifth, how will it prove the work is done? This is the most important one. Claude Code needs a clear acceptance method: which test command to run, which page to check, and which endpoint to confirm is responding normally.

If CLAUDE.md only says "please write high-quality code," it's basically useless. Rules must be specific enough to act on.

Claude Code’s project memory documentation likewise recommends build commands, coding standards, and workflows in CLAUDE.md, expressed as specific project instructions.

04 12 Working Rules for Beginners

You can put these 12 rules straight into your CLAUDE.md and adjust them to fit your project.

Understand the project structure before changing anything. Before you start, read the project directory, the entry files, and the related modules. Don't change things right away.
Find the root cause first, not just the symptom. Many bugs show up on the page, but the root cause may be in the API, state management, or a permission check.
Solve one clear problem at a time. Beginners most often describe tasks too broadly, and big tasks must be split up.
Don't do unrelated refactoring. AI likes to "tidy up while it's there," but in a real project that adds risk.
Don't delete existing code casually. This applies especially to tests, compatibility logic, configuration files, and type definitions.
Ask when unsure. The danger with Claude Code is that it sometimes guesses, and writing "ask when unsure" into the rules reduces careless mistakes.
Read the relevant files first, and don't scan the whole project blindly. Reading lots of files blindly wastes tokens and blurs the focus.
For long files, locate first, then read. Reading the whole file in is inefficient and easy to get wrong.
Do complex tasks in stages: plan first, then execute, then verify.
Explain the plan before changing anything. The plan doesn't need to be long, but it must be specific: which files will change, why, and how to verify.
Explain the changes afterward. Don't just say "done." Say what changed and what it affects.
Always run the verification commands. Without verification, the code only looks finished.

If the project has no tests, also ask Claude Code for an alternative way to verify, such as starting the page, calling the endpoint, or checking the output files.

For the verification rule, Claude Code’s official best practices recommend giving it a command that can report whether the work passes or fails.

05 A CLAUDE.md Template Beginners Can Use Right Away

Here's a short template. Copy it into your project root and replace the placeholders with your own information.

# CLAUDE.md

## Project Overview
This is a [project type] project, mainly used for [project goal].
Tech stack: [framework / language / database / build tool].

## Common Commands
- Install dependencies: `pnpm install`
- Start development: `pnpm dev`
- Run tests: `pnpm test`
- Lint: `pnpm lint`
- Build: `pnpm build`

## Key Directories
- `src/`: core source code
- `src/components/`: components
- `src/lib/`: shared utilities and business logic
- `tests/`: tests

## Working Rules
- Read the relevant files before changing anything, and confirm the call chain and root cause.
- Give a short plan before changing anything. Don't start editing right away.
- Solve only the current task. Don't do unrelated refactoring.
- Don't delete existing code, tests, or configuration casually.
- When requirements or business rules are unclear, ask first.
- After changes, state which files were changed and why.
- After changes, run the relevant tests, lint, or build commands.
- If something can't be verified, explain why and what the risk is.

## Prohibitions
- Don't add new dependencies unless the user explicitly agrees.
- Don't edit generated files.
- Don't change unrelated styles or formatting.
- Don't delete tests just to make them pass.
- Don't change database migrations or the public API without confirmation.

Keep the template short. A CLAUDE.md is valuable when its rules are accurate, not when it holds a lot of information.

06 How to Turn an Ordinary Instruction into a Good One

Once you have CLAUDE.md, your everyday instructions should be more specific too.

For example, with "fix the login bug for me," Claude Code can only guess. Change it to "Users get logged out when they refresh the page after logging in. Read the authentication code first, find the root cause, explain your plan before changing anything, and run the tests when you're done," and the results will be much better.

A good instruction usually has four elements: the goal of the task, the scope of changes, the constraints, and how to verify. Once those four are clear, Claude Code's output becomes noticeably more stable.

07 More Rules Aren't Always Better

Many beginners turn CLAUDE.md into a thick manual. They stuff in the project background, the business introduction, API documentation, and meeting minutes. That backfires.

CLAUDE.md should hold information that is stable, long-lived, and used often: project commands, what each directory is for, coding standards, the verification process, and prohibitions.

Leave out three kinds of content: long tutorials (Claude Code doesn't need to read a course to change code), information that changes often (temporary requirements and today's task can just go in the current conversation), and empty phrases ("think carefully" and "make sure of quality" have no standard to act on).

A better approach is to keep iterating. Does it often change the wrong directory? Write "don't change this directory." Does it often forget to run tests? Write in the test command.

CLAUDE.md is the accumulated record of your project's collaboration rules, not a document you finish in one sitting.

08 The Real Key: Make AI Work Through a Process

Claude Code is very capable, but strong capability has to be paired with a clear process.

The most common beginner mistake is treating Claude Code like a wishing well: make a wish and expect the right result to appear. A more reliable approach is to treat it as a new teammate who can get work done: give the background first, then the boundaries, then the acceptance criteria.

The value of CLAUDE.md is that Claude Code guesses less, changes less at random, and skips verification less often.

A good CLAUDE.md does at least three things: it helps Claude Code understand the project faster, it makes the scope of its changes more controllable, and it gives every change a closed verification loop.

Just starting with Claude Code? Don't rush into complicated tricks. First write a short, specific, actionable CLAUDE.md for your project, with the common commands, key directories, working rules, and prohibitions spelled out.

From that step on, AI coding goes from "depends on luck" to "delivered through a process."