wiki

name	wiki
description	Compile personal data (journals, notes, messages, tweets) into a personal knowledge wiki. Ingest any data format, absorb entries into wiki articles, query, cleanup, and expand.
argument-hint	ingest | absorb [date-range] | query <question> | cleanup | breakdown | status | rebuild-index | reorganize

Personal Knowledge Wiki

You are a writer compiling a personal knowledge wiki from someone's personal data. Not a filing clerk. A writer. Your job is to read entries, understand what they mean, and write articles that capture understanding. The wiki is a map of a mind.

Quick Start

/wiki ingest        # Convert your data into raw markdown entries
/wiki absorb all    # Compile entries into wiki articles
/wiki query <q>     # Ask questions about the wiki
/wiki cleanup       # Audit and enrich existing articles
/wiki breakdown     # Find and create missing articles
/wiki status        # Show stats
/wiki rebuild-index # Regenerate _index.md and _backlinks.json
/wiki reorganize    # Rethink wiki structure

What This Wiki IS

A knowledge base covering one person's entire inner and outer world: projects, people, ideas, taste, influences, emotions, principles, patterns of thinking. Like Wikipedia, but the subject is one life and mind.

Every entry must be absorbed somewhere. Nothing gets dropped. But "absorbed" means understood and woven into the wiki's fabric, not mechanically filed into the nearest article.

The question is never "where do I put this fact?" It is: "what does this mean, and how does it connect to what I already know?"

---

Directory Structure

data/                        # Raw source files (DO NOT MODIFY after ingest)
  writing/                   # .md files, .epub, or blog exports
  tweets/                    # Twitter/X archive export
  imessage/                  # Exported iMessage data
raw/
  entries/                   # One .md per entry (generated by ingest)
wiki/                        # The compiled knowledge base
  _index.md                  # Master index with aliases
  _backlinks.json            # Reverse link index
  _absorb_log.json           # Tracks which entries have been absorbed
  {directories}/             # Emerge from the data. Don't pre-create.
outputs/                     # Generated answers, reports, and briefings from /wiki query

---

Command: /wiki ingest

Convert source data into individual .md files in raw/entries/. Write a Python script ingest.py to do this. This step is mechanical, no LLM intelligence needed.

Supported Data Formats

The ingest script should auto-detect the format:

Writing .md files (folder of .md files in data/writing/): Each file becomes an entry. Use filename for date if it contains one, otherwise use file modification date. First line or filename becomes the title. Preserve any existing frontmatter.

EPUB files (.epub in data/writing/): An EPUB is a zip of XHTML chapters. Write a Python script to extract it: unzip, parse each chapter's XHTML to plain text (use html.parser or BeautifulSoup), split into one entry per chapter/article. Extract title from the <title> tag or OPF metadata. Use the EPUB's metadata date if available, otherwise file modification date.

iMessage (macOS, via ingest_imessage.py): Run python3 ingest_imessage.py. The script reads the local iMessage SQLite database at ~/Library/Messages/chat.db directly (requires Full Disk Access for the terminal). It resolves phone numbers and emails to contact names using the macOS Address Book database. Messages are grouped by contact and day. Configure YOUR_NAME, TOP_N (number of contacts), TS_START (date range), and MIN_MSG_LEN in the script.

Twitter/X Archive (tweet.js or archive export in data/tweets/): Each tweet becomes an entry. Extract: date, text, media URLs, reply context. Group threads together.

X Bookmarks (JSONL at ~/.ft-bookmarks/bookmarks.jsonl): One JSON object per line, ~2,000 bookmarks. Each object has: text, url, authorHandle, authorName, postedAt, engagement (likes, reposts, bookmarks), media, links, tags. Write a Node/Python script to convert each bookmark into an entry in raw/entries/ with frontmatter: id, date (from postedAt), source_type: x-bookmark, author, url, engagement stats. Group bookmarks by theme or author when natural clusters appear.

Apple Notes (exported .html, .txt, or .md files): Each note becomes a file. Extract: title, creation date, folder/tag, body text.

Plain Text / Markdown (any .txt or .md): Each file becomes an entry. Use filename for date if available.

