sidleo/llm-wiki

llm-wiki — Agent Knowledge Base in Pure OKF v0.2 Markdown

English · 简体中文

An open-source, generic, agent-first knowledge base: the format layer strictly follows the Open Knowledge Format v0.2, and the operations layer follows Karpathy's llm-wiki pattern (ingest / query / lint + index / log). It ships in four consumption forms that share one core library and one data bundle.

Design Principles

1. Strictly OKF v0.2 — the official spec is the single source of truth for the format; no custom frontmatter fields, no magic features at the consumption layer.
2. Generic and vendor-neutral — not tied to any business or domain; the same bundle is readable and writable by any agent.

Features

• Progressive disclosure — every session carries injected tool guidance plus the active bundle/category list; wiki_list shows the whole tree first, then you search and drill in.
• Real cross-links + automatic backlinks — concepts reference each other with Markdown links; reading a concept automatically surfaces the pitfalls and rules that cite it.
• Directory-level rules (AGENTS.md) — per-directory write gates (which concept types need human confirmation) and behavioral conventions, resolved bottom-up with child directories overriding parents.
• Per-directory prompt injection (APPEND_SYSTEM_PROMPT.md) — each category defines its own behavior rules; identical content across all five forms and effective immediately after an edit. DSH rides a constant section plus a runtime-context snapshot; the pi extension hooks before_agent_start to re-read them every turn and append them to that turn's system prompt; the Codex plugin injects them through SessionStart / UserPromptSubmit hooks (no duplicate injection when unchanged, refresh next turn, rebuild after compaction); the MCP server sends the same text through the initialize instructions field (the protocol only delivers it once per connection — reconnect or call wiki rules after an edit); the skill/CLI form has no injection hook, so it uses wiki rules (no args = load every rule verbatim) plus rules automatically appended to wiki get/create/update responses — the rules travel with the data, so nothing depends on the agent remembering to load them. See SPEC-EXTENSIONS.md.
• Lifecycle — stale_after expiry, status: deprecated (concept-level) and directory-level deprecation, auto-maintained index.md / log.md.
• Validation & health — wiki_validate (OKF compliance) and wiki_lint (broken links, orphans, stale entries, missing index).
• Multiple bundles — register several wiki directories as named bundles and switch between them (session-level or persisted globally).
• Online knowledge base (two backends) — one wiki_sync / wiki sync entry point, dispatched by the bundle's backend:
  • Local directory + Git remote: commit → fetch/merge → push for multi-machine collaboration; force-push is never used.
  • Feishu cloud drive: the bundle lives in a Feishu Drive folder as a tree of native .md files (zero OKF format loss), read and written file-by-file through lark-cli; humans browse/download in Feishu, agents do the reading and writing. Both backends share one conflict policy: index.md is regenerated locally, log.md is merged as a union (never blocks), and a concept / AGENTS.md changed on both sides stops the sync with a conflict list — nothing is auto-overwritten. The Feishu backend never deletes files on either side (deletions are only reported).
• Graphical configuration (DSH Web GUI) — an llm-wiki card under Settings → Plugins → Plugin configuration: named directories (add/rename/remove/set default), Git remote status with one-click sync/init/clone, and a health panel (validate/lint counts + rebuild index). Runtime parameters are deployment-level (the profile's cordis.patch.yml) and are deliberately not editable from the card.