claude-second-brain: A Second Brain That Outlives the Apps
My knowledge about my own life was scattered across four machines and a dozen Claude projects, and none of them agreed on what I knew.
A MacBook Pro, a MacBook Air, an always-on Mac Mini, and a Windows work laptop. The notes I needed for a call were in a project on the wrong device. The context I had spent an hour building up with Claude on one machine meant nothing the next morning on another. And every few months some new app would promise to be the one true home for all of it, so I would dutifully pour everything in, only to watch that app get acquired, abandoned, or quietly enshittified a year later.
I have been on this treadmill for fifteen years. Evernote to Notion to Obsidian to whatever was next. Each migration cost me a weekend and a little more trust. So this spring I did the thing I should have done ages ago: I stopped trying to pick the right tool, and built a convention instead.
The realization
The mistake was thinking the app was the asset. It isn't. The asset is the knowledge. The app is just a thing that reads it, and apps die.
Once I framed it that way, the answer got obvious and a little boring. If I commit to a structure rather than a product, I never have to migrate again. The tools become interchangeable. The files stay.
So claude-second-brain is not an app. There is nothing to install. It is a documented agreement about how a folder of markdown files is laid out, plus a small pile of scripts that help set it up and keep it tidy. That is the whole thing, and the boringness is the point. Markdown is readable in any editor, diffable in git, greppable from a shell, and parseable by every LLM without a special integration. It is infrastructure, and infrastructure should be boring.
One source of truth, many readers
The design comes down to three rules.
First, one source of truth, many readers. Everything lives as markdown under a single root folder. Claude Desktop reads it. Claude Projects reads it. The API reads it. A future tool I haven't heard of yet reads it. I read it in any text editor. Nobody owns the data except me.
Second, context cascades from general to specific. Shared knowledge sits at the top and flows down to everything beneath it. A fact about me at the root applies to every conversation. A fact about one project applies only to that project. Anything that primes an LLM walks up the tree and composes exactly the context it needs, no more.
Third, it works flat, works nested, works partial. An empty tree still works. Every file I add just makes it a little smarter. Migration is never required, only addition. That last rule is what makes the whole thing survivable - I can adopt it lazily, and it never punishes me for an incomplete brain.
What the tree looks like
At the root there are a couple of always-loaded anchors: a short MEMORY.md digest of who I am and what I am focused on this week, and a _journal/ of daily running notes. Next to those is a global _meta/ folder of context that applies to every conversation - who I am, the people I work with, my jargon, how I like to work.
Below that, the tree splits into life areas. One top-level folder each for personal life, the day job, and the various SaaS apps and hobby projects I have going. Inside a life area are projects, and inside a project are two small files that do a surprising amount of work: an _index.md that says in one paragraph what the project is, and a _meta/ folder of reusable context that gets primed into any LLM call scoped to that project.
The files I care most about are the ones that make a downstream agent sound like me instead of generic Claude. There is a voice-calibration.md for how I write, the phrases I use, my sign-offs. There is an anti-ai-writing-style.md listing the LLM tells to avoid: em-dash storms, "delve", performative agreement, the empty closing paragraph that says nothing. (This post was written against that file. If it reads like a person, that file is part of why.) There is a thinking-models.md for how I actually reason through a decision, and a global-instructions.md that is the behavioral contract every LLM in the brain follows.
There is also a _meta-private/ for the things that should never touch a work-managed account: personal contacts, finances, the stuff I would not want on the company laptop.
Four machines, one brain
A convention only earns its keep if it is identical on every machine. I run four, and each one declares its role in a tiny per-machine config file while a sync layer keeps the tree consistent across all of them.
The Mac Mini is the always-on agent host. It holds a full copy and runs the scheduled work. (It does not have to be a Mac Mini - a Linux mini-PC, a NAS, a Raspberry Pi, or a cheap VPS would all do the job.) The laptops are interactive machines, full sync, whatever OS runs Claude or a text editor.
The interesting one is the Windows work laptop. It should never see my personal life or my side projects, so it selectively syncs exactly one life area plus the global _meta/. The privacy boundary is enforced by the sync tool's folder-level selective sync, not by any code I had to write. I use Google Drive Desktop for this because it is native on Mac and Windows and handles that boundary for free, but the sync layer is deliberately replaceable - Syncthing and Dropbox both work. The files do not care how they get from one machine to another.
Before I trusted any of this with real data, I ran a validation gate script that stress-tests cross-device sync - propagation lag, conflict frequency, what happens when two machines write at once. It passed. Then I moved in.
The part I am most excited about
Because one machine is always on, it can run agents that quietly curate the brain over time. Re-classify a stale inbox item once there is more context to place it. Render a one-page dashboard every fifteen minutes of what is open and what is drifting. Pull mail across several accounts and file per-area summaries where they belong. None of these belong to any single app - they are small scheduled scripts that call a model and write markdown back into the same tree everything else reads.
The agents are themselves markdown files. An agent is a file with a little frontmatter (name, schedule, which scopes it touches, which host runs it) and a plain-language description of the job. Two ship in the repo as examples - a calendar sync and a daily dashboard renderer - both switched off until the runtime is fully in place.
The hard part was never the agents. It is the review loop. Anything that writes back to my brain needs a way for me to approve changes before they land, so the design leans on "propose, don't impose": agents write to a proposed sibling location or surface a morning digest of pending edits, and nothing mutates my real files without a nod from me. That is the genuinely unsolved design problem, and I would rather get it right slowly than wrong fast.
Why this one might stick
Every previous system I tried was a bet on a company. This one is a bet on a file format that has outlived every app that ever opened it. Claude is the best reader of this tree today, and I built it with Claude in mind, but the format is deliberately compatible with other markdown-native runtimes too. If something better than Claude shows up, my brain comes with me. That has never once been true before.
It is early. The convention is documented and in daily use, with more scaffolding and per-platform sync guides landing as the need becomes obvious. Convention first, tooling second. It is open source and MIT licensed, and I would genuinely love eyes on the structure, especially from anyone who has migrated their brain one too many times and is also tired of it.