Llm wiki design

LLM-Wiki Design

Goal

Design a custom LLM-Wiki system that starts thin, stays inspectable and has explicit trust controls.

When to use

• The user wants to build their own LLM-Wiki implementation, CLI, Obsidian plugin, repo-docs agent, or team workflow rather than adopt an existing tool.
• A product decision is needed on data model, retrieval tier, provenance, storage, sync, review or agent integration before any code is written.
• The user asks for an MVP plan, architecture sketch, or build-vs-buy justification for a wiki/knowledge-base system.
• Do not use this skill to answer questions from an already-built wiki (route to a query skill instead) or to pick between existing off-the-shelf tools (route to llm-wiki-choose).

Inputs

• Product/workflow goal.
• User type: personal, team, company, plugin, CLI, SaaS, research tool.
• Corpus type and scale.
• Local-first/privacy constraints.
• Target agents and editors.
• Required integrations.

Procedure

1. Frame the build-vs-buy reason

Custom build is justified when at least one is true:

• claim-level provenance is required;
• existing tools do not preserve human edits;
• local-first/offline operation is mandatory;
• team governance or permission model is specific;
• product UX is the main differentiator;
• corpus shape is unusual;
• integration with a workflow/repo/editor is central.

If none apply, recommend llm-wiki-choose again and prefer a ready-made path.

2. Define the domain model

Start with:

raw source -> source page -> entity/concept/comparison/synthesis/query pages

Define page types, lifecycle states, source hashes, claim types, review gates and protected sections.

3. Pick retrieval tier

Use the smallest sufficient tier:

Tier	Use when
index + grep	first 50-100 sources or strong filenames/wikilinks
hybrid lexical + semantic	conceptual recall fails or corpus grows
graph-aware retrieval	relationships, provenance and multi-hop questions dominate
custom storage	product requirements demand concurrency, permissions or scale

4. Design ingest pipeline

Prefer two-step ingest:

1. analyze source into structured claims/entities/concepts without writing final pages;
2. generate or patch wiki pages from the analysis;
3. run lint and review.

Add confidence and rejection feedback before adding complex graph UI.

5. Design write safety

Specify:

• raw source immutability;
• git/PR/dry-run workflow;
• protected human sections;
• schema validation;
• low-confidence staging;
• rollback;
• prompt-injection defense;
• sensitive data policy.

6. Plan MVP

A good MVP usually includes:

• Markdown output;
• source preservation;
• index.md and log.md;
• one ingest command;
• one query command;
• one lint report;
• git diff review;
• frontmatter schema;
• no vector DB until there is a measured retrieval problem.

Output

## Product/workflow thesis

## Build-vs-buy justification

## Architecture

## Data model

## Ingest/query/lint flows

## Trust model

## Storage and retrieval choices

## MVP milestones

## Risks

## Open questions

Safety gates

• Do not start with graph visualization as the core deliverable.
• Do not hide generated memory in a black box if users need trust.
• Do not recommend current dependency versions or licenses without browsing.
• Do not design direct-write team systems without review ownership.