Build Your Own Second Brain for Claude Code

Most "second brain" setups are just someone else's workspace in disguise — copy them and they fit like a borrowed suit. This one is different. Below are five principles and five paste-ready prompts that hand the work to Claude Code: it studies your files, your folders, your memory, and builds a second brain shaped around how you work.

The one thing to hold onto

Every workspace is different. The way your files, folders, and memory are organized is not the way mine are — so a copy-paste system fits badly. What transfers are the principles. Give these to your agent, let it study your workspace, and let it build your version.

What you need

• Claude Code, doing the heavy lifting.
• A workspace with some history in it — notes, projects, memory files. The brain needs something to organize.
• An hour or two of letting the agent work, checking in between steps.

How this works

Five principles, each with a starter prompt you can paste as-is. The prompts deliberately ask the agent to interview you before building — answering its questions is where your workspace's shape gets in.

graph TD
  R[1. Research what is working now] --> P[2. Stand on proven shoulders]
  P --> D[3. Deterministic code before the model]
  D --> I[4. A small index of everything]
  I --> V[5. Make it prove itself]
  V -- /goal: measure tokens and wall time --> V
  V --> B[A second brain shaped like YOUR workspace]

1. Research before you build

Don't start from your guesses. Have the agent pull what's working for people right now, then read your workspace, and only then plan. The combination of current best practice plus how your files look is what makes the plan fit.

Starter prompt:

research how people are building second brain / memory systems for claude code right now — reddit, x, youtube, hacker news, the lot. whats actually working, whats hype. then scan my whole workspace and describe how my files, folders and memory are organised today. combine the two into a short plan for a second brain that fits THIS workspace. before you build anything, ask me at least 3 questions about how i actually work.

2. Stand on proven shoulders

Four open-source memory projects are worth studying before building — not to copy, but to steal the right ideas from:

• Karpathy's LLM wiki — the foundation: plain markdown the agent writes itself, one small index read first.
• qmd (Tobi Lütke, Shopify's founder) — search by meaning, not just keywords.
• gbrain (Garry Tan, YC's CEO) — answers cite their sources; the brain cleans itself.
• Graphify (YC-funded) — your notes already form a graph; use the links.

Link or screenshot them into your prompt and ask the agent to judge what fits and what to skip.

Starter prompt:

before building, study these four open source memory projects: karpathy's llm wiki, qmd by tobi lutke, garry tan's gbrain, and graphify. for each one tell me what idea is worth stealing for MY setup and what to skip — with reasons. dont copy any of them wholesale. then update the build plan. ask me 3 questions if anything about my workspace is unclear.

3. Deterministic code before the model

This is where the savings come from. Most of a memory lookup needs zero intelligence — so it should be plain code, not model calls. The ladder the system climbs for every question:

1. Strip the question down to its keywords — filler words get discarded.
2. Score every possible source without opening any of them — using the index and file names alone.
3. Open only the top-scoring file — not three, not "just in case." One.
4. Read only the section that answers — not the whole document.
5. If that section just points somewhere else, follow the pointer once.
6. Only then does the model see anything — it gets the question plus the evidence, and answers in one go.

All of that runs in milliseconds because it's code, not model turns. The model is invoked exactly once, at the end.

Starter prompt:

build the retrieval path as plain deterministic code, not model calls. it should: strip my question to keywords, score every candidate source from the index WITHOUT opening files, open only the single best file, pull only the section that answers, and follow one pointer if that section points elsewhere. the model only gets involved at the very end, with the evidence already attached. also give me one simple command that stores a new memory — writes the file and updates the index in one step, no model needed.

4. Keep a small index of everything

The scoring trick above only works because the workspace keeps indexes and reference maps — one small catalogue file where every memory has a one-line entry, and a map of which big doc owns which topic. That's what lets code judge "where would this answer live?" without reading anything.

If you build one habit, build this one: every new fact gets a file and a line in the catalogue, every time. An index that's always true is what keeps retrieval cheap forever.

Starter prompt:

set up a single small index file that catalogues every memory in one line each — name, link, one-sentence description. make saving a new memory automatically add its index line so the catalogue can never drift from reality. then add a short routing note to my claude md so every session knows: check the index first, open files second.

5. Make it prove itself

Don't take the system's word for it — make the agent test its own build. Run the same questions through a fresh default session and through the second brain, then compare with /context (it shows exactly how many tokens the session burned) and a clock. If the brain isn't clearly cheaper, the instruction is simple: keep optimizing until it is.

One honest thing the tests will teach you: for facts that already sit in your always-loaded index, default retrieval is instantly fast — that's your index doing its job. The brain wins on the deep stuff: facts buried inside files, questions that need more than one file, and saving new memories.

Starter prompt:

now prove the system works. design a fair test: the same real questions from my workspace answered by a fresh default session vs the second brain path. compare tokens with /context and wall time for both sides, and check the answers are actually correct. if the brain doesnt clearly win, keep optimising and retesting until it does. show me the results in a simple table.

The /goal trick — make the agent check its own speed

The tip that made the biggest difference to quality: give the agent a /goal with a hard pass-fail line and permission to keep working until it's met. It will test its own build, catch its own lag, and iterate without you babysitting. Use this for the interactive parts — anything you click, drag, or reload.

Sample /goal prompt:

/goal make sure that moving things around and switching views in the interface never lags for me. actually load it and check your own work — dont just assume. keep optimising until its smooth.

Start here

Pick principle one, paste the first prompt, and answer the agent's questions honestly — that's the whole trick. Build it once, and every session after starts smarter. Hit a wall? Book a working session and we'll get it running.