Claude Code Memory: How CLAUDE.md and Skills Compound

TL;DR

• Claude Code memory lives in CLAUDE.md files, not in chat history.
• You can stack CLAUDE.md at global, project, and folder level.
• A memory directory stores reusable context that loads across sessions.
• Skills are pre-built instruction sets that compound over time.
• The more you build these files, the smarter Claude gets at your work.

What is Claude Code memory?

Claude Code memory is not stored in a conversation. The moment a session closes, the context is gone. But your CLAUDE.md files stay. That is the whole idea.

When Claude Code starts a session, it reads CLAUDE.md files automatically. These files carry your rules, your preferences, your project context. You write them once. Claude reads them every time.

That is the foundation of Claude Code memory. Not a database. Not a chat log. Plain markdown files that load before any message is sent.

If you are new to the tool, start with the complete Claude Code guide. It covers the basics before you get into memory strategy.

How does CLAUDE.md actually work?

CLAUDE.md files load in a specific order. Global first, then project-level, then any subfolder files. Each one adds more context.

Global lives in the .claude folder in your home directory. This is where your personal rules go. Things like Australian English, no em dashes, your timezone, how you like code formatted. Every project you open inherits this.

Project-level lives at the root of your repo. This is where project-specific rules go. Your tech stack. Your naming conventions. Your business context. What the project does and who it serves.

Subfolder-level lives inside a specific folder. If you have a blog agent that needs different rules to your dev agent, drop a CLAUDE.md inside that folder.

Claude reads all three. The more specific file wins when there is a conflict.

Writing CLAUDE.md once is maintenance. Writing it well is compounding.

For a full breakdown of how to structure these files across a project, read the CLAUDE.md strategy guide.

What goes inside a CLAUDE.md?

Keep it practical. Here is what actually belongs in one.

Project context. Who the client is. What the site does. What success looks like. Claude cannot guess this.

Rules that never change. Australian English. No em dashes. No banned words. These go in global so you never repeat them.

Tech stack. What framework you are using. What component library. What to never touch. This stops Claude from suggesting something that breaks your setup.

Naming conventions. File names, component names, folder structure. Claude will follow them if you write them down.

Anti-patterns. Things Claude tends to do that you do not want. Write them explicitly. "Never add inline comments to code you did not change." That kind of thing.

Agent instructions. If you run specialised agents (developer, QA, content, SEO) each one can have its own CLAUDE.md in its working folder. The instructions are scoped. No bleed.

The cleaner the file, the more useful it is. Long walls of text slow Claude down and dilute the signal.

What is the memory directory?

The memory directory is a folder, usually .claude/memory/, where you store structured context files that persist across sessions.

This is different to CLAUDE.md. CLAUDE.md carries rules and instructions. Memory files carry facts and state.

A memory file might hold your client list. Your active projects. What happened in the last session. Key decisions you made. Things you never want to repeat. References you keep coming back to.

The memory index, usually called MEMORY.md, acts as a map. It lists all the memory files and what each one contains. Claude reads the index and pulls relevant files as needed.

The feedback file is underrated. Every time you correct Claude, write it down. "Stop recommending Prisma for this project." "Always check the config before suggesting priorities." Over sessions, these corrections build up. Claude starts getting things right the first time. This is what compounding looks like in practice.

How do skills fit in?

Skills are reusable instruction sets for specific tasks. They live in a skills folder as SKILL.md files.

A skill might cover how to write a blog post. It lists the exact format, the voice rules, the link requirements, the word count, the FAQ structure. Every blog post follows the same standard because the skill file never changes.

Without a skill, you explain the requirements every session. With a skill, you run it once. Claude reads the file and executes.

Skills compound in a few ways. Quality compounds, because once a skill is tuned, every output matches it. Speed compounds, because a well-written skill cuts the back and forth. And team compounds, because if you run multiple agents, they all follow the same shared skill files. The Claude Code skills guide covers how to build these from scratch.

What makes this compound over time?

Most tools get more complex as you use them. CLAUDE.md-based memory gets simpler.

In week one, you write a rough CLAUDE.md. Claude makes mistakes. You correct them. You add the corrections to the file or to your feedback memory.

In month one, the files are sharper. Claude makes fewer mistakes. The feedback loop speeds up. You spend less time correcting and more time building.

In month six, the context is deep. Claude knows your stack, your voice, your clients, your anti-patterns. Sessions start fast because Claude already understands the situation.

This is the compounding effect. The files get better. The outputs get better. The time cost drops. It is not magic. It is just good documentation that Claude can read.

The best Claude setup is the one that gets out of your way and lets you build.

What about settings and permissions?

Memory and skills sit on top of a permissions layer. Claude Code lets you control what tools are available, what files can be read or written, and what commands can run.

Getting this right matters. If the permissions are too tight, skills cannot execute properly. Too loose, and Claude can touch things it should not. The Claude Code settings and permissions guide covers how to configure this so your memory system actually works.

How does this work at Devwiz?

At Devwiz, the whole operating model runs on CLAUDE.md files and skills.

Every client project has its own project-level CLAUDE.md. Every agent has its own folder with a CLAUDE.md. Skills cover blog posts, client onboarding, weekly planning, accountability, meeting summaries, and more.

The global CLAUDE.md carries the rules that never change. New projects start with a template that already has the right structure. You fill in the project-specific bits and the context is live. Sessions open fast. Claude knows where it is and what the rules are. The work starts immediately. That is what good Claude Code memory looks like in a real workflow.

FAQ

What is the difference between CLAUDE.md and the memory directory?
CLAUDE.md carries rules and instructions. The memory directory carries facts and state. Rules tell Claude how to behave. Memory tells Claude what is true about your project right now.

Does Claude remember between sessions automatically?
No. Claude does not have persistent memory by default. Everything you want carried across sessions must be written to a file. CLAUDE.md files and memory directories are how you do that.

How often should I update CLAUDE.md?
Update it when Claude makes a mistake you want to prevent in future. Add the correction to the relevant file. Small updates as you go work better than a big rewrite once a month.

Can I use skills across multiple projects?
Yes. Global skills live in your home .claude folder. Any project can read them. Project-specific skills live inside the project. If a skill is useful everywhere, put it in global.

---

If you want to see what a fully built AI workflow looks like in practice, book a session here. We will walk through your setup and show you where the compounding starts.