When andrej karpathy tweeted his "LLM wiki" in April he got many people excited. one of whom was me. The simplicity of the concept was to allow someone to take years of their own note-taking, and not have to re-create all the synthesized content each time they returned to a subject. Create it once, add deltas periodically, and move on. For the last several weeks, I extracted approximately 2300 pages of my roam research into Obsidian, then developed a small family of Claude skills. These skills use unprocessed notes as sources instead of processed ones. compile-wiki-node is the synthesizer; capture-topic, summarize-work-conversation, conversation-ideas-extract and youtube-obsidian-batch all feed it. Closed book rule: no web searches during synthesis, no information the model happened to learn from its own training, and any conflicts were logged with provenance (i.e., why), as opposed to silently resolving them: this is what gives any of it credibility. After two weeks the nodes already seem to be compounding.
Sample Wiki Node: A sample compiled node created from my notes is available below. This document contains personal information including names and details from private conversations, so it shares the same password as the vault.
The Reframe
I ran across andrej karpathy's "LLM wiki" tweet regarding the storing and retrieval of information, specifically for one's own notes. The idea is deceptively simple: knowledge does not have to be re-created for every query. Compile it once. Update it via deltas. Be done.
This is the general outline. Traditional note taking requires a fresh walk-through of your existing notes anytime you come back to a particular subject. You derive the synthesized content from scratch; the same connections are made anew; judgment calls are made again. Deriving synthesized content is an expensive process. The output is not saved in a durable location; therefore, you must go through the same derivation process again when returning to that subject later. Karpathy's assertion is that this is an incorrect loop. You should have persistent, compiled documentation per entity, i.e., company, person, theme, which becomes more robust over time. New sources are added to the compiled documentation. No piece of documentation ever derives the entire documentation from start-to-finish again.
Getting out of RoamResearch
Since 2020 i've been writing in RoamResearch five days a week. Approximately 2300 pages of daily, atomic notes, linked together with [[links]], encompassing both personal and professional topics. All of my data exists within a proprietary format that models cannot directly access. At some point i decided to get out of RoamResearch and create a second brain.
The first step was structural rather than complex. It involved getting help from Claude, and exporting all of my data to markdown, loading it into Obsidian and putting the directory where Claude could find it. With the vault converted into a directory containing .md files on disk, i could now reuse every skill i'd previously written for another project that could also access my notes. Vendor lock-in was the cost i paid without realizing it. While RoamResearch initially showed great promise in terms of new feature development and integrating AI into its platform, little of either has occurred in recent years. What a mess!
Obsidian is simply a text editor that treats the file system properly. What provides value is that the files are yours; they're plaintext; and any future or past version of a model can point to the vault without migrating.
Notes as Feedstock
Karpathy's suggestion wasn't about changing the input to a Note, rather he suggested moving the Note out of the category of "deliverables" and turning it into the "feedstock" for a new piece of content, which will live in a separate directory. The raw notes stop being the deliverable. They become the source material for a separate, compiled artefact that lives in a different folder.
In the old model, when I wanted to think about a company I opened Roam, found the pages, read them, and held it all in my head long enough to make a decision. The head was the compiler. When I closed the tab the compilation was gone. Next time, I did it again.
In the new paradigm, each item has two files associated with it: one in Pages/, where all the raw material exists (daily Notes, Transcripts, Chat captures); and one in Wiki/, where the compiled version of that information resides. The Pages/ folder contains all the raw materials captured throughout the day, while the Wiki/ folder contains the compiled versions of those items. The model does the compilation; I edit the compiled output; the artefact remains.
The Capture Skills
Compiling from empty and the output won't seem promising or meaningful at the start: the vault needs to be fed first. So the skills I actually wrote first were the capture skills, the front doors.
capture-topic converts a chat search session into a single .md file in Pages/ based upon a date. After spending hours with Claude researching a company or a particular philosophical thread, and saying "capture this", the skill creates a Page in Pages/YYYY-MM-DD Topic.md format and includes automatic links to Wikilinks and tags. This represents the difference between thinking about something and having it in the vault.
summarize-work-conversation takes a voice transcript or Notes from a phone call with another investor (long, possibly in multiple languages including Hindi-English heavy calls) and adds them as a structured Note in Notes/. Additionally, summarize-work-conversation automatically appends a linked list of bullet points from that call to a relevant Speakers.md page (if it already exists). As such, each speaker now has a running log of their comments from across all conversations. Those comments are also cross-linked to the companies and themes discussed.
youtube-obsidian-batch performs this same function monthly for video notes. Each month I paste a series of bullets generated via Gemini from the videos watched during that month. youtube-obsidian-batch then compiles those bullets into individual notes and generates a master index.
conversation-ideas-extract is probably used less frequently than any of these other functions, but is relied upon very heavily. conversation-ideas-extract searches every one of approximately 2,300 pages and provides answers to structural queries (such as who has mentioned Idea Y across all conversations; or which companies have been referenced by Person X). Completeness is the whole product: the skill's job is to extract every idea from every dated chat, not just the ones I later summarised.
The key aspect of building capture skills is that you can always run the compiler again, if you have enough data. You cannot however re-run a capture on a conversation you never captured.
The Compile Skill
compile-wiki-node is essentially the synthesizer. Provide it with an entity name (a company, a person, a theme like Meditation or AI Investing): it then processes everything in your vault that references that entity, compiles or updates that entity's node in Wiki/, and applies tags to every claim linking it to the original file.
The final skill that I created was likely my 3rd or 4th iteration. My first attempts failed because Claude could not determine what my notes looked like, therefore its synthesis could not properly identify the structure necessary for compiling. Voice transcripts are different from filings; filings are different from daily-bullet notes; and each requires different treatment by the compiler. Ultimately, what allowed me to create a successful compiler was working back and forth with Claude for two or three sessions providing examples from both Notes/ and Pages/, and allowing Claude to develop an index/ontology atop my source notes: an index/ontology describing how to differentiate between conversation notes; capture pages; relationships between speakers; companies; and themes. At that point, the compiler begins processing with an understanding of my note structure.
The rewarding bit is in getting your LLM to do the work in understanding the structure of notes. The actual model call at the end is short. All engineering work is providing sufficient scaffolding: index, examples, hierarchy, to allow Claude not guessing.
Closed-Book Discipline
Two consequences follow that took me a while to fully accept.
The first is that the vault's holes become visible. If I've never captured anything about the CFO of a company, the node's CFO section is empty: not "here's what training data says," not a plausible sentence, but empty, or flagged [not in vault]. That emptiness is the whole point. It tells me where I actually have coverage and where I've been fooling myself.
The second is what happens when two sources in the vault disagree: say a 10-K says 4,000 stores and an investor call says 5,000. The old instinct (and Claude's instinct, unsupervised) is to pick a winner or paper over the difference. The skill instead logs both, with their original source paths, and marks the row as an unresolved conflict. The conflict is the point of building or invalidating a thesis. Silently resolving it is the failure mode.
Every skill I've written over the last three months has moved further in this direction: training data is not a source, the vault is the world, gaps are honest output. It works here for the same reason it works in the workflow I use to generate initiation reports: the model can't reliably tell what it retrieved from what it recalls, but a closed source list is a set-membership test that a hundred lines of Python can enforce.1
Two Weeks In
The nodes look like they're compounding. The clearest signal is that when I add a new source like a youtube summary, a new call transcript, my research notes on something I just read and re-run the compile, the node gets sharper, not just longer. New evidence sometimes corroborates an existing claim, sometimes contradicts it (which the conflict-logging catches), sometimes adds a dimension the node didn't have. What I'm not seeing, which I was worried about, is monotonic bloat: the compiled node isn't drifting toward "everything I've ever said," it's staying focused on what the entity actually is.
Two weeks is not a real test but the direction seems right.
If You're Building Your Own
Some of this is specific to how I work; most of it is generic. The patterns that would generalise if you wanted to try the same shape on your own notes:
In summary ...
The meta-observation, since this is now the third or fourth skill family I've built along these lines: I keep trusting the model with less and building more scaffolding around it. The scaffolding (indexes, ontologies, closed source lists, provenance tags, failure logs) is where the domain knowledge actually lives. The model is the fast, patient reader that fills the shape the scaffolding defines.
What I'm curious about is how much of the scaffolding survives as models get better across horizontals, not particulary verticals. There's a version of the future where a model trained on enough of the world does the ontology-building on the fly and the harness collapses to a single prompt. There's another version where the domain knowledge in the harness (my notes, my ontology, my failure log, my sense of what a good source is) is what makes any of it useful, and general capability across horizontals increases don't touch that at all. My guess is closer to the second. To be seen ...