The second brain

File memory: never lose anything again

An LLM is amnesiac between sessions (lesson 1.1). The industrial fix: a persistent file memory that Claude rereads and updates. Pierre's system is the textbook case.

Principle: a memory/ folder where each durable fact is a markdown file with frontmatter (name, description, type: user / feedback / project / reference). A MEMORY.md file acts as the index: one line per memory, loaded on every session.

Three categories that structure everything:

• feedback: how Claude should work (corrections, preferences). With the why.
• project: the state of a piece of work, the decisions, the constraints not derivable from the code.
• reference: pointers to external resources.

A crucial discipline, codified by Pierre: update the memory after each delivered batch, not only at the end of the session. That way you lose neither detail nor context. And you only store what is not already in the code (git, the CLAUDE.md already tell it): you keep the non-obvious.

Obsidian: the navigable second brain

Pierre mounts his file memory as an Obsidian vault: the same single source, but visually navigable. The techniques that make the difference:

• Wikilinks [[note-name]]: each note points to related notes. You weave a network, not a pile of files. A link to a note not yet written is valid: it marks a gap to fill.
• MOC (Map of Content): hub notes (_MOC_feedbacks, _MOC_projects, _absolute_rules) that gather links by theme. A thematic entry point.
• Atomic notes: one fact per note, densely linked. Easier to find and recombine.
• Graph view: the visual map of the vault, to see clusters and gaps.

Pierre's "sync memory" protocol formalizes maintenance: create or update the note, weave its wikilinks to the related ones, add it to the right MOC and to the index. Not just reconciling the index: weaving the network. A second brain is worth its links, not its isolated files.

Graphify: querying a codebase instead of rereading it

