The second brain build guide: prerequisites, skills, and the exact commands

In Part 1 I made the case for a plain-text second brain that an AI can actually read. Making the case is the easy part. This is the build guide: what to install, how the pieces fit, and the exact prompts to paste, so you can get from empty folder to working second brain in an afternoon.

Everything here is the setup I actually run. Read it as a recipe, or paste the prompts straight into Claude and let it build the pieces while you put the kettle on.

Prerequisites

You only need four things (and only one will cost you money):

• Obsidian (free). A local-first Markdown editor: a clean window onto your folder of .md files. Claude does not strictly need it, since the notes are just text, but it is how you (the human) browse, link, and review what is in the vault. obsidian.md
• Claude Code (paid, included with a Claude subscription). The agent that runs in your terminal with read and write access to that folder. This is the brain. I am on the Pro plan and it is generally enough, unless you plan to ingest very large amounts of binary data like PDFs or images. Any capable coding agent would work here. I happen to use Claude Code, and I love it.
• A GitHub account (free). Version history and backup. Your second brain is too valuable to live on one disk. github.com
• Git installed locally (free), so Obsidian can sync the vault to GitHub. Not sure how? Follow the official guide, or just ask Claude to install Git and the GitHub CLI for you. With the CLI in place, Claude can also check the repo’s status and explain any differences you see between devices, instead of leaving you to decode them.

No servers, no database, no subscriptions beyond the AI. That is the whole bill of materials.

Build the vault (one time)

Open Claude Code in an empty folder and tell it what you are building. A prompt like this lays the foundation:

I want to build an Obsidian second brain in this folder, organised with the PARA method. Please: (1) create four top-level folders: Projects, Areas, Resources, Archive; (2) create an empty VAULT_INDEX.md at the root that I will use as a one-line-per-note map; (3) initialise a Git repo, create a private GitHub repo, and set it as the remote so I can sync.

PARA is the whole hierarchy. Everything you ever save lands in one of these four folders:

Folder	Use for
Projects/	Active work with a clear outcome and deadline
Areas/	Ongoing responsibilities without a deadline
Resources/	Reference material you’ll want to find later
Archive/	Completed projects, past processes, anything no longer active

Resist the urge to nest deeper. Only add a subfolder once a topic has built up enough notes to genuinely earn its own home.

Turn on autosync: the Obsidian Git plugin

This plugin is the backbone of the whole setup, and the one piece I would call non-negotiable. Obsidian Git auto-commits and pushes your vault to GitHub on a schedule (mine runs every 30 minutes).

Why it matters: every edit, whether you made it in Obsidian or Claude made it from the terminal, gets committed and synced automatically. Open a fresh laptop, clone the repo, point Obsidian at it, and your entire second brain is back, identical, with full history. No manual saving, no “wait, did I back that up”. The vault is always one git clone away from being whole again.

Setting it up:

1. In Obsidian, go to Settings → Community plugins → Browse, search for Obsidian Git, then install and enable it.
2. It needs the Git repo you created above. If you skipped that, ask Claude to git init, create the private repo, and wire up the remote.
3. In the plugin’s settings, the only parameters that matter:
   • Vault backup interval (minutes): set to 30, or whatever cadence you like. This is what makes it auto-commit and push.
   • Pull updates on startup: enable it, so a device that has been offline grabs the latest version before you start editing.
   • Commit message: the default is fine; it timestamps each commit.

Set it once, then forget it exists. Which, for any piece of software, is about the highest praise I can give.

Teach Claude to write good notes

Out of the box Claude writes perfectly fine Markdown. To make it write Obsidian Markdown, with proper links and callouts, it needs one skill. Claude Code skills are bundled capabilities it loads on demand. The ones I lean on:

• obsidian-markdown — the one that earns its place immediately. Teaches Claude Obsidian’s flavour of Markdown: frontmatter properties, [[wikilinks]], callouts (> [!info]), embeds. Every note Claude writes goes through it.
• defuddle — strips a web page down to clean Markdown before importing. Use it instead of a raw fetch when you want to save an article into the vault, and skip the cookie banners and navigation cruft.
• obsidian-bases — builds database-style table and card views over your notes (.base files). Handy once the vault grows and you want filtered views.
• json-canvas — for visual maps and mind-maps (.canvas files), if you think spatially.

Install only obsidian-markdown to start; add the rest when you feel the need. They all live in the kepano/obsidian-skills repo, with install instructions.

How Claude Code commands work (30 seconds summary)

