llm-wiki

# LLM Wiki Setup Assistant

A guided, multi-phase workflow for designing and scaffolding a personal LLM-maintained wiki. The core idea: instead of re-deriving knowledge from raw documents on every query (like RAG), the LLM incrementally builds a persistent wiki — extracting, cross-referencing, and synthesizing knowledge once, then keeping it current as new sources arrive. The wiki compounds over time. The human curates sources and asks questions; the LLM does all the bookkeeping.

## Preamble (run first)

```
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"
```

## Architecture (for context)

Every LLM Wiki has three layers:

1. **Raw sources** — immutable collection of source documents (articles, papers, transcripts, images). The LLM reads but never modifies these. You need to understand from the user what the scope of the raw sources is for a particular project.
2. **The wiki** — LLM-generated markdown files (summaries, entity pages, concept pages, comparisons, synthesis). The LLM owns this layer entirely. You create the `/wiki` folder (or user-defined) in the project's folder for that (if it doesn't exist yet).
3. **The output** — This is where you store the output of your interactions with user for a particular project - you create it in the `/output` folder of the project (or user-defined) if it doesn't exist yet.
4. **The schema** — a configuration document (CLAUDE.md for Claude and AGENTS.md for Codex) that tells the LLMs how the wiki is structured, what conventions to follow, and what workflows to use. Co-evolved by user and LLM over time. Create both files so the folder is compatible with most LLMs.

## Phase Overview

```
1. DISCOVER    -> What domain? What's the goal? What sources?
2. SCOPE       -> How big? How deep? What outputs matter?
3. STRUCTURE   -> Directory layout, page types, naming conventions - see architecture above
4. SCHEMA      -> Write the CLAUDE.md and AGENTS.md of the local folder where the skill is invoked for configuration
5. WORKFLOWS   -> Define ingest, query, and lint operations
6. TOOLING     -> Obsidian plugins, InfraNodus tools for gap analysis, research, and text optimization, CLI tools, search, git
7. SCAFFOLD    -> Create the directory structure and starter files
8. ACQUIRE     -> Get sources into raw/ (hard-drive import, web fetch, transcription, PDF→md)
9. PROCESS     -> Ingest raw/ → wiki/ (summarize, update index, refresh ontologies)
10. PLAN       -> Analyze gaps, prioritize research directions, create actionable todos

Phases 8 and 9 are TWO DIFFERENT OPERATIONS. Phase 8 only touches raw/; Phase 9 only
reads raw/ and writes wiki/. Either can run without the other. Both are re-runnable.
```

---

## Phase 1: DISCOVER — What Are You Building This For?

Start by understanding the user's domain and motivation. Ask conversationally — 2-3 questions max per message using the AskUserQuestion tool.

### Core Questions

- **What domain or topic is this wiki for?** Get specific. Not just "research" but "competitive analysis of AI coding tools" or "tracking my health and psychology over time" or "reading notes for a political philosophy course."

- **What kinds of sources will you be feeding it?** Examples:
  - Academic papers (PDFs, arXiv links)
  - Web articles and blog posts
  - YouTube videos / podcast transcripts
  - Meeting notes / Slack threads
  - Books (chapter by chapter)
  - Journal entries / personal notes
  - Data files (CSVs, JSON)
  - Images, screenshots, diagrams

- **What's your end goal?** What does success look like?
  - "I want to deeply understand topic X and develop an original thesis"
  - "I want a living reference I can query months from now"
  - "I want to track how my understanding evolves over time"
  - "I want to produce a report / paper / presentation at the end"
  - "I want a structured record of everything I've read on this topic"

- **Are you starting fresh or do you already have sources?** If they have existing material, understand the volume and format.

- **Who else will use this?** Just the user, or a team? This affects structure and access conventions.

### Contextual Probes

Based on the domain, ask domain-specific questions using the AskUserQuestion tool:

- **Personal/self-improvement**: What aspects are you tracking? (health, goals, psychology, habits, relationships) Do you journal regularly? What format?
- **Research**: What's your current level of expertise? Are you exploring broadly or going deep on a specific question? Is there a deadline?
- **Book reading**: One book or a reading list? Fiction or non-fiction? What do you want to get out of it?
- **Business/team**: What's the knowledge problem you're solving? Who generates the sources? Who consumes the wiki?
- **Course/learning**: What course? What's the structure? Lectures, readings, problem sets?

Don't overwhelm. Gather enough to move to Phase 2. You can refine as you go.

---

## Phase 2: SCOPE — How Big and How Deep?

Now calibrate the wiki's scale and depth. This determines how much structure to build.

### Scale Assessment

Ask the user to estimate:

- **Source volume**: How many sources do you expect to add? (5-10? 50-100? 500+?)
- **Timeframe**: Over what period? (one weekend sprint? months of ongoing work?)
- **Session frequency**: How often will you work with it? (daily? weekly? sporadic bursts?)

### Depth Assessment

- **Entity tracking**: Do you need pages for individual entities (people, organizations, products, concepts)? Or is topic-level granularity enough?
- **Chronological tracking**: Does time matter? (e.g., tracking how a company's strategy evolved, or how your health changed over months)
- **Contradictions and debates**: Is tracking disagreement between sources important? (critical for research, less so for course notes)
- **Quantitative data**: Will there be numbers, metrics, data to track? Or is it primarily qualitative?

### Output Needs

- **What formats will you want to extract from the wi