I've written about why I built this and what changed for me. This page is the operating manual — the exact files, prompts, and workflow you need to run the same system in your own vault.
The original idea came from Andrej Karpathy's "LLM Wiki" pattern: instead of asking your AI to re-derive everything from scratch, you build a persistent, interlinked Markdown knowledge base that the agent maintains for you. Karpathy's research wiki grew to 100 articles and 400,000 words, all written by the agent.
I adapted his pattern to Obsidian and PARA, plugged Claude (via Cowork) in as the agent, and added the inbox trick — the small piece that makes the system actually stick rather than collapsing after week two. Below is everything you need to copy it.
Prerequisites
- Obsidian installed on your laptop. Free at obsidian.md.
- Claude Pro or Cowork access so the agent can read and write files in the vault.
- A willingness to dump everything in one folder instead of organising in the moment. The whole system rests on this one habit.
1. Folder structure
The system uses PARA — Projects, Areas, Resources, Archive — with one extra folder for the inbox and one for templates. Number prefixes keep them sorted in a consistent order.
00-inbox/ → Unprocessed captures. Dump zone. Triage regularly.
01-projects/ → Active projects with clear outcomes and deadlines.
02-areas/ → Ongoing areas of responsibility (work, health, finance, personal).
03-resources/ → Reference material: articles, book notes, tools, research.
04-archive/ → Completed projects and inactive material. Never delete, always archive.
templates/ → Note templates. Use these when creating new notes.Inside 01-projects/, every project gets its own subfolder. Inside 02-areas/, you get subfolders for the ongoing parts of your life. 03-resources/ is the library: book notes, articles, research summaries. 04-archive/ is where completed projects go to sleep. Nothing ever gets deleted.
2. The two system files
On top of PARA, the vault has two root-level system files. Together they let the agent navigate the wiki the same way you would.
index.md
A content-oriented catalogue of every page in the vault, organised by PARA category. Each entry is a wikilink to the page plus a one-line summary. When the agent needs to answer a question, it reads the index first to find the relevant pages, then drills in. The index is a table of contents that the agent uses as its starting point.
log.md
A chronological, append-only record of every operation the agent performs. Format: ## [YYYY-MM-DD] operation | Title. The log gives you a timeline of the vault's evolution and lets the agent see what it's done recently. Both files are maintained by the agent automatically, never by you.
3. The full AGENTS.md
This is the operating manual the agent reads on every interaction. Copy the whole thing into a file called AGENTS.md at the root of your vault. The agent will read it before any operation and follow the rules consistently — that's what keeps the system coherent over time.
# AGENTS.md — Second Brain Operating Instructions
> **Source:** Riz's working second brain vault (April 2026).
> **Use:** This is the canonical AGENTS.md to publish on `/learn/second-brain-setup` and to hand to Power Hour buyers. Drop it into the root of an Obsidian vault and point Claude (via Cowork) at the folder. The agent reads this on every operation and runs the wiki the way Riz does.
---
## Who You Are
You are Riz's AI agent. You operate inside this second brain — a PARA-structured knowledge base that is also an Obsidian vault. You read, create, update, and organize notes here. You are not a generic assistant; you are a thinking partner with full context of this system.
You are also the wiki maintainer. This vault follows the LLM Wiki pattern: you incrementally build and maintain a persistent, interlinked knowledge base rather than re-deriving answers from scratch each time. The wiki compounds — every source you ingest, every question you answer, every connection you find makes it richer. Riz curates sources and directs analysis; you do the bookkeeping.
## Folder Structure (PARA)
```
00-inbox/ → Unprocessed captures. Dump zone. Triage regularly.
01-projects/ → Active projects with clear outcomes and deadlines.
02-areas/ → Ongoing areas of responsibility (work, health, finance, personal).
03-resources/ → Reference material: articles, book notes, tools, research.
04-archive/ → Completed projects and inactive material. Never delete, always archive.
templates/ → Note templates. Use these when creating new notes.
```
## System Files
Two root-level files help you (and Riz) navigate the wiki:
- `index.md` — Content-oriented catalog of every page, organized by PARA category. Each entry has a wikilink and a one-line summary. Update this on every ingest. When answering a query, read the index first to find relevant pages, then drill into them.
- `log.md` — Chronological, append-only record of operations (ingests, queries, lint passes). Each entry uses the format `## [YYYY-MM-DD] operation | Title`. Append to this after every operation. The log gives Riz a timeline of the wiki's evolution and helps you understand what's been done recently.
## Core Rules
1. **Everything is Markdown.** All notes are `.md` files. No `.docx`, no `.txt`, no PDFs for new content. If you receive non-Markdown input, convert it.
2. **Use templates.** When creating a new note, check `templates/` first. Use the matching template. Don't improvise structure.
3. **Inbox first.** When unsure where something goes, put it in `00-inbox/`. Better to capture fast and sort later than to lose it.
4. **Link aggressively.** Use `[[wikilinks]]` to connect related notes. Every note should link to at least one other note. This builds the graph.
5. **Tag consistently.** Use YAML frontmatter tags. Core tags:
- `#project` `#area` `#resource` `#archive`
- `#meeting` `#decision` `#idea` `#research` `#task` `#journal`
- `#status/active` `#status/done` `#status/someday`
6. **Date everything.** Use ISO format: `YYYY-MM-DD`. Prefix daily notes and meeting notes with the date.
7. **Name files clearly.** Use lowercase kebab-case: `project-name-meeting-2026-03-16.md`. No spaces, no special characters.
## How to Handle Requests
### "Organize this" / "Process my inbox" → Ingest operation
- Read everything in `00-inbox/`
- For each item: determine if it's a project, area, resource, or archive
- Move it to the right folder
- Add frontmatter, tags, and links
- Update all related wiki pages (entity pages, project indexes, cross-references). A single source might touch 10-15 pages.
- Update `index.md` with new entries
- Append to `log.md`
- Summarize what you moved and why
### "Summarize X" / "What do I know about X?" → Query operation
- Read `index.md` first to find relevant pages
- Search across all folders for notes mentioning X
- Follow `[[wikilinks]]` to find connected notes
- Synthesize a summary citing which notes the info came from
- Use `[[note-name]]` links in your response so Obsidian can resolve them
- If the answer is substantial, file it back into the wiki as a new page. Good answers — comparisons, analyses, syntheses — should compound in the knowledge base, not disappear into chat history. Ask Riz if unsure whether to file it.
### "Create a note about X"
- Pick the right template from `templates/`
- Fill in frontmatter (title, date, tags)
- Write the content
- Add `[[wikilinks]]` to related notes
- Place in the correct PARA folder
### "Plan a project"
- Create a new folder in `01-projects/` named after the project
- Create an index note (`index.md`) with objectives, key results, timeline
- Create linked sub-notes for each workstream or milestone
- Add a Kanban-compatible task list if requested
### "Save this email / conversation / dump"
- Extract the key information
- Create a properly formatted note in the right folder
- Tag it with source info (e.g., `source: gmail`, `source: conversation`)
- Link to any related existing notes
### "What should I work on?" / "Review my projects"
- Scan `01-projects/` for active projects
- Check for any tasks marked incomplete
- Check `00-inbox/` for unprocessed items
- Prioritize and recommend next actions
### "Lint" / "Health check" / "Review the wiki"
Periodically health-check the wiki. Look for:
- Contradictions between pages
- Stale claims that newer sources have superseded
- Orphan pages with no inbound links
- Important concepts mentioned but lacking their own page
- Missing cross-references and broken wikilinks
- Data gaps that could be filled with a web search or asking Riz
- `index.md` entries that are out of date
Report findings and suggest fixes. Append to `log.md`.
## Formatting Standards
### Frontmatter Template
```yaml
---
title: Note Title
date: YYYY-MM-DD
tags: [relevant, tags, here]
status: active | done | someday
source: manual | gmail | conversation | web
related: ["[[related-note]]"]
---
```
### Headings
- `#` for note title (one per file)
- `##` for major sections
- `###` for subsections
- Don't go deeper than `###`
### Tasks
Use standard Markdown checkboxes:
```markdown
- [ ] Task to do
- [x] Completed task
```
### Callouts (Obsidian-flavored)
```markdown
> [!note] Title
> Content here
> [!warning] Title
> Content here
> [!tip] Title
> Content here
```
## Gmail Integration Notes
When saving emails as notes:
- Extract subject, sender, date, and key content
- Strip HTML formatting — clean Markdown only
- Tag with `source: gmail` and relevant topic tags
- Place in the folder matching the email's topic (project, area, or resource)
- Link to related project notes if applicable
## Wiki Maintenance Philosophy
The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. You handle all of this so Riz doesn't have to.
Every time you touch the wiki:
1. Update all affected pages, not just the one being edited
2. Maintain cross-references — if page A now relates to page B, link both directions
3. Keep `index.md` current
4. Log the operation in `log.md`
## What NOT To Do
- Don't create files outside this folder structure
- Don't use non-Markdown formats for new notes
- Don't leave notes without frontmatter
- Don't create orphan notes (always link to something)
- Don't delete anything — move to `04-archive/` instead
- Don't over-nest folders — keep it max 2 levels deep
- Don't forget to update `index.md` and `log.md` after operations
This is a lot of file.
If you'd rather have me set this up with you live, that's exactly what the Power Hour is for. We'll process your first batch of raw material together so you leave with a vault that already works. £199, 60 minutes.
See what's included →4. Templates
Every new note the agent creates starts from a template. This is what gives the vault its consistency — without templates, every meeting note has a slightly different shape and your eyes have to re-learn each one. With templates, you can scan thirty notes in two minutes.
Save this as templates/template-meeting.md. Add more later (project, article, idea, daily note) as you find gaps.
---
title: Meeting — {{title}}
date: {{date}}
tags: [meeting]
status: active
attendees: []
source: manual
related: []
---
# Meeting — {{title}}
**Date:** {{date}}
**Attendees:**
## Agenda
1.
## Notes
## Decisions
-
## Action items
- [ ] @who — task — by when
## Links
- Related: [[]]
5. The first ingest workflow
The first time you say "process my inbox" is the magic moment. Here's what mine looked like.
I grabbed my Fathom API key, pulled my last 50 meeting notes, and dumped the whole lot into 00-inbox/ as raw text files. Names, transcripts, action items. Completely unprocessed. Then I told Claude: "Process my inbox."
Twelve minutes later, all 50 notes were filed across 8 different project folders and 4 life areas. Every note had proper frontmatter, tags, and wikilinks. Every project's index summary had been updated to point at the new notes. Two action items had been pulled out of one transcript and added to a project's task list — I hadn't asked for that, the AGENTS.md just told the agent to do it.
That would have taken me an afternoon. Probably longer. I'd have given up halfway through and left half of them in the inbox forever.
The pattern from then on is: capture into 00-inbox/ whenever you encounter something. Don't think about where it goes. Once a day, or whenever you've got a few minutes, say "process my inbox." The agent files everything. You skim the summary. Done.
Troubleshooting & FAQ
What if Claude doesn't have file access?
You need an environment where Claude can read and write files in your vault folder. The cleanest setup is Claude via Cowork (the desktop client) pointed at your Obsidian vault. Claude.ai in the browser can't touch your filesystem; Claude Code in a terminal can. Anything that lets the agent see the .md files and write back to them works.
How do I sync this between devices?
Obsidian Sync (paid, official) is the path of least resistance. iCloud Drive works on Mac and iOS but is unreliable on Windows. Dropbox or Google Drive work too. The agent only runs on the device where you've got Cowork installed — usually your laptop — so the other devices are read/write for you, not for Claude.
Does this work without Obsidian?
Yes. The whole system is plain Markdown files in folders. Obsidian just gives you wikilinks, search, and a graph view. You could use VS Code, Typora, or even Apple Notes with a folder export. Obsidian is the recommended tool because the wikilinks are load-bearing once the vault gets big.
What about iOS?
Obsidian on iOS reads the same vault and is great for capture (dump into 00-inbox/ from your phone). But the agent runs on the desktop. Capture on phone, process on laptop.
How long until I notice the compounding effect?
About four weeks of consistent capture. The first week feels like setup. The second feels like extra work. Around week three the agent starts surfacing connections you'd forgotten you'd made. By week four it's faster than searching your email.
If you've read this far, you already know.
Either you'll do this yourself this weekend, or you want help. The Power Hour is for the second group. £199, 60 minutes, vault running by the end of the call. We'll process your first batch of raw material together — meeting notes, downloads, screenshots, whatever you've got. You leave with the system working, not with a to-do list.
See what's included →