Lesson 4: The .claude folder, memory, rules and tools 90% of users never open

After this lesson, you'll understand how Claude Code organizes its “brain” through the .claude folder, know how the three layers of instructions (machine-wide, per-project, per-company) stack up, know how the /init command produces CLAUDE.md in one go, and master the rules for writing CLAUDE.md smartly. Frankly, most people using Claude Code out there haven't grasped this content.

The hidden folder named .claude

In programming there's a convention: a folder with a dot before its name (like .claude) is a hidden folder, which the file manager doesn't show so as not to clutter the view. Claude Code keeps its whole advanced toolkit in a folder like this, placed right in your project folder.

A fully equipped .claude folder looks like this:

• settings.json: permission settings + hooks (hooks are scripts that run automatically before or after each action the machine takes, for example ringing a bell when the machine finishes a job; there's a separate lesson on this later).
• settings.local.json: a configuration that exists only on your machine. The word “local” in the file name means this does not get pushed to the shared code repository (GitHub), meant for sensitive things like access keys.
• rules/: a folder holding the rule files, split out from CLAUDE.md.
• agents/: where the “sub-employees” are defined (lesson 9).
• skills/: where the “professions” you teach the machine live (lesson 7).

You do not need to build the full set right away. Even the original instructor of the source course admits that he normally uses only CLAUDE.md, adding skills and agents when needed. What you need today is know these buttons exist, so when the work comes you know which drawer to open.

Splitting CLAUDE.md into rule files

As a project grows, the CLAUDE.md file swells: design rules, security rules, work process, naming conventions… crammed into a single file of a few thousand words that's hard to manage and hard to spot redundancy in. The rules/ folder exists to split it up: one rule file for each area (for example design-rules.md, workflow.md, security.md).

The nice part is you don't have to split it by hand. Just tell the machine: “split this project's CLAUDE.md into rule files following the Claude Code rules standard”. It reads, divides and files them into the folder itself. After the split, when you want to change a design rule you touch exactly one file, with no risk of accidentally breaking the security rules next to it. Teamwork gets easier too: give the designer rights to edit the design rule file, while the team lead keeps the overall process.

Three layers of instructions stacked together

Here's a point many people misunderstand: there isn't just one CLAUDE.md. There are three layers, and the machine reads all three each time it opens a session:

1. Personal, machine-wide layer: located in your home folder (~/.claude/CLAUDE.md). Instructions here apply to EVERY project on the machine. Good for personal tastes: how to address you, which language, the absolute prohibitions.
2. Project layer: the CLAUDE.md file in the project folder (learned in lesson 2). It applies only to that project.
3. Company layer: for enterprise licenses, where administrators set rules for the whole organization. Most of you won't need to touch it.

How companies organize it: the boss holds the top layer and sets the general rules (“do not delete these files”, “address staff this way”), and each employee adjusts the project layer for their own part of the work. Sounds familiar? It's exactly how a company runs on general house rules + a job description for each department. At MONA we use this exact model for the software projects running every day.

/init: one command produces CLAUDE.md

Jumping into an existing project folder that doesn't have a CLAUDE.md yet? Type /init. The machine skims the whole folder, figures out what the project does, then writes a summary CLAUDE.md: what the project is, what the architecture is, how it's deployed, which conventions to remember.

Why is it worth doing, when the machine “can read the files anyway”? Because of money and quality. Without a summary, every new session the machine has to dig through a pile of files again to understand the context: that costs tokens (meaning money), and the longer the prompt, the lower the average answer quality. That is a statistical property of AI models. So CLAUDE.md has a second role beyond “steering the ship” from lesson 2: it is compressed copy of the context, helping every session start light, cheap and smarter.

Rules for writing CLAUDE.md: do and don't

Distilled from heavy users, plus our own daily experience:

Do:

• Run /init first in every new folder.
• Write with bullet points and short headings, compressing the information. If you want to compose by voice, ramble at length and then tell the machine to “compress this into a high-information-density rule set”.
• Put the most important things at the top of the file. AI models (and people) remember the beginning well, the end fairly well, and the middle vaguely. A vital prohibition like “never delete file X” belongs on the very first line.
• The machine makes the same mistake a second, a third time? Say so right away: “write this into CLAUDE.md so that next time a new session doesn't make this mistake.” That's how this file truly grows: every stumble becomes a line of rules.
• Treat it like living code: clean it periodically and delete lines that have lost their value. Left uncleaned for long, it swells on its own.

Don't:

• Don't dump entire API guides or whole style handbooks in. 10,000 tokens get reloaded every time you open a session: slow, expensive, and it makes the machine dumber. When you need an API, tell the machine to filter out just the part it uses.
• Don't write vague rules: “be smart”, “don't make mistakes”. The machine can't do anything with those, just like an employee can't do anything with an instruction like “please try to do better”.
• Don't go past about 200-500 lines. Longer means you're stuffing it, so go back and split into rules.

Memory: the machine's own notebook

Besides the three CLAUDE.md layers, there's one more file loaded at the start of each session: memory, an automatic notebook. You say “remember, my younger brother is named George”, and the machine writes it in the notebook; in the next session, another machine instance asked “what's my brother's name” can answer right away. The difference from CLAUDE.md: memory is notes the machine writes for itself, while CLAUDE.md is the rulebook you write for the machine. Put important things in CLAUDE.md to be safe, and don't entrust them to the machine's notebook.

Try it yourself before moving on to lesson 5

1. Open any project folder (or the web folder from lesson 2), type /init, read the CLAUDE.md the machine writes itself and edit it to your liking.
2. Tell the machine an important prohibition and ask it to put it on the first line of the file.
3. Ask the machine to split CLAUDE.md into 2-3 rule files in rules/.
4. Try the memory feature: tell the machine a piece of personal information, close the session, open a new one and ask again.

Lesson 5 covers what decides safety when you let the machine touch real things: the four permission modes, including the notorious “skip permissions” mode, and plan mode, the planning mode that people building complex systems treat as their main weapon.