Building Compiled Second Brains
The core architectural shift: stop storing, start compiling.
vault/
raw/ ← input buffer only, never the answer
wiki/ ← compiled, cross-linked knowledge pages
output/ ← built from wiki, not from raw or memory
CLAUDE.md ← compiled profile of the person, read every session
Minimal first action for a new vault:
- Create the four items above.
- Run the CLAUDE.md interview prompt (below) to seed the profile.
- Drop one real source into
raw/and run the ingestion prompt. - Confirm the model wrote wiki pages, linked them to nothing yet (first source), and gave a three-sentence summary.
Progress:
- Step 1: Set up the four-part structure (
raw/,wiki/,output/,CLAUDE.md) - Step 2: Build CLAUDE.md via structured interview
- Step 3: Ingest first sources one at a time, reviewing wiki pages as they're written
- Step 4: Once 10-15 sources exist, set up the daily compilation loop
- Step 5: At 50-100 sources, evaluate whether non-obvious connections are surfacing
- Step 6: For active work, spin up project folders (Inputs/Process/Outputs/Feedback) instead of dumping into the general wiki
Step 1 — Structure. Nothing in raw/ is ever treated as an answer to a question — it's unprocessed input waiting for compilation. wiki/ is the only place knowledge lives. output/ (documents, posts, decisions) must be built from wiki pages, never from raw sources or from the model's unaided memory.
Step 2 — CLAUDE.md. This is not a static prompt. It's a living profile the model updates and reads before every session. Interview one question at a time; don't batch questions. Cover: identity/role, current goals, communication preferences, strengths/weaknesses, active projects. Write the result with clear headers at the vault root.
Step 3 — Ingestion. Each source should touch 10-15 wiki pages: new concept pages get created, existing pages get updated, links form to related pages, and contradictions with prior entries get flagged explicitly rather than silently overwritten. Always end ingestion with a short human-readable summary of what changed.
Step 4 — Daily loop. Automate (via Claude Desktop scheduled tasks) a daily pass that: files new raw items into the right wiki locations, flags stale notes (no update >2 weeks), checks for contradictions introduced by recent additions, and produces a morning brief of changes/links/flags/action items.
Step 5 — Density threshold. Before ~50-100 well-compiled sources, the wiki behaves like a slightly-better search index — this is expected and not a failure. The payoff (non-obvious cross-links surfacing on their own) appears after that density is reached.
Step 6 — Project isolation. For a bounded piece of work, don't mix it into the general wiki. Create a dedicated folder with Inputs/Process/Outputs/Feedback and its own CLAUDE.md defining the single goal, definition of done, and the model's specific role.
Example 1: New source ingestion
Input: A user drops raw/transformer-scaling-laws.pdf into the vault and says "process this."
Output: Model creates/updates wiki pages like wiki/scaling-laws.md, wiki/compute-optimal-training.md, links each to existing pages (e.g., wiki/chinchilla-paper.md), flags that this contradicts an earlier note claiming "bigger models always win," and returns: "Added 2 new pages, updated 3 existing ones, flagged one contradiction with your Jan note on model size — see wiki/chinchilla-paper.md."
Example 2: CLAUDE.md interview
Input: User says "set up my second brain."
Output: Model asks one question at a time — role, yearly goals, communication style, strengths/weaknesses, current projects — waits for each answer, then writes a structured CLAUDE.md with headers like ## Who I Am, ## Current Goals, ## Communication Preferences, ## Active Projects.
Example 3: Daily brief Input: Scheduled daily task runs. Output: "Filed 2 new notes from Inputs/ into wiki/marketing-strategy.md. Flagged wiki/q3-roadmap.md as stale (18 days, no update). No contradictions found. Recommend reviewing the new competitor-pricing note — it links to 3 existing pages and may change your Q3 assumptions."
- Treat
raw/as strictly disposable input, never a reference source for output. - Never let the model build
output/directly from raw material — force it through the wiki compilation step first. - Interview for CLAUDE.md interactively, not as a single giant prompt — quality drops when questions are batched.
- Curate sources deliberately. Since compilation propagates into many linked pages, source quality matters far more than in a simple search/retrieval setup.
- Expect and tolerate a slow start (first few weeks) — don't judge the system before ~50 sources are compiled.
- Use separate project folders (with their own CLAUDE.md) for active, goal-bound work instead of polluting the general wiki.
- Require the daily loop to always end in a human-readable brief — the human must stay inside the loop, not just receive silent automation.
- This setup assumes Claude Desktop with file system access and scheduled tasks on a paid plan — don't attempt on free tier.
- Treating raw/ as searchable knowledge. If someone answers a question by scanning raw files instead of the compiled wiki, the system has regressed into a filing cabinet.
- Skipping the CLAUDE.md interview and hand-writing a static prompt. This defeats the "living document" property — it should evolve and be re-read every session.
- Expecting non-obvious connections before reaching source density (~50-100). Below that threshold, a search engine does the same job — don't oversell early results.
- Ingesting low-quality sources without scrutiny. A bad source in a compiler touches many pages before it's noticed, unlike a bad document sitting alone in a library.
- Mixing active project work into the general wiki. Bounded projects need isolated Inputs/Process/Outputs/Feedback folders with their own goal-specific CLAUDE.md.
- Running this on free-tier Claude. Scheduled tasks and file system access are required for the compilation loop; without them the system is manual and will rot like any other note archive.