Most “how I use Obsidian” posts are about capture. This is the page where someone shows you a beautiful folder hierarchy and explains how their daily note flows into a graph of backlinks and emerges later as wisdom. I tried that for years. It never stuck.
The vault I actually use now isn’t optimized for capture. It’s optimized to push back on the things I tend to do wrong.
The blind-spots list as an architectural decision
The first file an agent (Claude, mostly) reads when entering my vault is AGENTS.md. About two-thirds of the way down, there’s a section called Blind Spots to Flag:
- Over-complicating simple things
- Going too wide and never finishing
- Planning instead of making
- Hoarding work instead of sharing it
- Letting perfect be the enemy of good
That’s not a self-help affirmation. It’s a brief to anything that reads it. When I’m working in the vault and I’m doing one of those things, I want to be told. The system isn’t passive.
The same file has a section called Outcome Engineering Principles: build to answer questions, bias toward shipping, map before building. These are the rails the vault wants me on. Most “personal knowledge management” systems would treat these as preferences. Mine treats them as setup.
Skills, not features
The other thing my vault has that most don’t is skills - small, opinionated workflows I can invoke by name. Each one is a markdown file in Skills/ with a clear job:
til- capture a single insight, search for connections across the vault, promote durable truths to memoryweekly-review- honest weekly review; reads priorities, learning log, recent files, surfaces stale priorities and winslog-decision- log a creative or project decision with reasoning; route it to the correct project’sdecisions.mdscout- research sweep that decomposes a question into angles, runs parallel searches, synthesises into a brief saved toLearning/scouts/
The shape that matters: each skill has a specific job and a specific output destination. They’re not “shortcuts.” They’re closer to small departments. The TIL skill doesn’t just dump a note somewhere - it tries to connect the new insight to existing notes, and if the insight feels durable, promotes it to long-term memory.
This is the part most PKM advice misses. Capturing things is easy. Doing the right thing with what you capture is the work.
The creative ecosystem, made explicit
I do four creative things in parallel: writing, D&D campaigns, an SNES-style RPG project, and (less actively) cooking. Most PKM systems treat these as silos. Mine has a section in AGENTS.md titled “Creative Ecosystem” that says, plainly:
My projects feed each other. The fantasy writing informs the worldbuilding. The worldbuilding feeds the D&D campaigns. The D&D campaigns generate ideas for the RPG. The RPG builds skills that loop back into everything. Treat these as a connected system, not separate hobbies.
Writing this out doesn’t do anything mechanical. But it changes how I think when I’m in any one project - and changes how an agent helps me when I am. A note about a magic item from a D&D session isn’t just a campaign artifact; it might be an opening scene for a story. The vault is configured to look for those connections.
PM thinking as an operating system
I do product management for a living. Years of practice with that mental model leak into how I make decisions about everything else - scoping personal projects, prioritising creative work, killing things that have been “someday” for too long. The vault makes that explicit:
If a personal project feels vague or stuck, ask: “what problem are you solving, and for whom?” If scope is creeping, use prioritization framing: “what’s the MVP of this?” If a decision feels hard, surface the trade-off explicitly rather than just listing options. If something has been in “someday” for a long time, treat it like a backlog item: is it actually a priority, or should it be killed?
The principle I keep returning to: no PRDs for D&D sessions, but the lens is fair game. I don’t want my personal life to look like a Jira board. I do want the same clear thinking I bring to work.
What I’d warn someone starting from scratch
Three things, if you’re trying to build something like this:
- Resist the urge to over-architect upfront. The structure should grow from real use, not from a YouTube video about The One True Method.
- Write down what you’re bad at. Most personal systems are designed assuming you’ll do everything right. That’s not the situation any of us are in. Design for the version of you that procrastinates and over-thinks, because that’s the version that’ll be using it most days.
- Make the system opinionated. A neutral system is a passive system. A system with views - about scope, about shipping, about when to stop - actually helps.
The vault isn’t fancy. It’s a folder of markdown files. What makes it useful is that it knows what I’m bad at, and it’s set up to call me on it.