personal_wiki_skill.md

This article describes a system for creating a personal knowledge wiki from an individual's data, emphasizing the role of a writer who understands and connects information rather than just filing it. It provides detailed instructions for setting up the wiki, including commands for ingesting, absorbing, querying, and cleaning data, as well as specifications for a Python script that converts various data formats (e.g., Day One, Apple Notes, Obsidian) into standardized markdown entries. The system aims to map a person's entire inner and outer world—projects, ideas, emotions, and patterns—by weaving every piece of data into a cohesive, interconnected knowledge base.

--- name: wiki description: Compile personal data journals, notes, messages, whatever 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" --- 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 Drop this file into .claude/skills/wiki/SKILL.md in any project. Put your data files in the project root. Run: /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 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 your-project/ data/ Your source files DO NOT MODIFY after ingest 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. You can override the wiki directory with --dir <name on any command. Each version is its own universe. Never read from or reference another version. --- 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. Here's how to handle common ones: Day One JSON .json with entries array : Each entry becomes a file. Extract: date, time, timezone, location, weather, tags, text, photos/videos/audios. Map dayone-moment:// URLs to relative file paths. Apple Notes exported .html , .txt , or .md files : Each note becomes a file. Extract: title first line or filename , creation date from metadata or filename , folder/tag, body text. Strip HTML formatting if needed. Obsidian Vault folder of .md files : Each note becomes a file. Preserve frontmatter. Extract: title, date from frontmatter or filename , tags, body. Convert wikilinks to plain text for raw entries. Notion Export .md or .csv files : Each page becomes a file. Extract: title, properties/metadata, body. Handle nested pages by flattening with parent context. Plain Text / Markdown Files folder of .txt or .md : 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. iMessage Export .csv or chat logs : Group by conversation and date. Each day's conversation with one person becomes an entry. Extract: date, participants, messages. CSV / Spreadsheet .csv , .tsv : Each row becomes an entry. Use column headers as frontmatter fields. Identify the date column and text/content column automatically. Email Export .mbox , .eml : Each email becomes an entry. Extract: date, from, to, subject, body. Strip signatures and quoted replies. Twitter/X Archive tweet.js or archive export : Each tweet becomes an entry. Extract: date, text, media URLs, reply context, engagement stats. Output Format Each file: {date} {id}.md with YAML frontmatter: yaml --- id: <unique identifier date: YYYY-MM-DD time: "HH:MM:SS" source type: <dayone|apple-notes|obsidian|notion|text|imessage|csv|email|twitter tags: ... any other metadata from the source --- <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. 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. Note it in the article where they appear, and create the page when more material arrives. 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 Python script scanning 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 use direct quotes to carry emotional weight? - 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. High backlink counts indicate central topics. 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. Query Patterns | Query type | Where to look | |-----------|--------------| | "Tell me about person " | people/ , backlinks, 2-3 linked articles | | "What happened with project ?" | Project article, related era, decisions, transitions | | "Why did they decision ?" | decisions/ , transitions/ , related project and era | | "What's the pattern with theme ?" | patterns/ , philosophies/ , tensions/ , life/ | | "What was time period like?" | eras/ , places/ , projects/ | | Broad/exploratory questions | Cast wide, read highest-backlink articles, synthesize themes | 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 who links to whom , 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 individual events as section headings ? - Line count: bloated 120 lines or stub <15 lines ? - Tone: flat/factual/encyclopedic or AI editorial voice? - Quote density: more than 2 direct quotes? More than a third quotes? - Narrative coherence: unified story or list of random events? - 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 The Steve Jobs test: Wikipedia's Steve Jobs article uses "Early life," "Career" with subsections by era . NOT "The Xerox PARC Visit," "The Lisa Project Failure." Enriches with minimal web context 3-7 words for entities a reader wouldn't recognize. Identifies missing article candidates using the concrete noun test. Phase 3: Integration After all agents finish: 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 100 lines , high-reference backlink targets without articles, and misclassified 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, organizations, institutions - Named events or turning points with dates - Books, films, music, games referenced - Tools, platforms used significantly - Projects with names - Restaurants, venues tied to narrative moments Do NOT extract: generic technologies React, Python, Docker unless there's a documented learning arc, entities already covered, passing mentions. Phase 3: Planning Deduplicate, count references, rank by reference count, classify into directories, present candidate table: | | Article | Dir | Refs | Description | |---|---------|-----|------|-------------| Phase 4: Creation Create in parallel batches of 5 agents. Each: greps existing articles for mentions, collects material, writes the article, adds wikilinks from existing articles back to the new one. Reclassification with --reorganize Move misclassified articles to correct directories. Common moves: - life/ to philosophies/ : articles stating beliefs - life/ to patterns/ : articles with trigger-response structure - events/ to transitions/ : multi-week uncertain periods - events/ to decisions/ : articles with enumerated reasons --- Directory Taxonomy Directories emerge from the data. Don't pre-create them. Here's a reference of common types: Core Directories | Directory | Type | What goes here | |-----------|------|---------------| | people/ | person | Named individuals | | projects/ | project | Things the subject built with serious commitment | | places/ | place | Cities, buildings, neighborhoods | | events/ | event | Specific dated occurrences | | companies/ | company | External companies | | institutions/ | institution | Schools, programs, organizations | Media and Culture | Directory | Type | What goes here | |-----------|------|---------------| | books/ | book | Books that shaped thinking | | films/ | film | Movies/shows that mattered | | music/ | music | Artists/groups that mattered | | games/ | game | Games that shaped projects or social life | | tools/ | tool | Software tools central to practice | | platforms/ | platform | Services used as channels | | courses/ | course | Learning resources | | publications/ | publication | Newsletters, blogs read regularly | Inner Life and Patterns | Directory | Type | What goes here | |-----------|------|---------------| | philosophies/ | philosophy | Articulated intellectual positions about how to work and build | | patterns/ | pattern | Recurring behavioral cycles with triggers, mechanisms, outcomes | | tensions/ | tension | Unresolvable contradictions between two values | | identities/ | identity | Self-concepts or role labels that shaped decisions | | life/ | life | Biographical themes that aren't philosophies or patterns | Narrative Structure | Directory | Type | What goes here | |-----------|------|---------------| | eras/ | era | Major biographical phases connecting multiple articles | | transitions/ | transition | Liminal periods between commitments | | decisions/ | decision | Inflection points with enumerated reasoning | | experiments/ | experiment | Time-boxed tests with a hypothesis and result | | setbacks/ | setback | Adverse incidents that disrupted plans | Relationships and People | Directory | Type | What goes here | |-----------|------|---------------| | relationships/ | relationship | Dynamics between the subject and others | | mentorships/ | mentorship | Knowledge-transfer relationships | | communities/ | community | Online communities built or joined | Work and Strategy | Directory | Type | What goes here | |-----------|------|---------------| | strategies/ | strategy | Named business strategies | | techniques/ | technique | Technical systems and engineering artifacts | | skills/ | skill | Competencies developed over time | | ideas/ | idea | Documented but unrealized concepts | | artifacts/ | artifact | Documents, plans, spreadsheets created | Other | Directory | Type | What goes here | |-----------|------|---------------| | restaurants/ | restaurant | Eating/drinking places tied to moments | | health/ | health | Medical situations, physical wellbeing | | media/ | media | Forms of self-expression diary, vlog, newsletter | | routines/ | routine | Specific daily/weekly schedules | | metaphors/ | metaphor | Figurative frameworks used to understand self or work | | assessments/ | assessment | Dated self-evaluations | | touchstones/ | touchstone | Encounters with cultural works that triggered reflection | 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. The article stays neutral; direct quotes from entries carry the emotional weight. 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 One exception: Direct quotes carry the voice. The article is neutral. The quotes do the feeling. Article Format markdown --- 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 | |------|-------| Backlinks {Generated by rebuild-index} Linking Use wikilinks between articles. Cite sources in frontmatter using entry IDs. Narrative Coherence Every article must have a point. Not "here are 4 times X appeared" but "X represented Y in the subject's life." A reader should finish feeling they understand the significance. Structure by Type | Type | Structure | |------|-----------| | person | By role/relationship phase | | place | By what happened there and what it meant | | project | By conception, development, outcome | | event | What happened brief , why it mattered bulk , consequences | | philosophy | The thesis, how it developed, where it succeeded/failed | | pattern | The trigger, the cycle, attempts to break it | | transition | What ended, the drift, what emerged | | decision | The situation, the options, the reasoning, the choice | | era | The setting, the project, the team, the emotional tenor | 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/restaurant | 20-40 | | Company | 25-50 | | Philosophy/pattern/relationship | 40-80 | | Era | 60-100 | | Decision/transition | 40-70 | | Experiment/idea | 25-45 | | 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. 40 stubs is as bad as 5 bloated articles. 7. The structure is alive. Merge, split, rename, restructure freely. 8. View photos. Understand what they show and integrate them into the narrative. 9. Connect, don't just record. Find the web of meaning between entities. 10. 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 . - Rebuild index.md and backlinks.json only at the very end of a command.