Claude Code lets you save reusable prompts as slash-commands. You (or Claude, if you ask) drop a Markdown file into a .claude/commands/ folder, and its contents become a command you trigger by name. Put a file called second-brain-load.md in there, type /second-brain-load, and Claude runs that file’s text as instructions. That is the entire mechanism: a command is just a saved prompt in a file. Name it whatever you will remember; the name means nothing to Claude.

There are two scopes:

• Project commands live in .claude/commands/ inside the vault folder. They exist only when you work in that vault.
• Global commands live in ~/.claude/commands/ and work everywhere.

If you work on a single machine, I suggest global commands, so you can call them from any Claude Code session no matter where you launched it. Handy when you want a fresh session to go grab a note from your vault, which you will do more than you expect. The catch: global commands do not sync to GitHub with the vault.

The two commands that do all the work

Part 1 introduced the two commands that carry the whole workflow:

• /second-brain-load orients Claude to the vault. It tells Claude where your knowledge lives and how it is structured, so when you mention anything in the vault it goes straight to the right note instead of guessing.
• /second-brain-import files new content into the vault.

You have three ways to set each one up. Pick whichever suits you; all three work.

1. Have Claude build it from a spec. Paste the generation prompt below and Claude writes a command tailored to your vault.
2. Use mine as a starting point. Copy the file below into .claude/commands/, adjust the paths, done.
3. Hybrid. Paste mine into Claude and ask it to adapt it to your setup.

Command 1: /second-brain-load

What it does: reads the vault index, confirms what is in the vault, and tells Claude it is ready. Run it at the start of any session where you want to draw on your own knowledge, so you stop repeating yourself. Thirty seconds, and the assistant knows the shape of everything you know.

The idea it encodes: the index is a pointer, never the content. Claude reads the one-line-per-note index to decide which notes are relevant, then opens only those. Cheap and accurate.

Generate your own. Paste this into Claude:

Create a Claude Code slash-command file at .claude/commands/second-brain-load.md. Its job: load my Obsidian second brain into context. It should (1) read VAULT_INDEX.md at the vault root to get a map of every note grouped by PARA folder, (2) reply with a one-line summary of the vault (folders and rough note count) and confirm it is ready, and (3) follow the rule that the index is a pointer only, so it always opens the actual note with the Read tool before answering, never answering from index descriptions alone. Keep it concise.

Or use mine. Save this as .claude/commands/second-brain-load.md (swap in your vault path):

You are loading my Obsidian second brain vault into context so you can
answer questions about its contents, navigate notes, and help me find or
connect information.

## Step 1 — Load the vault index
Read `VAULT_INDEX.md` to get a full map of every note currently in the
vault, organised by PARA folder.
Absolute path: `/path/to/your/Vault/VAULT_INDEX.md`

## Step 2 — Confirm and summarise
After reading, respond with:
- A one-line summary of what's in the vault (top-level folders + note count)
- That you're ready to answer questions, navigate to any note, or find
  connections across notes
- The list of available commands (/second-brain-load, /second-brain-import)

## How to navigate from here
- Use the index to identify which note(s) are relevant
- Read those notes directly with the Read tool before answering
- If the answer spans multiple notes, read all relevant ones first
- Always prefer reading the actual note over answering from index
  descriptions alone. The index is a pointer, not the full content.

## Key vault facts
- Vault path: `/path/to/your/Vault/`
- Write method: Write tool directly to the vault path
- Binary files: copy via `cp` in the terminal

Command 2: /second-brain-import

What it does: the workhorse. Hand it a transcript, an article, a voice-note dump, or a meeting summary, and it decides which PARA folder the content belongs in, distils it to the depth you choose, writes a clean note with consistent frontmatter, and updates the index so the note is findable next time.

The one discipline that keeps the system from rotting: always update the index on write.

A few patterns worth keeping, all encoded in my version:

• Import modes. Not everything you import matters equally, so for each source I have Claude ask two questions: copy as-is, or distil? And if distil, at what level (light, medium, or aggressive)?
• Patterns and insights, always on. Whatever the mode, I ask Claude to scan for cross-cutting themes worth their own note, and to check with me before skipping anything that looks meaningful.
• Consistent frontmatter. A fixed set of fields (tags, status, source) on every note. Consistency is what Claude relies on.

Generate your own. Paste this into Claude:

