Second Brain Wiki

Second Brain Wiki

Reads ~/second-brain/wiki/ and answers "what do I already know about this?" so nobody has to manually open files or paste content into a prompt. This is the retrieval half of the second brain; second-brain-ingest is the write half.

Step 1: Determine the query

Step 2: Search the tag index first (fast path)

Read ~/second-brain/wiki/tags.md. If the query matches a project/*, person/*, type/*, or status/* tag (exact or close match, e.g. "andy" matches person/andy-braren), collect every page listed under that tag. This is faster than scanning all pages and is the primary path once tagging (via second-brain-ingest) has been running for a while.

If tags.md doesn't exist yet or the query doesn't match a tag cleanly, fall through to Step 3.

Step 3: Fall back to index and content search

1. Read ~/second-brain/wiki/index.md and look for title matches under any category.
2. If still nothing, grep page titles and first-10-lines across ~/second-brain/wiki/*.md (excluding index.md, log.md, tags.md) for the query term.

Step 4: Rank and read

1. Combine results from Steps 2-3, deduplicated.
2. Rank by: exact tag match > title match > content match. Within a tier, prefer more recent pages (check log.md for dates if needed).
3. Cap at the top 5 pages -- but only for pages outside a stated date range. If the caller gave a specific range (see Step 1), every page dated inside that range gets read regardless of how many that is; the cap-of-5 applies only to older background material beyond the range. A person with heavy tag volume (dozens of pages over months) can still have several matches in a one-week window -- a flat cap would silently drop same-day or same-week pages behind months of lower-relevance history, which is the opposite of what a time-bounded caller needs. With no stated range, the plain top-5-by-recency cap applies as usual.
4. Read each selected page in full.

Step 5: Return the answer

Return a short synthesis, not a dump of the raw pages:

**Second brain context: <query>**

<1-3 sentence synthesis across the matched pages -- what's the state of this,
what's already been decided or discussed>

**Relevant pages:**
- [Page Title](page-slug.md) -- one-line summary of what it covers
- [Page Title](page-slug.md) -- one-line summary of what it covers

**Coverage:** <N pages found via tags, M via title/content search> | or
"Nothing found in the wiki for this yet."

If called by another skill (not directly by the user), skip the chat formatting and just return the structured data (page paths + one-line summaries + synthesis) for that skill to fold into its own output.

Example: good vs bad response

Good — specific, synthesized, sourced:

Second brain context:

Recent work with centers on the prototype-creator/evaluator-super-agent merge (as of the 2026-07-09 meeting) and PatternFly 6 migration timing (Q3 target, confirmed 2026-07-01). No open blockers from him currently.

Relevant pages:

• /Evan Meeting — 2026-07-09 — Apollo canvas, prototype-creator merge plan
• Weekly Design Sync — 2026-07-01 — PF6 migration, Nielsen's heuristics adopted

Coverage: 4 pages found via person/andy-braren tag

Bad — just lists files with no synthesis:

Here are some pages that mention : andy-evan-2026-07-09.md, andy-evan-2026-06-29.md, weekly-design-sync-2026-07-01.md.

The bad version makes the caller do the work the retrieval was supposed to save them. Synthesizing across pages, not just finding them, is the point.

Common Mistakes

Read-Only Constraint

This skill MUST NEVER create, edit, or delete anything under ~/second-brain/. If the user's request is actually about adding content (not looking something up), say so and point to second-brain-ingest.