/llm-wiki

name: llm-wiki
description: Build and maintain a persistent markdown wiki from raw sources using incremental ingest, indexed pages, and append-only logging.
user-invocable: true
metadata:
  hybridclaw:
    category: memory
    short_description: Persistent markdown wiki.
    tags:
      - wiki
      - knowledge-base
      - research
      - markdown
    related_skills:
      - pdf
      - notion

LLM Wiki

Use this skill when the user wants a persistent knowledge base that compounds over time instead of answering from raw documents from scratch on every turn.

Core Model

Treat the wiki as three layers:

• `raw/` is the immutable source collection. Read from it; do not edit or

rewrite it during normal maintenance.

• `wiki/` is the maintained knowledge layer. This is where summaries, entity

pages, concept pages, and durable analyses live.

• `AGENTS.md`, `index.md`, and `log.md` define and track the system:

`AGENTS.md` is the schema and workflow contract, `index.md` is the catalog, and `log.md` is the append-only timeline.

This is not a one-shot note dump. The goal is to integrate new information into existing pages, preserve cross-references, and keep the wiki internally coherent as the source set grows.

Resolve The Wiki Root

Use this order:

1. a HybridAI knowledge collection, when the `knowledge_*` tools are available and the knowledge is meant for the company, a team, or other agents (see "Platform Collection Mode" below) 2. a user-specified wiki root 3. an already-structured repo or vault containing `raw/`, `wiki/`, `index.md`, and `log.md` 4. a confirmed markdown vault or notes repo chosen by the user 5. the current workspace only if the user explicitly wants the wiki here

Do not assume the current workspace is the wiki root just because it contains Markdown files. Do not start a Git repository or a local folder for knowledge the user wants to share when a platform collection is available.

If the target is an Obsidian vault, also follow `skills/obsidian/SKILL.md`.

Platform Collection Mode

When the HybridAI tools `knowledge_list`, `knowledge_read`, `knowledge_write` and `knowledge_search` are available (hosted agents have them; a local install with a HybridAI API key gets them through the same gateway; they appear as `hybridai__knowledge_*`), the wiki can live as a **knowledge collection on the HybridAI platform**. `knowledge_create_collection` is only needed when no suitable collection exists and the user wants one created. The platform keeps the pages, renders the index and the log, indexes every section for search, and applies the company's roles. Other agents and people in the company read the same collection in the HybridAI app.

Prefer this mode whenever the user talks about company knowledge, a shared wiki, or anything the team should see. A folder wiki is for one user's local notes.

The same model applies, with these differences:

• **Root.** A collection. `knowledge_list` without arguments lists the

collections you can access; `knowledge_list` with a collection lists its pages. Pick the collection the user means, or ask. Creating one needs `knowledge_create_collection` (company admin or owner).

• **Layout.** No `wiki/` prefix. Pages live directly under `sources/`,

`entities/`, `concepts/` and `analyses/`; the folder sets the page type. `AGENTS.md` is a page you read and write like any other.

• **`raw/` is not writable.** Sources are ingested by the platform, not by

you. When the user hands you a document, read it and write its source summary page under `sources/`; cite it in `sources:` frontmatter. Do not try to store the original anywhere.

• **`index.md` and `log.md` are generated.** The platform renders them from

the pages' frontmatter and revisions. Read them to orient; never write them. Every `knowledge_write` with a `reason` is the log entry.

• **Writes are check-and-set.** `knowledge_read` returns a `content_hash`;

pass it as `expected_hash` when overwriting. Omit it only to create a page. On a conflict the tool returns the current hash: read again and retry once.

• **Search is a tool, not grep.** `knowledge_search` returns page sections

as `path#anchor` with a snippet. Use it before creating anything and when answering; follow up with `knowledge_read` for the full page. Cite as `path#anchor`.

• **Frontmatter.** The index is rendered from `title`, `type`, `tags` and a

one-line `summary`, so always set `summary`. The platform sets `created` and `updated` from revisions; you may omit them.

• **Links.** Wikilinks are `[[entities/acme]]` without `wiki/` and without

`.md`.

The workflows below are written for the folder layout. In collection mode read them through this mapping, which overrides any file step:

• `wiki/<family>/page.md` means the page `<family>/page.md` in the collection.
• "create the layout" or "seed starter files" means nothing: a collection has

its families from the start, and the schema page is one page among the others, `AGENTS.md` included.

• "capture into `raw/`" means: read the source and write its summary page

under `sources/`; the original is not stored by you.

• "update `index.md`" and "append to `log.md`" mean: give the

`knowledge_write` a one-line `reason`; both files are rendered from that.

• "search across `wiki/**/*.md`" means `knowledge_search`.

Workflow mapping:

• Orient: `knowledge_read` `AGENTS.md` (if present), `index.md`, `log.md`.
• Ingest: read the source, `knowledge_search` for related pages, create or

update pages with `knowledge_write` and a one-line `reason`.

• Query: `knowledge_search`, read the pages, answer with `path#anchor`

citations; save a durable answer under `analyses/`.

• Lint: compare `index.md` against the pages and fix through writes; the

platform reports stale and orphaned pages in a later version.

Orient Every Session

When the user already has a wiki, always orient yourself before acting:

1. Read `AGENTS.md` first to