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.

Update, July 11, 2026: on the author's setup the nightly dream gained two companions. Since July 9, an idle-sync: a Stop hook registers each finished turn, and a 15-minute scheduled task memory-syncs any session left idle for 30 minutes by resuming it headless. Since July 10, the sync wrapper also commits and pushes the vault to a private git remote, keeping a phone clone of the brain converged. Division of labor: the idle-sync is the trickle, the dream remains the deep nightly cleanup. The quick-setup module's hooks lesson has the anti-loop guards this requires.

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.

A pocket brain: Claude Code on Android, git-synced

The logical endpoint of a git-versioned second brain: the same memory, on your phone, driven by a native Claude Code. Not the official remote-control option (piloting your PC from the phone), but Claude running on the Android device itself, inspecting and acting on the phone, and reading the same vault as your desktop. The author deployed exactly this in July 2026; here is the runbook with the traps pre-sprung.

The platform is Termux, a Linux terminal environment for Android, installed from F-Droid, never the Play Store (the Play Store listing has been a dead build for years; a newer fork exists there but restricts binary execution). Add the Termux:API companion app (same source, same signature) for phone integrations: notifications, clipboard, sensors, speech. Claude Code itself installs via a community installer that downloads Anthropic's official linux-arm64 binary and verifies its SHA256 (recent versions need a glibc compatibility patch on Android's Bionic libc, which the installer handles). Audit any such community script before running it, the way the safety module teaches: read it, confirm it fetches from official domains, check what else it touches.

Authentication has a trap and a rule. The trap: browser OAuth from inside Termux often loops. The reliable path is generating a long-lived token on your desktop with claude setup-token and placing it in the phone's environment (CLAUDE_CODE_OAUTH_TOKEN): usage stays covered by your subscription. The rule: never wire a pay-per-token Console API key into a device that runs agentic sessions in your pocket. The second trap wears a costume: first launch may fail with a permissions error about reading / (Claude Code ignoring the sandbox's temp directory). The fix is running it through proot with the temp directory bound, wrapped in a shell alias, at which point login and sessions behave.

The brain link is the payoff. Clone your vault repo in Termux, then symlink the phone's session memory path (~/.claude/projects/<home-slug>/memory) to the clone. Desktop and phone now read and write the same brain. Automate the sync with the hooks you already know: a SessionStart hook pulls (fast-forward only, timeout, never blocks), a SessionEnd hook commits and pushes. Add the desktop's idle-sync on the other end and the two devices converge within minutes of any change, no manual step. A second small repo can carry your config (CLAUDE.md for the phone, a curated skill subset) with an idempotent bootstrap script, so reflashing the phone rebuilds everything in one command.

Android-specific survival kit, each item earned the hard way:

• Android's phantom process killer silently kills long tasks: disable child-process restrictions in developer options, and take a wake-lock for long runs (fold termux-wake-lock into the launch alias so it is automatic).
• The bundled ripgrep is broken on ARM64: install the system one and point Claude at it (USE_BUILTIN_RIPGREP=0).
• Low RAM: cap Node's heap (NODE_OPTIONS=--max-old-space-size=512).
• Mobile keyboards corrupt pasted && chains: run commands on separate lines, and enable character-based input in Termux properties.
• Storage access needs a one-time termux-setup-storage.

What do you actually do with a pocket Claude? Voice is the killer interface: a small loop script chains speech-to-text, claude -p (with -c to continue the conversation), and text-to-speech, launched from a home-screen widget. You dictate a thought walking out of a meeting; the phone writes it into the brain; the desktop pulls it before your next session. Scope honestly: without root, Claude can work files, notifications, clipboard, sensors and scripts, but cannot touch other apps' private data or system settings. It is a brain terminal, not a phone administrator, and that is exactly the job.