Create a Claude Code slash-command file at .claude/commands/second-brain-import.md. Its job: import new content into my Obsidian second brain. It should: (1) read VAULT_INDEX.md first to understand existing content and linking opportunities; (2) read all source files before writing; (3) ask me, for each source, whether to copy it as-is or distil it, and if distil, at what level (light / medium / aggressive); (4) place each note in the right PARA folder (Projects / Areas / Resources / Archive) using clear decision rules; (5) write notes with the Write tool using consistent YAML frontmatter (tags, status, source) and Obsidian wikilinks, applying the obsidian-markdown skill; (6) always scan for cross-cutting patterns worth a standalone note, and ask before skipping anything meaningful; (7) update VAULT_INDEX.md with every new note; (8) keep binary files out of the vault, storing them externally and linking instead. Make it a clear step-by-step process.

I have not pasted my full import command, because it is longer and ends up different for everyone (it carries my own PARA rules, distil levels, and tagging conventions). Start from the generation prompt above and tailor it. If you want to be more prescriptive, the four tips below are the parts of mine most worth stealing.

Tip 1: spell out your decision rules

Be explicit about how Claude should file things. From my second-brain-import.md:

Decision rules I ask Claude to follow in my vault:
- If the content is about something **you're currently responsible for** → `Areas/`
- If it's **reusable reference material** → `Resources/`
- If it's about a **completed process or project** → `Archive/`
- If it's **in progress with a defined end goal** → `Projects/`

Tip 2: define the import modes

Spell out what each distil level means, so Claude stays consistent across imports. From my second-brain-import.md:

Before starting any import, always ask which mode I want for **each source or section**:

### Option 1 — Copy as-is
Migrate the content faithfully into the vault with clean filenames, frontmatter, and wikilinks. Preserve the original structure and detail level. Use for content where the detail itself is valuable (e.g., reference docs, templates, structured notes).

### Option 2 — Distil
Read the raw content and produce a condensed version. I choose the level:

| Level | What it means |
| --- | --- |
| **2a. Light** | Preserve most content; trim obvious filler (greetings, repeated context, formatting noise); restructure for readability; keep all specific facts, figures, and decisions |
| **2b. Medium** | Keep the key points, decisions, and learnings; drop supporting detail that can be inferred; aim for ~30-50% of original length |
| **2c. Aggressive** | Extract only the core insights, lessons learned, and actionable conclusions; strip everything else; aim for ~10-20% of original length |

Tip 3: keep large binary files out of the vault

As a rule, do not store large binary files (images, PDFs, slide decks) in the vault. They burn tokens every time Claude reads them, they bloat your backup, and GitHub is the wrong home for them. The flow I use:

1. Use the import command to extract the knowledge from those files. Claude produces a curated set of text notes (.md) that are cheap to retrieve later.
2. If you need the original, store it on a separate service (Google Drive, Dropbox, or similar). If Claude has a connector for that service, enable it, so Claude can reference the file and drop the link straight into the note. Then you, or Claude, can pull the original back whenever the text note is not enough.

The result is a vault that stays lean no matter how much you feed it, because what grows is the knowledge, not the file size.

Tip 4: write out the process, then tune it

My command ends with the exact process Claude follows on every import. Include something like this, then adjust to taste. It matters more than any other part once you are importing in volume:

## Your process

1. **Read `VAULT_INDEX.md`** first to understand existing content and linking opportunities
2. **Read all source files** before writing anything
3. **Ask** (before any planning):
   - For each source or section: **Option 1 (copy as-is)** or **Option 2 (distil)**, and if 2 — which level (light / medium / aggressive)?
   - If the structure is ambiguous: thematic or chronological output?
   - If anything seems potentially meaningful but uncertain: ask explicitly rather than deciding alone
4. **Plan** — present the full target structure, source-to-destination mapping, and any proposed pattern/insight notes for approval
5. **Write notes** using the `Write` tool directly to the vault, applying the `obsidian-markdown` skill for all note formatting
6. **Update `VAULT_INDEX.md`** with all new notes added
7. **Commit and push** the changes to GitHub
8. **Verify** by listing all created files at the end

That’s the whole system

A folder of plain-text notes, two commands, and Git quietly backing it all up. Nothing exotic, and that is the point. The only step left is the one that actually matters: start feeding it. Run the import command on a few real sources, watch where things land, tweak the prompts when something feels off.

The vault looks unremarkable on day one. But it pays off fast: within a couple of weeks you ask Claude about something you half-remember deciding, and it answers from your own notes instead of guessing. That is the moment it stops being a folder and starts being a second brain. And it only compounds from there.

---

*Part of a series on building with AI around a full-time job. Start with the overview