Project Wiki

The Project Wiki is your project’s knowledge, kept as concepts — Lanterns, the Lore of Aldoria, the matchmaker’s configuration — and drawn as a navigable knowledge graph inside the editor. Each concept is one Markdown file in the folder your wiki lives in (the “vault”); the selected one opens in a reader beside the pan/zoom canvas. A document is how a concept reaches somebody outside the wiki, so documents come in by import and go out by export.

Opening it

The wiki is a full-panel overlay, reached the same way the Integrations view is — from the panel’s / slash menu → Project Wiki. A back button in the top-left corner returns you to the chat. Opening it on a project with no docs folder yet leaves an empty view and creates nothing.

The vault it reads defaults to your configured agent working directory — the tree your docs live in. The derived index is written under the project’s .kumo/local/ area; it is regenerated from the vault, never hand-maintained, and never part of your docs.

The graph

Each node is a concept. Edges are the links between them, of two kinds:

• Authored links — a [[wiki-style link]] you wrote in a note. These always show.
• Glossary auto-links — connections the wiki infers from shared terminology across your notes, without you linking anything by hand. These can be toggled off when you want only the links you authored.

Drag a node to pull the graph around; the layout settles with a force simulation. Pan and zoom the canvas freely. Selecting a node loads it into the reader and recenters the view on it.

Views

The View menu in the wiki’s search bar picks what the canvas shows:

• Concepts — the graph above, and what the wiki opens on.
• Documents — the documents you imported, as a folder list instead of a graph; opening one shows it whole, with the concepts cut out of it in place.
• People — your studio’s members, grouped by the roles and teams your studio gives them.

Everything is a concept

A note you write is a concept. A document you import becomes a concept too — one that embeds the concepts cut out of it, one per named section and per dated entry of a chronicle — so a large design doc is a node of its own and a cluster of connected concept nodes beside it. Definitions and recurring names in the prose are still found for you and drawn as suggested concepts.

Importing documents

The folder button in the wiki’s search bar imports a document from:

• Files on this computer — Markdown, text, Word and PDF;
• Obsidian, Confluence, Notion, Google Drive and SharePoint, once connected in Integrations.

Pick a document and the wiki shows the plan before it writes anything: the concepts it will become, and where the original is kept. Nothing is lost — the wiki checks that the concepts give the document back exactly, character for character, and refuses the import otherwise. The original file is kept under .kumo-sources/ beside them, so what Markdown cannot carry (a Word file’s styles, a PDF’s layout) is still there. Importing the same document twice is refused with the name of the concept that already holds it.

Exporting a concept

Export in the reader writes a concept — with every concept it embeds, in place — as one document: a file in any format the wiki can create (.md, .docx, …), a Confluence or Notion page, a Google Doc, or a Word file in a SharePoint library. Exported back to the format it was imported from, a concept starts from its kept original, so the styles and layout come back out untouched.

Your project, on the same map

The wiki doesn’t stop at prose. It draws your project’s own files and assets — Blueprints, levels, source files — right beside the notes that talk about them: GA_WingedForm next to the ability’s design note, GameplaySkill.h next to the architecture doc that names it. This is on by default; one slash-menu toggle hides it when you want to read only the writing.

A second toggle adds the #include dependencies between those files, turning the map into something you can walk as a codebase. It is off by default — while you are reading the documents, the code is context rather than subject.

It respects version control

The reader will not print the contents of a file your project keeps out of version control. Rather than guessing at secret filenames, the rule is exact: an ignored file might still hold a secret, so its body is held back; a committed one is already shared, so it is shown.

The reader

Selecting a node opens its body in the reader pane. Below the text, connection chips list the note’s links and backlinks — click one to jump the whole view to that note, highlighting the term that connects them and scrolling to it. Hovering a chip previews where that reference is mentioned in the note you’re on.

Search and categories

A search field at the bottom filters the canvas to matching notes and highlights every match in the reader — including inside fenced code blocks. Alongside it, category chips filter the graph to a topic (design, systems, art, and so on); categories, search, and the toggles all compose, so you can narrow to “systems notes mentioning dash” in a couple of clicks.

It stays in sync by itself

There is no manual “re-index” step. When you open the wiki it regenerates the index from the vault, then watches that folder: add, edit, or delete a note and the canvas refreshes on its own. In the editor the work happens on a background process so the UI never stalls; in headless/automation runs it happens inline.

Opening the real thing

Double-click a node to open what it stands for. An asset opens in its own Unreal asset editor — double-clicking a Blueprint opens the Blueprint editor, because nothing else would do. Anything else opens in whatever application your OS uses for that kind of file: a .docx design doc in Word, a .h in your code editor. The path shown under the reader’s title reveals the file in Explorer / Finder.

Adding a page

The + button creates a new empty markdown page in the vault, re-indexes, and opens it ready to write — so a thought you have while reading the graph becomes a note without leaving the panel.