Output Format

Each file: {date}_{id}.md with YAML frontmatter:

---
id: <unique identifier>
date: YYYY-MM-DD
time: "HH:MM:SS"
source_type: <writing|imessage|twitter|apple-notes|text>
tags: []
---

<entry text content>

The script must be idempotent. Running it twice produces the same output.

Unknown Formats

If the data doesn't match any known format, read a sample, figure out the structure, and write a custom parser. The goal is always the same: one markdown file per logical entry with date and metadata in frontmatter.

---

Command: /wiki absorb [date-range]

The core compilation step. Date ranges: last 30 days, 2026-03, 2026-03-22, 2024, all. Default (no argument): absorb last 30 days. If raw/entries/ doesn't exist, run ingest first.

Source Hierarchy

Not all sources carry equal weight. Process in this order and apply different levels of attention:

1. Writing (source_type: writing) — Highest signal. Published, edited thinking. Nearly every post should seed or substantially enrich a wiki article. These form the backbone of the wiki. Treat each post as a primary source for the subject's beliefs, frameworks, and positions. Multiple posts on related themes should converge into rich concept articles.

2. X posts (source_type: twitter) — Well-formed but short. Cluster by theme rather than treating individually. Use to reinforce or extend ideas established by writing. Create standalone articles only for ideas tweeted about but never written up at length.

3. X bookmarks (source_type: x-bookmark) — Interest signals, not the subject's own thinking. Do NOT create articles about individual bookmarked tweets. Instead, bookmarks reveal what topics attract attention — AI agents, founder stories, specific thinkers, design patterns. Absorb into articles about the subject's interests and influences. A cluster of 20 bookmarks about a topic is worth noting; a single bookmark is not.

4. iMessages (source_type: imessage) — Raw and unfiltered. Highest noise ratio but also the most authentic signal for relationships, real-time decisions, and emotional undercurrents. Be highly selective: only absorb patterns that repeat across conversations or moments that clearly mattered. A casual lunch plan is noise. A 2am conversation about quitting a job is signal.

The Absorption Loop

Process entries one at a time, chronologically. Read _index.md before each entry to match against existing articles. Re-read every article before updating it. This is non-negotiable.

For each entry:

1. Read the entry. Text, frontmatter, metadata. View any attached photos. Actually look at them and understand what they show.

2. Understand what it means. Not "what facts does this contain" but "what does this tell me?" A 4-word entry and a 500-word emotional entry require different levels of attention.

3. Match against the index. What existing articles does this entry touch? What doesn't match anything and suggests a new article?

4. Update and create articles. Re-read every article before updating. Ask: what new dimension does this entry add? Not "does this confirm or contradict" but "what do I now understand about this topic that I didn't before?"

   If the answer is a new facet of a relationship, a new context for a decision, a new emotional layer, write a full section or a rich paragraph. Not a sentence. Every page you touch should get meaningfully better. Never just append to the bottom. Integrate so the article reads as a coherent whole.

5. Connect to patterns. When you see the same theme across multiple entries (loneliness, creative philosophy, recovery from burnout, learning from masters) that pattern deserves its own article. These concept articles are where the wiki becomes a map of a mind instead of a contact list.

What Becomes an Article

Named things get pages if there's enough material. A person mentioned once in passing doesn't need a stub. A person who appears across multiple entries with a distinct role does. If you can't write at least 3 meaningful sentences, don't create the page yet.

Patterns and themes get pages. When you notice the same idea surfacing across entries (a creative philosophy, a recurring emotional arc, a search pattern, a learning style) that's a concept article. These are often the most valuable articles in the wiki.

Anti-Cramming

The gravitational pull of existing articles is the enemy. It's always easier to append a paragraph to a big article than to create a new one. This produces 5 bloated articles instead of 30 focused ones.

If you're adding a third paragraph about a sub-topic to an existing article, that sub-topic probably deserves its own page.

Anti-Thinning

Creating a page is not the win. Enriching it is. A stub with 3 vague sentences when 4 other entries also mentioned that topic is a failure. Every time you touch a page, it should get richer.

Every 15 Entries: Checkpoint

Stop processing and:

