Wiki Creator Knowledge Base Manager

What It Solves

When documents, meeting notes, or design specs are handed to an LLM, answers often come from ad-hoc fragments: no stable source, repeated concepts scattered, and conflicts silently overwritten. wiki-creator turns this into an auditable local Wiki: raw/ is read-only, the LLM only reads it and compiles pages like pages/<topic>/<slug>.md, each page has a two-sentence summary, claims cite source file and section, and conflicts are written to .conflicts.md for human resolution.

How It Works

It does not rely on vector search. Instead, it treats each complete page as a knowledge unit and uses a two-level index as a symbol table: read index.md to locate topics, then topics/*.md to locate pages, then read the selected page; [[kebab-case-slug]] links support multi-hop reasoning. Core flow:
- First creation: init_wiki.py builds the skeleton, parse_raw.py parses raw/, and the LLM drafts the SCHEMA.md topic list for user review.
- Compilation and indexing: diff.py lists new files, entities are extracted and pages are created, and build_index.py generates the index, backlinks, graph, and manifest.
- Query and health check: queries follow index.md → topics/*.md → pages only, without loading the whole context; lint.py checks isolated pages, dangling links, unsourced claims, and oversized topics.
Updates process only new/changed files via merge, ref-only, or conflict branches; new topics require user confirmation before SCHEMA.md is changed.

Boundaries

It suits project knowledge, product docs, architecture notes, and other scenarios where stable provenance matters. In coding assistants, it defaults to project .wiki-creator/; office agents can use global ~/.wiki-creator/, or override with --root. Do not split one Wiki across roots; keep topic merges, SCHEMA.md changes, and conflict resolution under user control rather than automatic LLM rewriting.