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 wiki?
  • Markdown pages (default — always)
  • Comparison tables
  • Slide decks (Marp)
  • Charts / visualizations
  • Structured data (YAML frontmatter, Dataview queries)
  • Exportable reports

Tier Classification

Based on answers, classify the wiki into a tier (share this with the user):

Tier	Sources	Entities	Duration	Example
Light	5-20	Few/none	Days-weeks	Reading a single book, trip planning
Medium	20-100	Dozens	Weeks-months	Research project, course notes, competitive analysis
Heavy	100+	Hundreds	Months-years	Ongoing team wiki, long-term research program, personal life wiki

The tier determines how much indexing infrastructure, how many page types, and how formal the schema needs to be.

---

Phase 3: STRUCTURE — Design the Directory Layout

Based on Phases 1-2, propose a directory structure. Present it to the user and iterate.

See Directory Structure Templates.

Knowledge Graphs

All ontology/knowledge-graph files live flat in infranodus/ at the project root, registered in infranodus/manifest.json (file → saved InfraNodus graph). This is a core part of the workflow — not optional. Rules:

1. Curated ontologies are append-only — NEVER regenerate them from scratch. Read the existing file first, then append only lines covering genuinely new content, matching its format exactly; removing or editing a line is a deliberate, line-by-line editorial decision.
2. Files with generated: true frontmatter belong to their generator script (e.g. the infranodus skill's repo/vault scans) — never append to or hand-edit them. Always check the frontmatter before touching any file in infranodus/.
3. Generate with the ontology-generator skill (via /ontology-generator or the Skill tool) from the folder's page content; save as infranodus/<folder-name>-ontology.md with curated: true and wikilinksMode: wikilinksOnly. If the skill is missing, ask the user to install it from https://github.com/infranodus/skills.
4. Upload with the bundled script, never via create_knowledge_graph calls: python3 <this skill's dir>/scripts/upload_wiki_ontology.py . --file infranodus/<folder-name>-ontology.md for a new file, plain python3 <this skill's dir>/scripts/upload_wiki_ontology.py . to sync appended lines — it records graphName + url in the manifest. Then save the graph analysis to output/<folder-name>-knowledge-graph-analysis.md and act on the gaps.

See Knowledge Graphs and Ontology Policy

Page Types to Consider

Propose page types based on the domain. Common ones:

See Directory Structure Templates.

Naming Conventions

Propose and confirm with the user:

• File naming: kebab-case (market-analysis.md) vs other conventions
• Wikilinks: [[page-name]] style for cross-references (Obsidian-compatible)
• Frontmatter: What YAML fields? (title, date, tags, source_count, status)
• Date format: ISO 8601 (2026-04-08) recommended

Present and Iterate

Show the proposed structure as a tree diagram. Ask:

• "Does this capture the categories you need?"
• "Any page types missing for your domain?"
• "Do you want to add/remove any directories?"

---

Phase 4: SCHEMA — Write the Configuration Document

This is the most important phase. The schema (CLAUDE.md / AGENTS.md) is what turns a generic LLM into a disciplined wiki maintainer.

Determine Which Schema File

• Claude Code: CLAUDE.md
• OpenAI Codex: AGENTS.md
• Other agents: Ask the user what their agent uses for system instructions

Schema Sections to Include

Write the schema document with these sections, tailored to the user's domain:

1. Project Overview

• One paragraph describing what this wiki is, what domain it covers, and its purpose.

2. Directory Structure

• Document the agreed structure from Phase 3. Explain what goes where.
• Include a Knowledge Graphs note: infranodus/ holds the graph files, infranodus/manifest.json maps each file to its saved InfraNodus graph (graphName + url — query these first via analyze_existing_graph_by_name / retrieve_from_knowledge_base instead of re-analyzing), and files with generated: true frontmatter are machine-regenerated (never append or hand-edit) while curated ontologies are append-only.

3. Page Templates

• For each page type, provide a template with:
  • Required YAML frontmatter fields
  • Section structure (what headings to use)
  • Content guidelines (what to include, what level of detail)
  • Cross-referencing rules (when to create wikilinks)

4. Ingest Workflow

• Step-by-step instructions for when a new source is added:
  1. Read the source
  2. Discuss key takeaways with the user (optional — based on user preference)
  3. Create a source summary page
  4. Update or create entity/concept pages
  5. Update the index
  6. Update the overview if the new source significantly changes the picture
  7. Append to the log
  8. Flag any contradictions with existing wiki content

5. Query Workflow

• How to answer questions against the wiki:
  1. Read the index to find relevant pages
  2. Read the relevant pages
  3. Synthesize an answer with citations to wiki pages
  4. Optionally: file the answer as a new wiki page if it's valuable

6. Lint Workflow

• Periodic health checks:
  • Find contradictions between pages
  • Find stale claims superseded by newer sources
  • Find orphan pages (no inbound links)
  • Find concepts mentioned but lacking their own page
  • Find missing cross-references
  • Suggest new questions to investigate
  • Suggest sources to look for

7. Conventions

• Tone and voice (academic? casual? technical?)
• Citation style (inline links? footnotes? source page references?)
• How to handle uncertainty and contradictions
• When to create a new page vs update an existing one
• When to flag something for user review vs handle autonomously

Present and Iterate

Show the user the draft schema. This is the document they'll live with, so get it right. Ask:

• "Does the ingest workflow match how you want to work? Some people prefer to stay involved at every step; others want to batch-ingest with minimal supervision."
• "Any conventions you want to add or change?"
• "How much autonomy should the LLM have? Should it create new entity pages automatically, or always ask first?"

---

Phase 5: WORKFLOWS — Define the Operations

Flesh out the three core operations based on user preferences.

Ingest Preferences

Ask with AskUserQuestion tool:

• Interactive or batch? "Do you want to discuss each source as it's ingested, or just tell me to process a batch and review the results?"
• Depth of summaries: "How detailed should source summaries be? A paragraph? A full page? Depends on the source?"
• Auto-create entities? "Should I automatically create pages for new entities I encounter, or ask you first?"
• Image handling: "Will your sources contain images? Should I download them locally?" (If yes, configure Obsidian's attachment folder)

Query Preferences

Ask using the AskUserQuestion tool:

• Filing answers: "When you ask a question and get a good answer, should I automatically file it as a wiki page, ask first, or never?"
• Output formats: "Do you want answers as plain text, as new markdown pages, as tables, or should I ask each time?"
• Citation style: "How should I cite sources in answers? Link to the wiki summary page? Link to the original source? Both?"

Lint Preferences

Ask using the AskUserQuestion:

• Frequency: "Should I suggest a lint pass after every N ingests? Or only when you ask?"
• Scope: "Should lint be comprehensive (check everything) or focused (only check recently changed pages)?"
• Auto-fix: "Should I fix minor issues (broken links, missing cross-refs) automatically, or list them for your review?"

Document the Workflows

Add the agreed workflows to the schema document with enough detail that the LLM can follow them in future sessions without re-asking these questions.

---

Phase 6: TOOLING — Set Up the Environment

Based on the user's setup, recommend and configure tools.

Essential: File Viewer

• Obsidian (recommended): Markdown editor with graph view, wikilinks, and plugins.

  • Configure: Attachment folder path for images
  • Recommend plugins based on needs:
    • Dataview: If using YAML frontmatter for structured queries
    • Marp Slides: If generating presentations
    • Graph View: Built-in, but call attention to it for wiki navigation
    • Obsidian Web Clipper: Browser extension for capturing web articles as markdown
    • InfraNodus AI Graph View: Advanced knowledge graph visualization and analysis of the pages' content and connections between the pages

• VS Code / other editor: Works fine, just loses graph view and wikilink navigation.

• InfraNodus: Content gap analysis, insight generation, and knowledge graph analysis and optimization via the InfraNodus MCP server tools or via MCPorter as described at https://infranodus.com/mcp/deploy-mcporter. Ask the user to set up an API key for InfraNodus and update the environment you're using to be able to access that key when needed without saving it to the conversation or wiki.

• infranodus skill (repo/vault scanner): If the infranodus skill is listed among the available skills, invoke it (via /infranodus or the Skill tool) for deterministic, LLM-free scans that complement the curated ontologies: mapping the wiki's page-link structure as a graph, mining any code repo among the raw sources (docs, docstrings, WHY/NOTE comments, commit/PR/issue history), and extracting the text layer of PDF collections (a structural map of what the papers literally say — distinct from this skill's summarized wiki pages). It writes generated: true scopes into the same infranodus/ folder + manifest. Refresh generated scopes by re-invoking the skill, never by editing the files — and a clean rebuild of an already-uploaded scope requires deleting its graph in InfraNodus first (uploads append). Offer this during ingest (Phase 9) when the corpus includes a repo, or whenever the user wants the vault's link topology as a graph.

Optional: Search

Assess search needs based on tier:

• Light tier: Index file is sufficient. No additional tooling needed.
• Medium tier: Index file works, but suggest they revisit if it gets slow. Mention qmd as an option.
• Heavy tier: Recommend setting up qmd or a similar local search tool from the start. Offer to help configure it.

Optional: Version Control

• Git: Recommend initializing the wiki as a git repo. Free version history, branching, collaboration. Do it for the user if they agree.
• Offer to set up .gitignore (exclude .obsidian/workspace.json and other ephemeral Obsidian files).

Optional: CLI Tools

For power users or heavy-tier wikis, offer to build simple helper scripts:

• Search script (grep/ripgrep wrapper for the wiki)
• Stats script (page count, word count, orphan detection)
• Ingest helper (moves a file to raw/ and kicks off the ingest workflow)

Ask what the user already has installed and what they're comfortable with. Don't over-engineer the tooling for light-tier wikis.

---

Phase 7: SCAFFOLD — Create the Directory Structure

Now build it. Create the agreed directory structure with starter files.

Create directories and files:

1. Directory tree — create all agreed directories
2. CLAUDE.md / AGENTS.md — the schema document from Phase 4
3. index.md — empty index with the agreed format and section headers
4. log.md — initialized with a first entry: ## [YYYY-MM-DD] init | Wiki created
5. overview.md — a placeholder noting the wiki's purpose and that it will be populated as sources are ingested
6. Page templates — optionally create example template files in a _templates/ directory for reference
7. .gitignore — if git was chosen
8. Initialize git repo — if git was chosen

Present the Result

Show the user the created structure. Walk through each file briefly. Ask:

• "Does this look right?"
• "Want to adjust anything before we do the first ingest?"

---

Phase 8: ACQUIRE — Get Sources Into raw/

Re-runnable. Touches only raw/ — never wiki/. Steps:

1. Detect the mode: no wiki/sources/*.md yet → first run (acquire ONE source as a test drive); otherwise → ongoing bulk acquisition. If raw/ already holds unprocessed material, skip straight to Phase 9.
2. Ask where the material is: a folder on disk, a list of URLs, a reference-manager export, a web search for new sources, or files the user dropped in manually.
3. For each item: determine the source TYPE, convert if needed (PDF → markdown, YouTube → transcript, web page → markdown), place it in the typed raw/ subfolder (create on the fly), keep lossy originals in raw/assets/.
4. Report what was acquired (counts, subfolders, failures) and hand off to Phase 9.

See Phase 8: ACQUIRE and Phase 9: PROCESS — mode-detection script, capture-channel table, and the exact prompts.

Phase 9: PROCESS — Ingest raw/ → wiki/

Re-runnable. Reads raw/, writes wiki/ — no acquisition here. When the user says "ingest", "process raw/", or "update the wiki" on an existing wiki, jump directly here — do NOT re-run Phases 1–7. Steps:

1. Show the confirmation prompt (verbatim wording in the reference) with scope options: all of raw/, one subfolder, or one file.
2. Inventory unprocessed sources — every raw/ file without a matching wiki/sources/<slug>.md.
3. Process each source per the schema's ingest workflow (source summary → system/concept/connection updates → question pages → index → log → contradiction flags), reporting one-line progress.
4. After the batch: append new relations to the curated ontologies in infranodus/ (never regenerate — see the policy in Phase 3), sync with python3 <this skill's dir>/scripts/upload_wiki_ontology.py ., refresh output/<folder>-knowledge-graph-analysis.md, and re-invoke the infranodus skill for any generated scopes.
5. First run only: flag schema adjustments. Then summarize the batch and suggest Phase 10 if ≥10 new sources came in or gaps shifted.

See Phase 8: ACQUIRE and Phase 9: PROCESS — full procedure, inventory script, and handoff text.

---

Phase 10: PLAN — Research Direction and Todo Planning

After the wiki has accumulated enough content (typically 10+ sources, or after a significant round of ingestion), help the user step back and plan what to research next. This phase analyzes the wiki's current state — using InfraNodus gap analysis and the wiki's own structure — to produce a prioritized todo list that lives in a todos/ folder at the project root.

This phase can be run at any time, not just during initial setup. It's the natural follow-up whenever the user asks "what should I work on next?" or after a batch of new sources has been ingested.

Step 9.1: Assess Current State

Read the wiki's structural health:

1. Read wiki/index.md to understand what exists
2. Read wiki/overview.md for the current synthesis
3. Check for existing InfraNodus analyses in output/*-knowledge-graph-analysis.md — these contain identified content gaps, cluster structure, and recommendations
   • Also check infranodus/manifest.json for saved graphs (curated ontology scopes AND generated repo/vault scopes): run generate_content_gaps on their graphNames for LIVE gap analysis instead of relying only on the last saved analysis file — gaps in the vault-links or repo scopes surface under-connected pages/modules the ontology analyses miss
   • If the manifest has a memoryGraph, check it via memory_get_relations for recurring #dead-end and #corrected lessons — these are query-driven evidence of wiki gaps (a human actually asked and the wiki couldn't answer), often stronger signals than structural gap detection
4. Check wiki/questions/ for open research questions
5. Check wiki/data/ for personal data pages (empty = a gap worth flagging)
6. Check todos/ for existing todo files (to avoid duplicating or contradicting prior plans)

Summarize the state back to the user: how many sources, what's well-covered, what's thin.

Step 9.2: Identify Priorities

Using the InfraNodus analyses and wiki structure, identify the highest-value work to do next. Prioritize by convergence — gaps flagged by multiple analyses are more important than one-off mentions.

Common priority types: