Most people write a CLAUDE.md that lists their tech stack and calls it a day. That is the bare minimum. The real power comes from the rules you put inside it — the sections that change how Claude thinks, plans, and self-corrects.

This guide breaks down the 7 sections that turned Claude Code from a basic code generator into an autonomous developer that plans before building, fixes its own bugs, tracks its own mistakes, and never ships half-baked work.

Every section below is something you can copy straight into your own CLAUDE.md today.

1. Force Plan Mode

What to add:

## Planning Rules
- Enter plan mode for any 3+ step task
- Outline every step before writing a single line of code
- Wait for my approval before implementation

Why it matters:

This is the single biggest time saver. Without this rule, Claude jumps straight into building — and when it gets something wrong three layers deep, you spend more time undoing bad decisions than you would have spent planning.

With this section, Claude stops and asks first. It maps out the approach, lists the files it will touch, flags potential issues, and waits for your green light. Only then does it start coding.

The result: no surprise refactors, no "why did you do it that way" moments, and no hours lost reversing bad architectural decisions.

When you will feel the difference: The first time Claude outlines a 10-step implementation plan and you catch a wrong assumption before a single file is created.

2. Subagent Strategy

What to add:

## Subagent Rules
- Use subagents to keep the main context window clean
- Offload research, exploration, and parallel tasks to subagents
- Reserve the main thread for decision-making and implementation

Why it matters:

Claude Code has a context window limit. Every message, every file read, every error log — it all takes up space. When the window fills up, Claude starts forgetting earlier instructions and decisions.

Subagents solve this. Instead of dumping everything into one conversation, you tell Claude to spin up a subagent for research, exploration, or parallel tasks. The subagent does the work and reports back with a summary. Your main thread stays clean and focused.

This is how you throw more compute at hard problems without sacrificing context quality. Think of it as having multiple junior devs working in parallel while you manage the main thread.

When you will feel the difference: When you are deep into a complex feature and Claude still remembers every decision from the start of the session — because the research noise never touched the main thread.

3. Improvement Loop

What to add:

## Learning Rules
- After any correction, update tasks/lessons.md with the mistake and the fix
- Review lessons.md at the start of every new session
- Never repeat a documented mistake

Why it matters:

This is permanent memory that actually evolves. Every time Claude makes a mistake and you correct it, Claude logs the lesson. Next session, it reads the lessons file first and avoids the same error.

Over time, the mistake rate drops every single week. Claude is literally learning from its own errors across sessions — something most people never set up because they do not think of CLAUDE.md as a living system.

Your tasks/lessons.md becomes a growing knowledge base of everything Claude has gotten wrong and how to do it right. The longer you use it, the smarter Claude gets with your specific project.

When you will feel the difference: When you realize Claude has not repeated a mistake in weeks — and you check lessons.md and see 30+ entries Claude wrote itself.

4. Verification Rules

What to add:

## Verification Rules
- Never mark a task done without proving it works
- Run tests, check logs, and diff the changes before reporting completion
- Ask yourself: 'Would a staff engineer approve this?'

Why it matters:

Without this section, Claude writes code, says "done," and moves on. You trust it, push the code, and discover it is broken in production.

With verification rules, Claude has to prove the work is complete. It runs the tests. It checks the logs. It diffs the changes. It asks itself whether a senior engineer would approve the output.

This is the difference between shipping code that "looks right" and shipping code that works. No more half-baked PRs. No more "I thought that was done" moments.

When you will feel the difference: When Claude finishes a task and sends you a verification summary with test results, log output, and a diff — without you asking for it.

5. Autonomous Fixing

What to add:

## Bug Fixing Rules
- When given a bug: just fix it. No hand-holding.
- Read the logs, find the error, trace the root cause, and resolve it
- Do not ask me clarifying questions unless you genuinely cannot determine the issue

Why it matters:

Most people paste an error and then answer 5 follow-up questions from Claude before it even starts fixing anything. That is a waste of your time.

With this section, Claude sees the bug, reads the logs, traces the error, and fixes it. Zero context switching required from you. You paste the error, walk away, and come back to a working fix.

