DEV Community

Cover image for Second brain 101: what your AI loads at session start, and what it drops
Malik Chohra
Malik Chohra

Posted on Originally published at codemeetai.substack.com

Second brain 101: what your AI loads at session start, and what it drops

TL;DR

  • An operating system for your AI is one folder it reads before it works and writes back to when it learns. The folder takes an afternoon. The write-back is the part that makes it a system.

  • Not all of it loads. One short index file loads at session start, and a detail file gets opened only when something in the index points at it. Past 200 lines or 25 KB the rest of the index is dropped, quietly, with nothing in the transcript to tell you.

  • CLAUDE.md is read first and in full, and the runtime walks up the folder tree from wherever you launched. Put it one folder down and it is not there at launch. It gets read later, on demand, the first time your AI opens a file in that folder. Mine is 41,480 bytes and lives in 00-Meta/, so 8 of my 31 commands pull it in by name and the other 23 do not.

  • Rules are read. Hooks are run. Anything that has to happen every time, and not most times, is a hook.

  • The receipt after a few months of this: 465 memory notes, 474 entries in my own decision log, 454 in both places under the same filename, 441 carrying the write-back footer. I typed none of it.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real products, receipts included.

AI for techies ยท 10. Last time I went through how to create your own commands, which is one saved job you run again by typing one word. This one is about the place all those jobs run inside.

By now you have the pieces. An instructions file. A skill or two. A command you actually use. Maybe a second agent you hand the boring half of a job to.

Each one works. None of them is broken. And you still open a new session by explaining where things are, which project, what you settled last week, why that folder is named that.

This is mine. Every dot is one file, every line is a link between two of them, and the folders down the left are the whole filing system.

Graph view of my Obsidian vault. Several hundred note dots wired together by link lines, with the numbered PARA folders listed down the left side.

the pile of parts problem

The pieces do not know about each other.

What your AI worked out on Monday is not in the file it reads on Tuesday. It found the answer, you moved on, and the answer stayed in a chat window that is closed now. Next week you ask the same question and it starts from nothing.

So you pay for the same thing twice. Once to work it out, and once to hold it in your own head well enough to say it out loud again.

A pile of good parts is not a system. What makes it a system is that the end of one session is the start of the next one.

an operating system is one folder and one loop

One folder your AI reads before it works, and writes back to when it learns.

That is the whole sentence. The folder is the easy half and you can build it in an afternoon. The loop is the thing: read, work, write back, and the next session opens on what the last one learned.

Two halves. On top, three pieces file into one folder and stop. Below, a closed circuit runs read, work, write back, and returns into the next session's read.
A folder is a one way trip. The loop is what sends the next session back in.

the eight parts

Most of these you already run one at a time.

  1. The folder. Files on disk, sorted by what you are doing with them. That is all it is.

  2. The memory. Your AI writes its own notes and keeps them in its own folder, not in yours, which is how you give it a memory. Mine holds 465 of them.

  3. The rules. A CLAUDE.md is the file that gets read first, in full, before any work starts, and what you write down once is most of the job.

  4. The skills. One kind of job, saved as a folder. It costs you nothing until it is used: your AI sees the name and one line about when to reach for it, and opens the body only when a job matches.

  5. The agents. A second AI with an empty head. It does not get the main session's memory, and that is the one that catches people out. What it needs goes in the prompt you send it, or it works blind. Six of these sit in my personal agents folder.

  6. The hooks. Rules are read, hooks are run, and this one is where I went through them properly. A hook is a small program the tool itself runs at a fixed moment, whatever the model decides. I have seven, on four moments: before a tool runs, after a tool runs, when I send a prompt, and when the session stops.

  7. The commands. A prompt you saved in a file, so you type one word instead of ten lines.

  8. The write-back. At the end of a session, what was learned gets written back into the folder it was read from. Nobody writes about this one, and it is the part that turns seven good pieces into a loop.

what actually loads, and what does not

This is where the tidy version is wrong, and being exact here saves you an afternoon of wondering why your AI ignored a note you can see on disk.

Pointing it at your notes folder does not mean it reads your notes.

One short index file loads at the start of every conversation. A detail file gets opened only when something in the index points at it. So the index has a budget, and it is a hard one: past 200 lines or 25 KB, the rest is dropped. Quietly. Nothing in the transcript says a word about it. Mine sits at 117 lines and 22,252 bytes, which is closer to that ceiling than I am comfortable with.

Skill bodies behave the same way. Name and trigger line up front, body on request.

Hooks sit apart from both, because a hook is the only one of the three that is not a suggestion.

Three bands in load order. At session start: the rules file walking up the tree, plus the memory index. Opened on request: 464 memory detail files and skill bodies. Set apart below: the hooks, which run whatever the AI decides.
The folder holds 465 files and the index is one of them, so the detail files are 464.

where your CLAUDE.md really sits

The runtime walks up the folder tree from wherever you opened the session and reads every CLAUDE.md it finds on the way. In full, before any work starts.

So placement is load-bearing. Put it where you start, not one folder down.

Mine is 41,480 bytes and it lives in 00-Meta/. There is no CLAUDE.md at the top of my vault. When I open a session at the top, that file is not loaded at launch.

It is not invisible either, and this is the part that gets stated wrong in both directions. It gets read later, on demand, the first time my AI opens a file in that folder, which is after the work has already begun. Eight of my 31 commands pull it in by name, so those eight get it up front. The other 23 do not.

If a rule has to be in the room from the first token, the file has to sit at the level you launch from. Otherwise you are relying on the work happening to walk past it.

three ways in

The effort climbs with each one.

It already does some of this. Auto memory is on by default, and any CLAUDE.md above your working folder is read in full when you launch.

You ask for it in plain words. Say "remember that". Say "add this to CLAUDE.md". Say "save that as a skill". It writes the file, in the right place, and you never have to learn the folder layout. /init will write you a first CLAUDE.md from the project you are sitting in.

You set it up so it is always there. The docs are blunt about the difference: "Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer." So anything that must happen every time is a hook. Not a line of instructions.

Three rows of rising effort. It already does it, auto memory and rules files read at launch. You ask for it, remember that or save that as a skill. You set it up, a hook, because a rule is read and a hook is run.
A rule is read. A hook is run. That is the whole difference between rows two and three.

the loop on my own disk

My /endSession command has a phase 3, and it is a few lines of plain English. New facts about how to work with me or my projects go to memory files, plus one line in the index, plus a stub in the vault's decision log.

Here is what those few lines produced.

The memory folder holds 465 notes. My own decision log holds 474. 454 of them exist in both places under the same filename, and 441 carry the same footer line saying they were written out from the memory bank.

I did not type any of that. The session that learned the thing wrote it down on the way out, and the next one opened on it.

That is the loop. The folder my AI read from is the folder it wrote to.

where to start

Do not build the whole thing. Pick the one thing you explained to your AI twice this month.

At the end of your next session, say: write that into CLAUDE.md so you have it next time. Then open a new session tomorrow and check whether it did.

If it did, you have a loop, and everything after that is filling it in.

If you would rather not start from empty, the prompt that builds the whole folder is in my guide, Build a second brain with Obsidian and Claude Code. Paste it in and it writes the files for you.


This one came from Code Meet AI, the newsletter where I write up the setups I actually run and the numbers come off my own disk. Next episode is how to keep this working once the folder gets big.

Top comments (0)