Build Your Own Second Brain

Two weeks ago I wrote about the note-taking system that files itself: Obsidian holding plain Markdown files, and Claude Code reading and writing them according to instructions I wrote down once.

I’ve gotten a lot of questions and feedback since, and nearly all of it came back to the same one. Okay, how do I build one?

This is that guide. Budget about two hours for the initial build, then two weeks of light tuning.

One thing to get straight before you start, because it decides whether this works for you or becomes another abandoned productivity project.

Do not copy my vault. I’m a Salesforce solutions architect. I track client engagements, architecture decisions, and certification progress because those are the things that decide whether I get promoted. If you’re a product manager, an academic, a founder, or a staff engineer, your vault should look meaningfully different: different note types, different frontmatter fields, different weekly questions.

What I’m giving you is the method. How to design a schema, how to teach an agent to write into it, and how to build the read path that makes it worth having. The specific fields are illustrative. Change them. The system only works if it’s tracking the things you actually care about, and I don’t know what those are.

What you’re building

Four moving parts:

An Obsidian vault: a folder of Markdown files with structured frontmatter
A schema: the note types and fields that make the vault queryable
Claude Code skills: instructions that teach an agent to write correctly into that schema
A read path: dashboards and a review routine that turn the pile into insight

The order matters. Most people start at step 3 because it’s the fun part, then discover their AI is writing beautifully worded notes into a structure that can’t answer any question. Start with the schema.

Step 1: Obsidian and the vault

Download Obsidian from obsidian.md. It’s free for personal use, and there’s no account to create.

On first launch, choose Create new vault. Name it something you’ll want to open. Put it somewhere backed up: iCloud Drive, Dropbox, or a folder you’ve initialized as a git repo. I’d genuinely recommend git. This is going to become the most valuable folder on your machine, and an agent will be writing to it.

A vault is just a directory. Nothing proprietary is happening. Open it in Finder and you’ll see plain .md files, which is exactly the point. That property is what makes everything else possible.

Turn on the plugins you need

Settings, then Community plugins, then Turn on community plugins. Browse and install:

Dataview. Required. This is what turns frontmatter into live queries. Without it you have a folder of notes. With it you have a database.
Meta Bind. Optional but nice. Lets you put an interactive dropdown inside a note, so you can change an action item’s status by clicking rather than editing YAML.

In Dataview’s settings, enable JavaScript Queries if you want the more advanced views later. The basic TABLE syntax covers most of what you’ll need.

Step 2: Design your schema

This is the part that earns its time back tenfold. Sit with a blank page and answer three questions.

What am I going to want to look back on? Not what you think you should write down. What you’ll want to retrieve, six months out. For me: what I accomplished, why I made a given architecture call, and whether I’m actually moving on my goals. For a researcher it might be experiments run, papers read, and hypotheses discarded. For a founder: customer conversations, pivots, and metrics at a point in time.

What are the nouns in my work? These become your entity types. Mine are people, companies, projects, goals, credentials. Yours might include papers, experiments, customers, features, incidents, courses.

What’s the recurring unit of time? For nearly everyone this is a day, rolled up weekly and quarterly. Keep it.

Now sort your answers into three families. Every note type I have falls into one:

Family	Purpose	Mine
Temporal	What happened when	daily log, weekly review, quarterly review
Entity	Durable things you refer to repeatedly	person, company, project, goal, credential
Content	Discrete artifacts of thought	action item, decision, big win, reference note

Create a folder per note type. Flat and boring beats clever:

Second Brain/
├── Daily Logs/
│   └── Archive/
├── Action Items/
├── Decisions/
├── Goals/
├── People/
├── Projects/
├── Companies/
├── Big Wins/
├── Notes/
├── Reviews/
└── Dashboards/

The frontmatter contract

Every note gets YAML frontmatter, and the first field is always type. That single field is what lets you query across the whole vault later.

Here’s my daily log, the note type you’ll create most often:

---
type: daily-log
date: 2026-08-13
projects:
  - "[[Project Name]]"
goals:
  - "[[Goal Name]]"
people:
  - "[[Person Name]]"
action-items: []
big-wins: []
energy: High
---

Then free-form Markdown sections underneath: Accomplishments, Blockers, Notes.

And my action item, which shows the pattern that makes the whole thing hang together:

---
type: action-item
title: Short description
status: Open
due-date:
resolved-date:
project: "[[Project Name]]"
goal: "[[Goal Name]]"
people: []
daily-log: "[[2026-08-13]]"
description: "Context and detail"
tags: []
---

Four rules I’d hold you to regardless of which fields you choose.