This only works well when combined with a solid CLAUDE.md that already has your project context, common issues, and architecture documented. Claude needs enough background to fix things independently — and with the right CLAUDE.md, it has exactly that.

When you will feel the difference: When you paste a stack trace, go make coffee, and come back to a clean fix with an explanation of what went wrong and why.

6. Task Management

What to add:

## Task Management Rules
- Write plan to tasks/todo.md before any implementation
- Check in before building, mark items done as you go
- Never start a new task without updating the task file

Why it matters:

This turns Claude into a self-managing developer. Before it writes a single line of code, it writes the plan to tasks/todo.md. As it works, it checks items off. If it gets interrupted or the session ends, the next session picks up exactly where it left off.

Think of it as Claude running itself like a junior dev with a manager watching. There is built-in accountability. You can open tasks/todo.md at any time and see exactly what Claude has done, what it is doing, and what is left.

This also prevents scope creep. Claude sticks to the plan because the plan is written down and it has to check items off in order.

When you will feel the difference: When you start a new session and Claude reads todo.md, tells you what is left from last time, and picks up exactly where it stopped.

7. Core Principles

What to add:

## Core Principles
- Simplicity first. No laziness. Senior developer standards.
- Every output gets judged against these three rules
- If the solution is complex, simplify it. If the code is sloppy, rewrite it. If a senior dev would not approve it, it is not done.

Why it matters:

This is the section that ties everything else together. Without a quality bar, Claude optimizes for speed. It takes shortcuts. It writes verbose code when concise code would do. It over-engineers when simplicity is the answer.

With core principles at the top of your CLAUDE.md, every single output gets filtered through three questions:

  1. Is this the simplest solution?
  2. Is this lazy or thorough?
  3. Would a senior developer approve this?

If the answer to any of those is wrong, Claude rewrites it before showing you. This is one section — but it changes everything about the quality of output you get.

When you will feel the difference: When Claude rewrites its own output mid-task because it caught itself being lazy — and you did not even have to say anything.

The Full Template

Here is every section combined into a ready-to-use template. Copy this into the root of your project as CLAUDE.md and customize it for your stack.

# CLAUDE.md

## Core Principles
- Simplicity first. No laziness. Senior developer standards.
- Every output gets judged against these three rules.
- If the solution is complex, simplify. If the code is sloppy, rewrite. If a senior dev wouldn't approve, it's not done.

## Planning Rules
- Enter plan mode for any 3+ step task.
- Outline every step before writing code.
- Wait for approval before implementation.

## Subagent Rules
- Use subagents to keep the main context window clean.
- Offload research, exploration, and parallel tasks.
- Reserve the main thread for decisions and implementation.

## Bug Fixing Rules
- When given a bug: just fix it. No hand-holding.
- Read logs, find the error, trace root cause, resolve.
- Only ask clarifying questions if you genuinely cannot determine the issue.

## Task Management Rules
- Write plan to tasks/todo.md before any implementation.
- Check in before building, mark items done as you go.
- Never start a new task without updating the task file.

## Verification Rules
- Never mark done without proving it works.
- Run tests, check logs, diff changes before reporting completion.
- Ask: 'Would a staff engineer approve this?'

## Learning Rules
- After any correction, update tasks/lessons.md.
- Review lessons.md at the start of every session.
- Never repeat a documented mistake.

Customize the specifics for your project — add your tech stack, folder structure, naming conventions, and known issues below these sections. The 7 rules above are the foundation. Everything else builds on top.

Start Now

  1. Copy the template above into your project root as CLAUDE.md
  2. Add your tech stack and project-specific rules below the 7 sections
  3. Start a Claude Code session and watch the difference immediately
  4. Every time Claude makes a mistake, tell it to update tasks/lessons.md
  5. Every week, your Claude gets smarter and your mistakes drop

One file. Seven sections. A completely different Claude Code experience.

Want more Claude Code guides? Follow @liamjohnston.ai for daily AI tutorials and real builds.