Three stores, four depths, one folder name. Once you see the pattern, the whole configuration model collapses into a single idea.
We build it up one layer at a time. Each picture is the previous picture with one thing added.
There is no memory database and no account-level profile. Three things get called memory, they have different authors, and all three are plain text on your own machine.
Local storage is not the same as local processing. The durable copy stays on the workstation, but when a session loads one of these files its contents go to the API as part of the prompt, exactly like any source file Claude reads.
In your home directory there is a folder called .claude. That is where your version of everything sits: your instructions, your procedures, and the memory Claude keeps per repository.
One folder per repository under projects\, so every worktree and checkout of the same repo shares one memory. Two developers on the same codebase build separate memories, and neither sees the other's.
Not an illustration. A working laptop, with the runtime clutter stripped out.
$ ls -R ~/.claude ~/.claude/ ├── CLAUDE.md your standing preferences ├── projects/ one folder per repository │ ├── -home-you-Projects-alpha/ │ │ ├── memory/ auto memory lives here │ │ └── *.jsonl transcripts │ └── -home-you-Projects-beta/ ├── settings.json permissions, hooks └── skills/ your procedures ├── agent-guardrails/ └── designing-evals/
Everything on the previous slide is here. Nothing hidden, nothing you cannot open.
A second .claude lives in the codebase itself, and it is committed. That is the whole difference between a habit you have and a standard your team has.
The nesting is about audience, not disk. A repository is not inside your home folder. It is drawn inside because it reaches fewer people, and that is the variable worth reading off this picture.
Two more layers exist, one outside yours and one inside the repository. Four in total, and the only thing separating them is where the folder sits.
The instruction files add up rather than replacing each other, read from the outside in.
Key conceptWhere a file sits decides who it applies to. Same folder name, four audiences.
Some of these files are read at the start of every session and cost you context whether they are relevant or not. The rest sit on disk until Claude reaches for them.
This is the whole argument for keeping a CLAUDE.md short. A skill contributes only its one-line description until Claude actually uses it, so a long procedure is free until the moment it is needed.
A skill is a folder with a SKILL.md in it: a written procedure. Nothing new to learn about where it goes, because it goes exactly where everything else does.
Put a procedure in the repository and every developer who clones it has it. Put the same file in your home folder and it helps one person. That choice, and nothing else, is your distribution mechanism.
The distinction that saves the most trouble. Both live in the same four folders, and only one of them is a control.
People reach for the left when they need the right, then wonder why it held nine times out of ten instead of ten. If it has to be impossible rather than discouraged, it is not a written instruction.
Check any of it yourself: /memory lists the files, /context shows what actually loaded, /doctor tells you why something is not taking effect.
tutto.one/praxis · daniel@tutto.one