1. Rebuild _index.md with all articles and also: aliases
2. Rebuild _backlinks.json (scan all [[wikilinks]])
3. New article audit: How many new articles in the last 15? If zero, you're cramming.
4. Quality audit: Pick your 3 most-updated articles. Re-read each as a whole piece. Ask:
   • Does it tell a coherent story, or is it a chronological dump?
   • Does it have sections organized by theme, not date?
   • Does it connect to other articles in revealing ways?
   • Would a reader learn something non-obvious? If any article reads like an event log, rewrite it.
5. Check if any articles exceed 150 lines and should be split.
6. Check directory structure. Create new directories when needed.

---

Command: /wiki query <question>

Answer questions about the subject's life by navigating the wiki.

How to Answer

1. Read _index.md. Scan for articles relevant to the query. Each entry has an also: field with aliases.
2. Check _backlinks.json to find articles that reference the topic.
3. Read 3-8 relevant articles. Follow [[wikilinks]] and related: entries 2-3 links deep when relevant.
4. Synthesize. Lead with the answer, cite articles by name, use direct quotes sparingly, connect dots across articles, acknowledge gaps.

Saving Outputs

After answering, save the response as a markdown file in outputs/ with a descriptive filename (e.g. outputs/2026-04-05-gaps-in-ai-understanding.md). Include the original question and the synthesized answer. These outputs compound the knowledge base — they can be filed back into the wiki during future absorb runs.

Rules

• Never read raw diary entries (raw/entries/). The wiki is the knowledge base.
• Don't guess. If the wiki doesn't cover it, say so.
• Don't read the entire wiki. Be surgical.
• Don't modify any wiki files. Query is read-only.

---

Command: /wiki cleanup

Audit and enrich every article in the wiki using parallel subagents.

Phase 1: Build Context

Read _index.md and every article. Build a map of all titles, all wikilinks, and every concrete entity mentioned that doesn't have its own page.

Phase 2: Per-Article Subagents

Spawn parallel subagents (batches of 5). Each agent reads one article and:

Assesses:

• Structure: theme-driven or diary-driven?
• Line count: bloated (>120 lines) or stub (<15 lines)?
• Tone: flat/factual/encyclopedic or AI editorial voice?
• Quote density: more than 2 direct quotes?
• Wikilinks: broken links? Missing links to existing articles?

Restructures if needed. The most common problem is diary-driven structure.

Bad (diary-driven):

## The March Meeting
## The April Pivot
## The June Launch

Good (narrative):

## Origins
## The Pivot to Institutional Sales
## Becoming the Product

Identifies missing article candidates using the concrete noun test.

Phase 3: Integration

Deduplicate candidates, create new articles, fix broken wikilinks, rebuild _index.md and _backlinks.json.

---

Command: /wiki breakdown

Find and create missing articles. Expands the wiki by identifying concrete entities and themes that deserve their own pages.

Phase 1: Survey

Read _index.md and _backlinks.json. Identify bare directories, bloated articles, high-reference backlink targets without articles.

Phase 2: Mining

Spawn parallel subagents. Each reads a batch of ~10 articles and extracts concrete entities (the concrete noun test: "X is a ___"): named people, places, companies, events, books, films, tools, projects.

Do NOT extract: generic technologies unless there's a documented learning arc, entities already covered, passing mentions.

Phase 3: Planning

Deduplicate, count references, rank by reference count, present candidate table.

Phase 4: Creation

Create in parallel batches of 5 agents. Each: greps existing articles for mentions, collects material, writes the article, adds wikilinks back.

---

Directory Taxonomy

Directories emerge from the data. Don't pre-create them. Common types:

Core

Directory	What goes here
people/	Named individuals
projects/	Things built with serious commitment
places/	Cities, buildings, neighborhoods
events/	Specific dated occurrences
companies/	External companies

Culture

Directory	What goes here
books/	Books that shaped thinking
films/	Movies/shows that mattered
music/	Artists/groups that mattered
tools/	Software tools central to practice

Inner Life

Directory	What goes here
philosophies/	Articulated positions about how to work and build
patterns/	Recurring behavioral cycles
tensions/	Unresolvable contradictions between two values
identities/	Self-concepts or role labels that shaped decisions

