/obsidian-brain

name: obsidian-brain
description: "Build a local Obsidian vault that acts as the company and founder second brain, the knowledge layer every other skill reads before acting and writes back to. Input: your raw material (PDFs, decks, transcripts, email, WhatsApp exports, loose notes). Output: a structured, linked vault (domain hubs, maps of content, atomic notes) with read-first/write-back protocols, no orphans, and a single source of truth for numbers. Use when the user mentions Obsidian, a vault, a knowledge base, a second brain, importing documents or transcripts, or wants to give Claude context once instead of repeating it every conversation."
license: MIT
metadata:
  author: "Sorank (https://sorank.com)"
  version: "1.2.0"

Obsidian Brain: the Company Knowledge Layer

Build and maintain a local Obsidian vault that holds everything the business (and the founder behind it) knows, so every other skill reads real context before acting and writes its work back when done.

The framing: Claude is the uranium, raw reasoning power in unlimited supply. The company's knowledge is what that power runs on. The Obsidian vault is the power plant, the infrastructure that turns the two into compounding output. A model without your facts produces generic advice; the same model on a well-built vault produces output that is specific, consistent across sessions, and smarter every week.

Why Obsidian: it stores plain markdown files on the user's own disk. Markdown is what Claude reads and writes natively, local files keep the data private and portable (no export lock-in), and wiki links turn scattered notes into the entity graph of the business. Any folder of markdown works the same way; Obsidian (https://obsidian.md) is simply the best free tool to browse and edit it.

This skill is the foundation of the kit. The other skills do the SEO and GEO work; this one defines where knowledge lives, how it gets in, and how it stays navigable. Four reference files hold the depth, load them when the matching section says so:

• `references/getting-started.md`: the from-zero on-ramp, install Obsidian, connect the agent, run the first scaffold session. Load this first when the user has no vault or no agent set up yet.
• `references/vault-architecture.md`: the full layered structure, frontmatter conventions per note type, hub and MOC patterns, naming and macOS pitfalls.
• `references/import-workflows.md`: step-by-step import for documents, WhatsApp, email and transcripts, plus the multi-agent fan-out for large backlogs.
• `references/link-audit.md`: how to run and read the two bundled scripts that find broken links, orphans, unreachable notes and duplicate people.

If the user is starting from zero (Obsidian not installed, no vault yet, agent not connected), begin with `references/getting-started.md`: it walks install, connecting the agent to the vault folder, and the first scaffold session in order, then this skill takes over.

When to use

• Scaffolding a vault from scratch, or restructuring a messy one into a navigable graph.
• Importing the user's pile into the vault: PDFs, decks, sales and podcast transcripts, support and analytics exports, email, WhatsApp chats.
• Connecting Claude to existing knowledge before any real work starts.
• Capturing a durable fact the moment the user states it, so it is never asked for twice.
• Auditing the graph: broken links, orphan notes, notes unreachable from the index, duplicate person notes.
• Logging completed SEO actions at the end of a session (every skill in this kit points here).

Boundaries: this skill builds and maintains the knowledge layer. The SEO and GEO work itself belongs to the other skills (seo-geo-audit to diagnose, content skills to produce, geo-tracking to measure). They read from the vault and write to its log; this skill defines how.

Architecture: entry points, hubs, then notes

A vault is navigable when an agent can land at the top and reach any fact in one or two link hops, never a full-text search. That requires a strict shape (full detail and an example tree in `references/vault-architecture.md`):

1. **One or two entry points.** A company uses one: `00-INDEX.md`. A founder whose personal life and business are entangled uses two: `00-INDEX.md` (business) and a personal index that links to it. Each entry point holds identity, the canonical numbers (or a link to them), the hard rules, and a map of the vault. Anything else lives one hop away. 2. **Domain hubs.** One hub per domain (admin, finance, product, marketing, content, people, health, and so on). The hub is a pure table of contents for its domain, linked from the entry point. 3. **Maps of content (MOC).** Only for large bases (a CRM, a competitor set, a content-idea swipe file). A MOC is a hub for a folder of many same-shaped notes. 4. **Atomic notes.** One subject per note. Reached from a hub or a MOC, never floating.

Why this shape and not flat folders: token economy. The entry point is the only thing an agent must read in full every session; from there it follows links to the two or three notes a task needs. Flat folders and orphan notes force the agent to grep or read everything, which is slow, expensive, and misses files. The graph is the index.

The three protocols

Read first

At the start of any task, locate the vault (a folder of .md notes, usually with a `.obsidian` directory; if unknown, ask once and record the path in the vault). Then:

1. Read the entry point (`00-INDEX.md`, plus the personal index if the task is personal). It maps everything. 2. Follow links to the notes the task needs: identity before writing copy, the numbers note before quoting a figure, the action log before recommending anything. 3. Ground every output in those facts. When the vault answers a question, do not ask the user.

The difference between generic advice and a usable deliverable is context: the right facts, the real voice, and the history of what was already tried. Reading first remove