Draft article
Building a Practical Second Brain with LLM Wiki
I have been using a simple Second Brain structure to keep project context, decisions, lessons, and raw material in one place. Nothing mystical: Markdown files, Git, Obsidian as a human interface, and a few skills that tell the AI how to operate the repository.
The point is not to build another note-taking ritual. The point is to reduce the amount of context I need to repeat every time I start a new session with an AI assistant. Repeating the same decisions, commands, paths, and project state is not knowledge work. It is overhead.
The idea is inspired by the LLM Wiki direction popularized by Andrej Karpathy: instead of treating memory as a pile of notes plus search, compile useful context into small, readable, linked pages that both a human and an AI agent can use.
The Shift: Human-Readable, AI-Operable
A useful Second Brain for AI-assisted work cannot be only a notebook you manually browse when you remember it exists. It needs to be readable by a human, but structured enough for an AI agent to operate without loading the entire history of a project into the context window.
This is where the LLM Wiki philosophy is useful. Instead of treating memory as a pile of raw files plus search, the system compiles knowledge into small, linked, explicit Markdown pages.
The important part is ingest-time compilation.
Read the raw source once. Extract the durable part. Save the compiled note. Link it. Move on.
For my personal workflow, that is often more useful than searching raw material every time I ask a question. If I have a deployment log, a resume PDF, a project discussion, or a schema, I want the system to compile it once into something atomic: decisions, lessons, pending tasks, project state, and references.
| Approach | What happens | Cost |
|---|---|---|
| Query-time search | Search raw material every time you ask | Repeated tokens, repeated ambiguity |
| Ingest-time compilation | Compile sources once into durable Markdown | Lower daily context cost, clearer answers |
The Three-Layer Contract
The architecture is intentionally boring. Boring survives. The contract has three layers:
C:\cerebro
|-- CLAUDE.md
|-- raw
| |-- inbox
| |-- clippings
| |-- scratchpad
| `-- projetos
| `-- rafael-borges-website
|-- wiki
| |-- index.md
| |-- log.md
| `-- projetos
| `-- rafael-borges-website
| |-- overview.md
| |-- decisoes.md
| |-- pendencias.md
| |-- sessoes
| `-- lessons
`-- .cortex
`-- skills
|-- cerebro.md
`-- salve.md1. Sources Layer: /raw
This is the human drawer. PDFs, notes, clippings, rough ideas, project inputs. The AI should not rewrite raw material. Raw is evidence, not polished memory.
2. Wiki Layer: /wiki
This is the compiled memory. Small pages, explicit links, project overviews, decisions, pending tasks, sessions, lessons, logs. The wiki is not a dumping ground. It is the version the AI can actually use.
3. Schema Layer: CLAUDE.md + /skills
This is where behavior lives. CLAUDE.md defines the system contract. Skills define operating procedures. They are not magic. They are just Markdown files that tell the model how to behave inside this repository.
The current working directory matters. CWD is scope. A model operating inside C:\cerebro should behave differently from a model operating inside C:\rafael-borges-website. That is not an advanced trick. It is basic context isolation.
The Daily Flow
In my current setup, Brain is not a heavy app. It is a repo, a contract, and a set of skills. The agent uses local files, shell tools, Git, and the current directory to stay grounded.
/cerebro: Scope and Briefing
Open the right context. Read the smallest useful set of files. For a project, that usually means overview.md,pendencias.md, decisoes.md, and the latest session. Not the entire wiki. Context is not free.
/capture: Compile Once
Take raw material and turn it into compiled memory. A resume, a PDF, a project note, a conversation, a schema. Extract the durable parts and save them into the wiki. Update the index. Register the source.
/sync: End-of-Day Loop
Save what changed. Update decisions. Move open items into pending tasks. Capture lessons when something is reusable. Record the project state. Git is the audit trail. The point is not ceremony. The point is continuity.
/lint: Semantic Cleanup
The boring janitor. Find broken links, stale pages, contradictions, oversized notes, and duplicated truth. Every knowledge base rots. The difference is whether you notice.
Why Keep It This Simple?
For this use case, I do not need a distributed orchestration platform to remember why I changed a website header yesterday. I need:
- local files;
- clear ownership between raw and compiled memory;
- small Markdown pages;
- skills as operating procedures;
- Git history;
- strict scope through CWD.
The less mystical the architecture, the easier it is to debug. If the AI writes bad memory, I can open the diff. If a decision changed, I can find the log. If a project loses context, I can inspect the session file. A small deterministic structure is easier to maintain than a system that depends on implicit memory and good luck.
The Template
I made the folder layout and boilerplate public here:github.com/rafaab1407/cerebro-layout.
It is not a product pitch. It is a starting point: raw inputs, compiled wiki, skills, logs, project folders, and enough structure for an AI agent to operate without pretending that search alone is memory.
The Payoff
Good engineering context reduces drag. I do not want to spend energy remembering where a decision was made, which command fixed a private GitHub push, or what the next step of a project was. That is bookkeeping. Machines are good at bookkeeping.
The human part should stay on the hard problems: architecture, tradeoffs, data, code, and judgment. Brain exists to keep the rest from leaking out of the system every time a chat window closes.