Before Building the App, I Tried CLI and Obsidian First
I dumped 130 scattered chat histories into a CLI — and validated the hypothesis in a single day
Second Brain Series — EP2: The Experiment
When I decided I needed to build a second brain, I didn’t jump straight into writing code.
Building an app takes time. Plan it, design it, code it — and if after all that you realize “hm, this isn’t what I had in mind,” you’ve just burned a few weeks. I’d been there before. So this time, I decided to verify first. The cheapest way possible: does this actually work?
Why CLI — “What Should I Burn Tokens On?”
There’s a proposal from Andrej Karpathy that came up in my searches. Back in April 2026, he suggested building a wiki where an LLM directly manages a markdown folder. Raw source goes into a raw/ folder; the wiki/ folder is owned by the LLM. The only control layer is a schema file like CLAUDE.md.
Reading it, I thought: isn’t this exactly what I’ve been looking for? The question was which tool to use.
Web-based Claude has context limits. Long conversations or too many attachments get cut off. Dumping hundreds of chat histories and saying “read all of this and organize it” simply doesn’t work. But the CLI (Claude Code) was different. With a Max plan subscription, tokens were effectively unlimited.
“What should I even burn tokens on?” I figured I’d just pour everything in. Summaries would go into my Obsidian vault — I was already using Obsidian, and storing things as markdown there meant I could visualize the graph later.
I Dumped the Entire Chat History
I exported everything I’d accumulated. Claude app export, ChatGPT app export, manual copying — the methods varied, but I got it all into text, organized it by category, and dropped it into raw/notes/SH_채팅이력_추출/. 130 conversations. 8 categories.
Then I opened the CLI and said: “Hey wiki ~”
That was the first session. June 3, 2026.
“Where should the chat history go?” I asked, and the wiki laid out the sorting principles: project-related stuff goes into project folders, everything else somewhere separate. That was enough — I put it in. “Done. Digest this.”
With that one line, I’d just thrown 130 conversations at it.
The Moment It All Clicked
The wiki started reading. It mapped out a triage plan by category, turned the high-signal conversations into pages, and grafted them onto the existing wiki structure. It ran for over an hour.
And then something started connecting.
The decision I’d gotten stuck on with trading_mvp over KIS brokerage terms. The judgment calls I’d made while designing Hansaiam Art Museum. The tradeoffs I’d worked through when choosing a deployment setup. These had all been separate conversations in separate windows — but gathered into one place, the connections between them became visible.
At the end of the session, I wrote this: “Made this literally today but it’s already great~ feels like all those things that were scattered around are getting processed in one shot.”
That was the validation. The confidence that this was the right direction came from there.
What the Real Value Was
Near the end of that session, I realized something more important.
“AI already knows all the general stuff really well — but my specific experiences and what I’ve been through, that’s only mine to know. Having this organize that for me, it’s genuinely great… no matter what AI comes along, this is right now, you know?”
That became the north star for this wiki.
Transaction isolation levels or Docker networking setups — search any of those, and you get an instant answer. Ask any AI and you’ll get the same response. That kind of knowledge is commodity.
But “I built out the entire stock app before realizing the KIS brokerage terms blocked me” — that’s my mess-up. “Hansaiam needed to build trust before selling” — that’s my conclusion. “I spent two days stuck on 443 not opening after setting up the home server” — that’s my process. None of it is on Google. Any AI could come along and still not know it, because it’s specifically mine.
That’s the real asset building up in this wiki. I understood that in the very first session.
Two Limitations
The session ended on a high note — but two limitations were already in view.
First, the CLI only works at a PC. When ideas come on the phone or you want to jot something down while moving around — it’s just not accessible. Right after the session, I tried connecting mobile Obsidian. “How do I sync the git vault?” That’s where I hit another wall. The mobile obsidian-git plugin didn’t work well with private repos.
Second, inputting the chat history was manual. Exporting conversations from the Claude app, moving the files to a folder, running them through the CLI for digestion — none of that was automatic. Every time, it took hands-on effort.
The hypothesis was validated. I knew this was the right direction. But for it to work as an everyday tool, those two entry points needed to open up.
That’s why the next part happened. Ideas needed to be capturable from the phone, and once captured, they needed to stack up automatically.
Before you build something, verify the cheapest way possible with what you already have.
I took a single CLI and dumped every chat history I had into it — and confirmed in a single day that “connecting my scattered context opens things up.” A hypothesis that would have taken weeks to test if I’d built the app first. Verify it works first. Build it well second.