Relationships are wikilinks, not folders. Write project: "[[Q3 Migration]]" rather than filing the note under a project folder. A note can relate to many things. It can only live in one folder. Obsidian’s backlink panel then gives you the reverse direction for free: open a project note and see every action item, log, and decision that referenced it, without maintaining a list.

Links go both ways. Notice that the action item carries daily-log: pointing back to the day it was born, and the daily log carries action-items: pointing forward. Slightly redundant. But it means either note is a complete entry point, and your agent can navigate from either direction.

Status fields are closed sets. Mine is exactly Open, In Progress, Done, Cancelled. Write the allowed values down. An open-ended status field becomes free prose within a month, and free prose can’t be queried.

Dates are ISO 8601. 2026-08-13. Always. Dataview sorts and filters on this, and every other format will eventually betray you.

Step 3: Write the tag taxonomy

Short section, disproportionate importance.

Create one note called Tag Taxonomy.md, and in it define a closed list of tags. Ten to fifteen, organized into two facets. Mine:

Domain, what the work is about: five options, specific to my practice areas
Activity, what kind of work it was: six options, being architecture, integration, discovery, thought-leadership, reusable-asset, and delivery

Rule: pick zero to two from each facet. Never invent a new one.

Also write down which note types carry tags at all. Mine: content notes only. People, companies, goals, and daily logs don’t get tags. They’re found by name, date, and link, not by topic.

Here’s why this matters more than it looks. A language model is an extraordinary tag generator. Ask it to tag a note and it will produce something reasonable, specific, and slightly different every time. Six weeks in, you’ll have data-migration, data_migration, migration, and etl all meaning the same thing, and your tag pane will be useless.

The taxonomy note isn’t for you. It’s for the agent, and it’s the difference between a filter that works and one that lies to you.

If you ever do need to change it, keep a table of retired tags mapped to canonical ones in the same note, and have the agent sweep the vault. Migrating a controlled vocabulary is a twenty-minute job. Migrating an uncontrolled one is a weekend.

Step 4: Install Claude Code and point it at the vault

Install it:

npm install -g @anthropic-ai/claude-code

Then run claude from your vault directory once to authenticate.

Where skills live

Claude Code looks for skills in two places:

~/.claude/skills/<skill-name>/SKILL.md, available everywhere
<project>/.claude/skills/<skill-name>/SKILL.md, only in that project

Put your second brain skills in the global location. This is a deliberate call, and it’s the one I’d most encourage you to copy. The whole value proposition is capturing work at the moment it happens, and that moment usually finds you deep inside a client repo or a data pipeline, not sitting in your notes folder. Global skills mean you can log the day from wherever you are.

Give the agent a map

Create ~/.claude/CLAUDE.md, which loads into every session, and tell it who you are and where the vault is:

# Who I am
[Your role, your domain, what you're working toward]

# Second Brain
My Obsidian vault is at `~/Documents/Second Brain/`.
Note types, folder structure, and the tag taxonomy are documented in
`Tag Taxonomy.md` at the vault root.

Keep this file short. It loads on every single session, so every line is a recurring cost. Detail belongs in the skills, which load only when they fire.

Step 5: Write your first skill

A skill is a Markdown file with two frontmatter fields and a body of instructions. The description is load-bearing. It’s how the agent decides whether to fire, so write it as a list of the phrases you’ll actually say, not an abstract summary.

Create ~/.claude/skills/dailylog/SKILL.md:

---
name: dailylog
description: "Capture a daily log entry into the Obsidian vault. Trigger on
any request to log the day, record what happened, or phrases like 'log today',
'daily log', 'end of day', 'here's what I did today', or when the user pastes
a brain dump of the day's work. Also trigger when the user shares a calendar
screenshot alongside a summary of what happened."
---

# Daily Log Skill

## Vault Path
`~/Documents/Second Brain/`

## Process

### Step 1. Determine the date
Use today's date (YYYY-MM-DD). If the user references another day
("yesterday"), derive it. Only confirm when genuinely ambiguous.

### Step 2. Collect input
Accept a freeform brain dump. If the user shares a calendar screenshot,
use visible meeting titles to infer projects and activities. Ask about
generic titles ("Sync", "Meeting") that can't be confidently matched.
Don't ask about anything clearly inferable. The point is to minimize friction.

### Step 3. Infer structured fields
Match against existing notes before creating anything.

- Projects: search `Projects/` recursively. Store as wikilinks.
  If a project is mentioned that doesn't exist, propose a stub.
- Goals: match against `Goals/` by content. Push for goal links.
  They're how daily work shows up on goal pages and the dashboard.
- People: search `People/` recursively. If someone new is mentioned,
  propose creating their record.
- Energy: infer from tone if not stated. One of High, Medium, Low.
- Accomplishments: everything completed or meaningfully progressed,
  including small wins.
- Blockers: what's stuck, at risk, or waiting on someone.
- Tomorrow's Focus: top 2 to 4 priorities. Specific verbs only.

### Step 4. Carry forward unresolved blockers
Read yesterday's log. Any blocker still unresolved carries forward with
its original date attached ("Carried forward from 8/12").

### Step 5. Close completed action items
The brain dump usually reports finishing things ("sent the deck",
"submitted the ticket"). This is how open items get closed. Otherwise
the Open list only grows.

1. Read open items: grep -rl "status: Open" "Action Items/"
   (also check `In Progress`).
2. Match against what the user just said.
3. Propose closures. On confirmation, set `status: Done` and
   `resolved-date` to today.

### Step 6. Propose new action items
Detect action-item language: "need to", "follow up on", "reach out to",
"I should", "waiting on". Propose records. The user confirms before
any are created.

### Step 7. Write the file
`Daily Logs/YYYY-MM-DD.md`, using the exact frontmatter schema below.
[paste your schema here]

## Rules
- Never create a duplicate entity. Always search first, always link
  to the existing note.
- Confirm before creating action items or new entity notes.
- Never invent tags. Use the controlled vocabulary in `Tag Taxonomy.md`.
- Dates are ISO 8601.

Adapt every step to your own work. But keep the three structural moves, match before creating, carry blockers forward, and close the loop, because those are what separate a system that compounds from one that just accumulates.

Let Claude write it

Worth stating plainly, because everything above reads like you should type that file out by hand. You shouldn’t. The agent that reads skills can also write them.

Paste the schema you designed in step 2 into Claude Code, describe what you want the skill to do, and let it write the SKILL.md. Anthropic publishes a skill-creator skill in the official plugin marketplace that does this properly, including tuning the description so the skill actually fires when you expect it to.

The update loop matters more than the first draft. When the skill gets something wrong, and it will, don’t go edit YAML by hand. Say what went wrong in the session where it happened. “You asked me three things you could have inferred.” “You created a second note for Sarah instead of linking the one that already exists.” Then have it revise its own SKILL.md while the failure is still in context. That’s how all four of mine got good, and it’s why the two weeks of tuning below is two weeks of remarks rather than two weeks of editing.

I still decide the rules. What counts as a win, what earns an action item, when the skill should push back and refuse to accept something. That part isn’t delegable, and it’s most of the value. Claude writes the rules down and fixes its own instructions when I tell it what it got wrong.

Then add a second one

Once the daily log works, write the skill for whatever your highest-value note type is. Mine is the ADR skill, because architecture decisions are my professional output. Yours might be an experiment log, a customer-conversation capture, an incident postmortem, a reading note.

The one design rule I’d insist on: make the required sections genuinely required. My ADR skill refuses to accept a decision with no rejected alternatives, because a decision without alternatives is just a default. It refuses to accept one with no consequences, because every real decision has trade-offs. When I skip them, the skill pushes back and asks. Those two prompts are where most of the value in that skill lives, and they would have been trivially easy to leave out.

Step 6: Add slash commands

Skills define capability. Slash commands define your routine. They live in ~/.claude/commands/<name>.md and are just a description plus a prompt.

Here’s ~/.claude/commands/eod.md:

---
description: End-of-day wrap-up. Capture today's log, then review open action items.
---

Run my end-of-day routine:

1. Invoke the `dailylog` skill to capture today's work, using this session's
   context as the brain dump. Ask me for anything you can't infer (energy
   level, tomorrow's focus) rather than guessing.
2. Once the log is written, pull up my Open and In Progress action items
   relevant to what we worked on today and walk me through them one by one
   so I can give quick status updates.

Note what step 1 does. If you’ve been working in Claude Code all day, the session itself is the brain dump. You don’t have to remember what you did. It was there. On days when I’ve been in the terminal, /eod is genuinely one keystroke plus a couple of confirmations.

I also have a /checkin for mid-day, which is additive: it reads the existing log and proposes only what’s new, rather than regenerating the entry. Worth building once you find yourself running /eod at 2pm because you’re about to context-switch.

Step 7: Build the read path

You now have capture. Capture alone is a diary. The read path is what makes it a system.

Create Dashboards/Daily Dashboard.md with Dataview queries:

---
type: dashboard
---

## Open Action Items

```dataview
TABLE status, due-date AS "Due", project AS "Project"
FROM "Action Items"
WHERE status != "Done" AND status != "Cancelled"
SORT due-date ASC
```

## Active Goals

```dataview
TABLE status, target-date AS "Target", progress AS "Progress %"
FROM "Goals"
WHERE status = "Active" OR status = "At Risk"
SORT target-date ASC
```

## Energy Trend

```dataview
TABLE date, energy, projects AS "Projects"
FROM "Daily Logs"
SORT date DESC
LIMIT 14
```

Nothing here is ever maintained by hand. The dashboard is a view over the data, and it’s correct the moment you write a log.

Then write the review skill

This is where the system stops being a filing cabinet and starts being useful. Create a review skill that reads a date range and reports back. Make it read-only. Mine never edits a note without explicit confirmation, and that constraint is why I trust it.

The reporting sections are yours to choose, but here are the four that consistently surprise me.

Neglected goals. Active goals that no in-range daily log links to. These are the ones quietly slipping while you feel busy. My most useful review finding ever came from this one: twenty-four consecutive logs with an empty goals: field, because everything had completed in June and nothing replaced it. I would have sworn I was making progress.

Overdue action items, with the number of days attached. “17 days overdue” reads very differently from “still open.”

Energy trend. List the energy values across the range and call out a downward run or a sustained Low in words. Don’t just print the data. Instruct the skill to name it as a burnout signal when it sees one. You will not notice this pattern yourself. That’s the nature of it.

Relationship atrophy. Give each person note a cadence field (weekly, monthly, quarterly) and a last-interaction date. The review flags anyone past due. This is the single highest-return field-to-effort ratio in my entire vault, and if you’re in any client-facing or leadership role I’d add it on day one.

Add a quarterly mode later. It’s the same machinery over a longer range, and it’s what turns performance-review season from a half-day of reconstruction into a query.

Step 8: Housekeeping

Two things that keep it fast.

Archive old daily logs. Move anything older than about a week into Daily Logs/Archive/. It stays fully searchable, but it keeps the agent from loading a hundred files when it only needs five. A ten-line shell script on a weekly cron handles it. Make sure your review skill knows to read both directories when a date range reaches back.

Watch your context budget. Every instruction in CLAUDE.md loads on every session. Keep it lean and push detail into skills, which load only when triggered. If a skill needs a big reference table, put it in a separate file and have the skill read it on demand rather than embedding it.

The first two weeks

Expect the first version to be wrong. Here’s how it usually goes.

Days 1 to 3: it over-asks. The skill confirms things it should infer, and logging feels like an interrogation. Fix it by adding explicit “don’t ask about X, infer it” instructions. Friction is the thing that kills these systems, and every unnecessary question is friction. Be aggressive about cutting them.

Days 4 to 7: duplicate entities. You’ll find two notes for the same person or project. Strengthen the match-before-create instruction, and be specific about how to search. Tell it which folders, and to search recursively.

Week 2: schema regret. You’ll want a field you didn’t think of. Add it. Old notes without it are fine, because Dataview treats a missing field as null and your queries still run. Adding fields is cheap. Renaming them isn’t, which is the argument for spending real time on step 2.

The tell that it’s working is the day your review surfaces something true that you didn’t already know. For me it was the empty goals field. Until that happens, keep tuning. You have a capture habit but not yet a system.

Make it yours

To be concrete about what “tailor it” means, here’s how I’d shape the same architecture for a few different jobs.

Engineering leader. Entities: people, teams, services. Content notes: one-on-ones, incidents, decisions. Person notes carry cadence and last-1:1, and the weekly review flags anyone you’re overdue with. Invaluable when you have fourteen reports and no honest sense of who you’ve been neglecting.

Researcher or grad student. Entities: papers, datasets, collaborators. Content notes: experiments, with hypothesis, method, result, and what you’d do differently as required sections, plus reading notes. The quarterly review becomes a literature-review scaffold and an advisor-meeting prep doc.

Founder. Entities: customers, investors, features. Content notes: customer conversations, pivots, metrics snapshots. The review reports how many customer conversations you had this week, a number every founder claims to care about and almost nobody actually counts.

Product manager. Entities: features, stakeholders, teams. Content notes: decision records (why we cut scope), user interviews. The weekly review flags features that have gone two weeks without a log entry.

Same architecture in every case: typed notes, wikilink relationships, a closed tag vocabulary, skills that match before creating and close the loop, and a read-only review that tells you the truth on Fridays.

The nouns change. The method doesn’t.

Start smaller than you think

If two hours is more than you have right now, do this instead. It’s about twenty minutes, and it’s genuinely enough to find out whether the idea is for you.

Install Obsidian, create a vault, install Dataview.
Create one folder, Daily Logs/, and one note type with five frontmatter fields.
Write one skill that captures it.
Use it for a week.

Then read the week back, and notice which question you wanted to ask that the data couldn’t answer.

That question is your next field. Build outward from there.