Graphify (one of Pierre's skills) turns any folder (code, docs, papers, video) into a persistent, queryable knowledge graph. Pipeline: detect the files -> extract the AST (code) and the meaning (docs) in parallel -> detect communities (clustering) -> export to HTML/Obsidian/Neo4j.

The gain is huge and counter-intuitive: instead of rereading 30 files to answer "who calls this function?", you query the graph (/graphify query, /graphify path, /graphify explain). Per Pierre's measurements, up to ~71x fewer tokens than a reread. It is context optimization (module 7) applied to codebase knowledge.

His rule is to wire Graphify onto every project, new and existing, in local AST mode (free), via a graphify-init.ps1 helper, and to inject the graph into the Obsidian vault (_graphify\<project>). Git hooks refresh the graphs on every commit. Result: he has 8 repos + a brain-graph of hundreds of nodes, all queryable without rereading anything.

General lesson: for large knowledge bases, index once, query often beats reread on every question. True of code as of your memory.

Dream: automatic nightly consolidation

Pierre's dream skill applies the concept of memory consolidation (inspired by sleep) to his vault. A scheduled task launches it every night. In four phases:

1. Orient: get bearings in the existing memory.
2. Gather signal: reread recent conversations and the memory.
3. Consolidate: extract durable facts, merge duplicates, archive (never delete) contradictions, weave the links.
4. Verify: keep MEMORY.md as a clean index.

The whole thing respects his absolute rules: never delete (archive into a dated folder), no emoji, no em-dash, the index stays an index. A backup precedes each pass, and it runs headless.

This is the culmination of the second brain: a system that cleans and strengthens itself while Pierre sleeps. Daily practice (memory updated after each batch) provides the raw material; Dream digests, deduplicates and links it. Without that digestion, a memory grows until it becomes unreadable. With it, it stays alive.

Continuous learning: learning from your own practice

The top floor of the system: the continuous-learning skill. It scans the git history of the repos over 90 days, spots the recurring patterns (repeated commands, the same fixes, typed deployments, with an occurrence threshold) and proposes turning them into new skills or rules to add to the CLAUDE.md.

The idea is deep: your daily practice already contains the automations you need, in the form of repetitions. Rather than guessing them, you extract them from the data (the git history) and codify them.

The full loop of Pierre's second brain:

• He works (Claude Code sessions on his projects).
• He consolidates after each batch (memory); Dream digests at night.
• Graphify indexes the code into queryable graphs.
• Continuous-learning extracts the repeated patterns into new skills and rules.

Result: a system that gets better every session with no dedicated effort. This is the expert level of using Claude: not just using the tool, but building around it a machine that learns.

Atomic notes

An atomic note contains exactly one idea, one fact, or one decision. The word "atomic" means indivisible: you cannot split the note further without losing meaning. In a second brain (a personal knowledge system that stores and connects information outside your head), atomic notes are the smallest useful unit.

Large, multi-topic notes create a filing problem: you never know which category owns them, and retrieving one fact means reading everything else. Small notes have a single home and a single job. They also recombine freely because each one stands on its own.

The power of atomic notes comes from linking. When each file holds one idea, connections between files become meaningful. A note on "context window limits" can link to "chunking strategy", "token counting", and "prompt caching" without duplicating content. Claude Code and tools like Graphify (a code graph injector Pierre uses) can traverse those links and surface relevant notes without re-reading thousands of lines.

• One idea per file: if you use "and" in the title, split the note.
• Descriptive title: the title should make the content predictable from a search result.
• No orphans: every new note gets at least one link to an existing note.
• Prefer nouns: name the concept, not the project ("token budget", not "Monday's token issue").

Wikilinks and maps of content

A wikilink is a double-bracket reference like [[note-title]] that creates a clickable connection between two notes. In Obsidian (the note-taking app used as a second brain), every wikilink you write becomes a visible edge in the graph view. When Claude reads your vault, those links are also readable metadata: they tell it which concepts are related without you having to repeat the explanation.

A map of content (MOC) is a note whose sole job is to list and link other notes on a topic. Think of it as a hand-curated index. Unlike a folder, an MOC can appear in multiple contexts and can link across topics. Common naming conventions: _MOC_projects, _MOC_skills, _MOC_reference.

Together, wikilinks and MOCs give your vault two navigation modes:

• Backlinks: every note shows which other notes point to it, so you can trace where an idea is used.
• Hub traversal: you open an MOC and click through to any subtopic in seconds, no search required.

When you ask Claude Code to update memory, instructing it to add a [[wikilink]] to the relevant MOC and to MEMORY.md means the new note is immediately reachable from two entry points. The graph stays coherent without manual maintenance.

Types of memory

Claude Code organises persistent knowledge into four memory types, each stored in a different file and loaded at a different moment. Understanding which type to use prevents clutter and makes sure the right context arrives at the right time.

• User memory: global preferences and rules that apply across every project. Stored in ~/.claude/CLAUDE.md. Examples: your name, preferred language, no-emoji rule, commit style.
• Project memory: facts specific to one codebase. Stored in .claude/CLAUDE.md at the repo root. Examples: tech stack, folder conventions, environment variable names, branch strategy.
• Feedback notes: lessons learned from mistakes or corrections. Named feedback_*.md in your vault. Examples: "never delete, always archive", "no jq on Windows, use node". They are referenced from MEMORY.md so Claude loads them on demand.
• Reference notes: stable factual documents Claude may need to consult. Named reference_*.md. Examples: API workflow, quota limits, tool versions. They are not rules but lookup tables.

The separation matters because user memory loads unconditionally on every session, so it must stay short and universal. Project memory loads only when Claude starts inside that repo. Feedback and reference notes are loaded on demand via links in MEMORY.md, keeping the active context window (the working memory Claude holds during a conversation) lean.

A common mistake is writing project-specific rules into user memory, or dumping every fact into one huge file. Keep each note atomic (one topic per file), link it from the right index, and Claude will retrieve exactly what it needs without wasting tokens (the unit that measures how much text Claude can process at once).

Recall instead of rereading

Every time you ask Claude to re-read a source file just to answer a question, you spend tokens (the units of text the model processes) on content your notes already summarize. At the Expert level, the habit to build is query your notes first, open the raw file only when the note falls short.

A well-maintained second brain (your Obsidian vault or any linked note system) stores the distilled meaning of each file: key decisions, entry points, gotchas, and cross-links. Asking Claude to search that graph costs a fraction of asking it to read dozens of source files from scratch. With a tool like Graphify (a code-graph builder that maps your repo into nodes and edges), a single graph query can replace reading an entire module tree.

The workflow has three tiers:

• Tier 1 - recall: ask Claude to query your notes or graph for the answer.
• Tier 2 - targeted read: if the note points to a specific file and line range, read only that slice.
• Tier 3 - full read: use this only when the note is stale or the question is structural and genuinely new.

This tiered approach is how a senior engineer works with a large codebase: mental model first, source file only as a last resort. Your notes are your mental model on disk.

Piping conversations into the brain

Every Claude Code session you have ever run is a rich record: prompts, reasoning chains, code edits, and outcomes. By default those sessions sit in a local log directory and go unread. Piping conversations into the knowledge graph means exporting those logs, parsing them, and injecting them into your Obsidian vault (your second brain) so Claude can search them in future sessions without re-reading raw text.

The export step uses claude-extract, a small Node utility that reads Claude Code session files (stored under ~/.claude/projects/ as JSONL files, where JSONL means one JSON object per line). On Windows, set PYTHONUTF8=1 before running any Python-based variant to avoid encoding errors with accented characters.

Once exported, the transcripts land in a folder (conventionally _conversations/ inside your vault). Graphify then ingests them: it builds an AST-style graph (AST stands for Abstract Syntax Tree, a structured map of relationships) that links session nodes to project nodes, to skill nodes, and to memory notes. The resulting graph can reach thousands of nodes and lets Claude answer questions like "what did we decide about door geometry in Plan2Tour?" by traversing graph edges rather than re-reading hundreds of files.

• Session file location: ~/.claude/projects/<encoded-path>/, one JSONL per session.
• Export command: claude-extract (run with PYTHONUTF8=1 on Windows).
• Destination: _conversations/ folder inside your Obsidian vault.
• Graph refresh: run graphify update <repo> or trigger the scheduled task that runs nightly.
• Query payoff: graph traversal costs far fewer tokens than reading raw transcripts, up to 71x less in large vaults.

Nightly refresh

A second brain (your Obsidian vault linked to Claude Code) is only as good as its freshest data. Code changes daily, new notes accumulate, and the knowledge graph (the map of connections between files, functions, and notes) drifts out of sync overnight. Scheduled consolidation is the practice of running automated jobs at a fixed time each night to pull everything back into alignment before the next work session starts.

Two complementary jobs cover this: a graph refresh (re-scanning all repos with Graphify to update AST nodes and edges) and a dream pass (a consolidation agent that reads recent notes, promotes important insights into permanent memory, and weaves new wikilinks). Running them sequentially, graph first then dream, means the dream agent always reasons over the freshest graph.

On Windows, Task Scheduler handles both. Each job calls a PowerShell script that changes into the right directory, invokes claude headless with a prepared prompt, and logs the result. The key flags are:

• --print: run one turn non-interactively and print the response, then exit.
• --model claude-opus-4-8: use Opus for the dream pass (reasoning-heavy); use claude-sonnet-4-6 for the cheaper graph-metadata summary.
• --output-format text: write plain text output that the script can append to a log file.
• --max-tokens 2048: cap output to avoid runaway cost on an unattended job.

The result: every morning your vault index is current, your memory notes carry last night's insights, and Claude Code loads a graph that reflects what actually exists rather than a stale snapshot.