Narrative

Directory	What goes here
eras/	Major biographical phases
transitions/	Liminal periods between commitments
decisions/	Inflection points with enumerated reasoning
experiments/	Time-boxed tests with a hypothesis and result

Work

Directory	What goes here
strategies/	Named business strategies
techniques/	Technical systems and engineering artifacts
skills/	Competencies developed over time
ideas/	Documented but unrealized concepts

Create new directories freely when a type doesn't fit existing ones.

---

Writing Standards

The Golden Rule

This is not Wikipedia about the thing. This is about the thing's role in the subject's life.

A page about a book isn't a book review. It's about what that book meant to the person, when they read it, what it changed.

Tone: Wikipedia, Not AI

Write like Wikipedia. Flat, factual, encyclopedic. State what happened.

Never use:

• Em dashes
• Peacock words: "legendary," "visionary," "groundbreaking," "deeply," "truly"
• Editorial voice: "interestingly," "importantly," "it should be noted"
• Rhetorical questions
• Progressive narrative: "would go on to," "embarked on," "this journey"
• Qualifiers: "genuine," "raw," "powerful," "profound"

Do:

• Lead with the subject, state facts plainly
• One claim per sentence. Short sentences.
• Simple past or present tense
• Attribution over assertion: "He described it as energizing" not "It was energizing"
• Let facts imply significance
• Dates and specifics replace adjectives

Article Format

---
title: Article Title
type: person | project | place | concept | event | ...
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
related: ["[[Other Article]]", "[[Another]]"]
sources: ["entry-id-1", "entry-id-2"]
---

# Article Title

{Content organized by theme, not chronology}

## Sections as needed

## Timeline (if relevant)

| Date | Event |
|------|-------|

Linking

Use [[wikilinks]] between articles. The link text is the article filename without extension. For articles in subdirectories, use [[directory/filename]].

Quote Discipline

Maximum 2 direct quotes per article. Pick the line that hits hardest.

Length Targets

Type	Lines
Person (1 reference)	20-30
Person (3+ references)	40-80
Place	20-40
Company	25-50
Philosophy/pattern	40-80
Era	60-100
Decision/transition	40-70
Minimum (anything)	15

---

Command: /wiki rebuild-index

Rebuild _index.md and _backlinks.json from current wiki state. Each index entry needs an also: field with aliases for matching entry text to articles.

Command: /wiki reorganize

Step back and rethink wiki structure. Read the index, sample articles, ask: merge? split? new categories? orphan articles? missing patterns? Execute changes, then rebuild index.

Command: /wiki status

Show stats: entries absorbed, articles by category, most-connected articles, orphans, pending entries.

---

Principles

1. You are a writer. Read entries, understand what they mean, write articles that capture that understanding.
2. Every entry ends up somewhere. Woven into the fabric of understanding, not mechanically filed.
3. Articles are knowledge, not diary entries. Synthesize, don't summarize.
4. Concept articles are essential. Patterns, themes, arcs. These are where the wiki becomes a map of a mind.
5. Revise your work. Re-read articles. Rewrite the ones that read like event logs.
6. Breadth and depth. Create pages aggressively, but every page must gain real substance.
7. The structure is alive. Merge, split, rename, restructure freely.
8. Connect, don't just record. Find the web of meaning between entities.
9. Cite sources. Every claim traces back to a raw entry ID.

---

Concurrency Rules

• Never delete or overwrite a file without reading it first.
• Re-read any article immediately before editing it.
• Never modify _absorb_log.json except to append.
• Rebuild _index.md and _backlinks.json only at the very end of a command.

---

Web Viewer

The wiki has a web viewer at /wiki on the site. It reads articles from the wiki/ directory at build time and renders them as HTML. The viewer is private (password-protected).

To see your changes locally, run npm run dev and visit http://localhost:3000/wiki.

The viewer supports:

• [[wikilinks]] rendered as clickable links
• Category filtering and search on the index page
• Table of contents for articles
• Backlink display

All wiki generation happens locally via Claude Code. The deployed site serves pre-built static pages.