LLM Knowledge Base Runtime

Problem

When source material arrives as raw files, PDFs, images, and structured data, direct chat-style answering can lose provenance, repeat summaries, and let wiki structure decay. This skill targets a Vault managed by the LLM Knowledge Bases runtime. The goal is not only to answer once, but to turn each meaningful interaction into retrievable, traceable, and maintainable wiki notes.

How It Works

• Clear runtime boundary: the runtime owns Vault I/O; the agent handles understanding, synthesis, linking, and deciding which wiki/sources/, wiki/concepts/, wiki/entities/, or wiki/syntheses/ pages should be added or improved.
• Tool-mediated access: reads and writes go through kb_* tools such as kb_status, kb_read_raw, kb_search, kb_read_notes, kb_upsert_source_note, and kb_rebuild_indexes, rather than direct file edits under raw/, wiki/, or .llm-kb/representations/.
• Asset compilation: text and structured data use the source compile path; PDFs and images use a representation-first path, filling in native_text, ocr_text, or vision_notes before compiling a source note.
• Grounded answering: search first with kb_search, cite only notes that were read, file query-specific answers as output archives, and promote reusable knowledge into concept, entity, or synthesis pages.
• Maintenance loop: use kb_lint to surface placeholder titles, stale links, manifest drift, and missing representations, then apply narrow repairs through kb_repair_source_ids and kb_rebuild_indexes.

Boundaries

It fits ongoing curation of source notes, book reviews, and topic pages. It is not a general one-off Q&A layer. Prefer small, high-confidence batches, verify evidence before creating derived pages, and avoid expanding vague continuation requests into large rewrites.