I've been building software since before I was 8 years old. I've had a BBC Micro, an Atari ST, a Leisure Center booking app I wrote from scratch for my A-levels, and an Inventories Database I built on my year 12 placement that was somehow running in a health authority. I've written a book about responsive images, Family-friendly Storytelling platforms. I've shipped more tools than I can remember.
And for most of that time, my second brain was a whiteboard.
Not metaphorically. An actual whiteboard. In my office. With things on it.
It worked, in the way that a whiteboard always works — always visible, zero friction, spatially organised. The problem is that it doesn't travel. It doesn't sync to my phone. It gets wiped by accident. And it has absolutely no memory of why I made the decisions written on it.
So in early 2026, I decided to build a proper second brain. Not buy one — build one. This is what happened.
The starting point: a graveyard and a migration
The first problem wasn't choosing a tool. The first problem was that a decade of thinking was scattered across Apple Notes, Evernote, various notebooks, P60s I'd photographed on my phone, and a Moleskine I wrote in on a plane in 2019 that contains a visual map of my entire life.
None of it was connected. Most of it was unsearchable. Some of it — the Evernote archive in particular — was genuinely at risk of being lost.
So step one was archaeology.
I migrated everything to Obsidian — a local, Markdown-based notes app that stores everything as plain text files on your own machine. No subscription lock-in, no proprietary format, no company that might go under and take your notes with it. Just files. The Evernote export alone was about 600 notes. Apple Notes was another few hundred. Old photographs of handwritten diaries. Scanned notebooks. The works.
The migration itself was mechanical — export, convert, import. The harder part was making any of it useful. That's where Claude came in.
The MCP server: Claude talks to the file system
Here's the thing about AI tools and personal knowledge management: most of them want your data to live on their servers. That wasn't going to work for me. I wanted Claude's intelligence operating on my files, stored locally, without anything leaving my machine in a direction I hadn't approved.
Model Context Protocol (MCP) made this possible. It's a protocol that lets Claude connect to local servers — including a filesystem server that can read and write files directly in your Obsidian vault. You configure it once, point it at your vault directory, and Claude can open your notes, read them, write to them, create new ones, and edit existing ones — without anything going through a cloud intermediary you don't control.
The config is a small JSON file:
{
"mcpServers": {
"obsidian-vault": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/path/to/your/vault"
]
}
}
}Once that's in place, Claude becomes the triage layer. You stop worrying about where to put things. You tell Claude what you need to capture — a decision, a task, a thought that arrived on a walk — and Claude routes it to the right file. The cognitive overhead of filing disappears.
This matters more than it sounds. The reason most personal knowledge management systems fail isn't the tool. It's the friction of deciding where something goes. Remove that decision, remove the friction.
The trigger system: Firehose and friends
The system I use most heavily is something I call Firehose. It's a weekly industry briefing — AI, developer tools, Vercel ecosystem news — that Claude assembles from multiple API sources: the Guardian API, the Perplexity Sonar API, and X/Twitter's API for signals from specific accounts I follow.
The trigger is simple: I type the word Firehose in Claude. That's it. Claude reads a file called _firehose.md in my vault that contains the full instructions — which APIs to call, which accounts to check, what format the output should take, where to write the files. No separate service. No cron job. No hosted infrastructure. Just a text file and a trigger word.
The output is three files written directly into my vault: an X feed file with raw signals, a full weekly briefing, and a Phase 4 summary — a personal version that contextualises the week's news against my own projects and priorities.
The key insight: the instruction file is itself a note in the vault. You can open it in Obsidian, edit it, improve it, change what it does. The system is transparent. It's yours. There's no black box.
The inbox: two ways in, one way out
I've stopped trying to find a single perfect capture method. There are two valid modes, and I use both.
Mode one: tell Claude directly. Mid-conversation, mid-work session — "make a note that we chose Cloudflare Workers over Vercel Edge for this project because of cost at scale" — and Claude writes a dated entry into the Decision Log for that project. Done. No context switch. No filing.
Mode two: type directly into Obsidian. On my phone, in a meeting, on a walk. There's a file called Inbox.md that I treat as a dump. No structure required. No format. Just text. When I next talk to Claude — or when the Firehose run kicks off — Claude reads the inbox, triages everything, routes it to the right place, and clears it.
The routing logic:
- A decision with reasoning → Decision Log in the relevant project file
- A system-level decision → OS-decisions.md
- A time-sensitive task → top of the Home dashboard
- A throwaway task → actioned and discarded, no permanent record
- Anything unroutable → flagged, left for me to handle
The phrase I use to kick this off: "triage my inbox." Three words. No explanation needed.
The OS decisions log: the layer below everything
This one came out of a conversation about why systems fail over time. They fail because the reasoning behind them gets lost. You end up with a structure you don't understand, conventions you can't explain, and a creeping sense that you should probably rebuild the whole thing — except you don't know what to keep.
So I created _system/OS-decisions.md. Every decision about the system itself gets a dated entry:
### 2026-03-07 — YYYY-MM-DD file naming
Decision: All files use YYYY-MM-DD meaningful name format — no week numbers
Why: Week numbers are opaque when scanning. Dates + names are self-explanatory and sort correctly
Alternatives considered: W-number format (used briefly), plain titles without datesFuture me — and future Claude in a new session with no memory of how any of this was built — can open that file and understand exactly why the vault is the way it is. Every choice is auditable. The system has a memory.
The dashboard: kill the queries, write the file
My first attempt at a dashboard used Obsidian's Dataview plugin — a query language that can pull tasks, links, and metadata from across your vault. It's powerful. It also mostly returned nothing, because my tasks are undated and freeform and don't use the conventions Dataview expects.
The fix was to stop fighting the tool and change the approach entirely.
The dashboard is now a file called 00-Now/Home.md. Claude writes it. I edit it. There are no queries. Three sections:
⏰ Time-sensitive — things with a real deadline this week, across all areas of life. Work, family, house, financial, travel — all in one place.
🎯 Active projects — one line per active project, showing exactly where I left off and the single next action. Not a task list. Not a Kanban board. Just the one thing I need to do next to keep each project moving.
🧪 Try / 📖 Read — each week's Firehose run updates these sections with three things to actually try and three things worth focused reading, based on what surfaced in the industry that week.
Claude updates this file during each Firehose run. I update it by telling Claude what's changed. Nobody has to manually maintain a dashboard. The system does it.
The Superwhisper problem: leading spaces and the Linter fix
Small things matter. This one cost me twenty minutes but is worth mentioning because I suspect I'm not the only one who'll hit it.
I'm moving towards voice capture as a primary input mode. Superwhisper is excellent — far better transcription than iOS native dictation, and with a Shortcuts integration you can route transcribed text directly into your Obsidian inbox. One tap, speak, done.
Except: Superwhisper was adding a leading space before each transcription. One space. Invisible. Completely harmless in isolation — but if you're appending multiple voice captures to the same file, Obsidian's Markdown renderer treats leading spaces as code blocks. Your inbox starts looking like a terminal. Each new entry indented one level deeper than the last. It's subtle and it's maddening.
The fix: Obsidian Linter plugin, with Remove Leading Whitespace turned on. Linter runs on save and strips the leading space before Obsidian processes the Markdown. Problem gone.
It's a small thing. But the small things are the ones that make you give up on a system.
What the system actually does
Let me be concrete about what this looks like in practice.
On Monday morning I sit down and type Firehose. Claude spends a few minutes fetching signals from the APIs — X accounts I follow, Guardian articles matching industry topics, Perplexity queries for things web search doesn't surface well. It writes a full briefing into my vault, updates the dashboard with the week's Try and Read list, and checks my inbox for anything I dropped in over the weekend.
During the week, I capture in two modes. At a Mac, I tell Claude directly. On my phone, I open Obsidian mobile and dump into Inbox.md. Neither requires a decision about where to file it.
When I context-switch — from Vercel work to a side project — I open 00-Now/Home.md and see exactly where I left off. One line per project. The next action, not a long list. If I made an architecture decision last week, it's in the project's Decision Log with a date and a reason.
When a new Claude session starts with no memory of any of this, it reads _system/OS-decisions.md and is immediately up to speed on why the system is the way it is. The context isn't in my head. It's in the vault.
What's still unfinished
The X/Twitter API sometimes returns old posts rather than recent ones for certain accounts — a known issue with the free tier that needs investigating.
The voice-to-Obsidian Shortcuts integration works but hasn't become habitual yet. Superwhisper on Mac is excellent; the phone workflow is still a bit more friction than I'd like.
And the decision logs in most of my project files are empty. The structure is there. The habit of filling them in is not yet. That's the next six weeks of work.
The thing underneath all of this
I've tried a lot of productivity systems. Most of them have one failure mode in common: they optimise for capture but not for retrieval. You end up with a very thorough record of everything you've ever thought, and no way to find the thing you're looking for when you need it.
What I wanted was something different. Not a better filing system. A better thinking system. A place where the context from last week is available this week, where decisions don't evaporate when the conversation ends, where the reasoning behind choices is preserved not for posterity but for usefulness.
The whiteboard worked because it was always visible. It failed because it had no memory.
This system is trying to be both. Always visible — the dashboard, one file, always open. And persistent — the decision logs, the OS notes, the dated entries that accumulate into something you can audit.
Claude is the triage layer. Obsidian is the filing cabinet. I'm still the one who decides what matters.
That's probably how it should work.