OpenWiki is a CLI that writes and maintains agent documentation for your codebase.
OpenWiki is a CLI that writes and maintains agent documentation for your codebase.
OpenWiki is a CLI that writes and maintains a wiki for your codebase or your personal knowledge. An agent reads your sources, synthesizes a linked Markdown wiki you own, and keeps it current on every change. It is built for agents to read as memory, and it ships an interactive visualizer for humans to explore.
OpenWiki gives you:
code wiki for a repository, or a personal wiki for your own knowledge.begin → submit_plan → next_page → submit_page → … → finish, with a durable ordered page queue, focused per-page workers, strict Claims persistence, per-page source checkpoints, and partial-progress PRs for ephemeral CI. See OpenWiki architecture for the full flow.Install the CLI (Node.js 22 or newer):
npm install -g openwiki
Generate a wiki for the current repository. The first run walks you through picking a provider, key, and model, then writes docs to openwiki/:
openwiki --init
Running openwiki --init again replaces the existing generated repository wiki and Claims with a brand-new generation while preserving the user-authored openwiki/INSTRUCTIONS.md brief. On a persistent checkout, OpenWiki records in-progress repository generation in openwiki/.run.json, so rerunning the same command after an interruption resumes the durable page queue. Ephemeral CI runners start fresh after failure unless their workspace is preserved. A setup failure before the new run state is durable restores the previous wiki.
Update an existing wiki from repository changes since its last successful run and any stale Claims:
openwiki --update
Keep it current automatically by adding a scheduled CI job that opens a docs PR whenever the wiki changes:
openwiki-update.yml into .github/workflows/openwiki-update.yml.openwiki-update.gitlab-ci.yml into .gitlab-ci.yml or include it from your pipeline.openwiki-update.bitbucket-pipelines.yml into bitbucket-pipelines.yml, then schedule the openwiki-update pipeline.[!NOTE] On Windows, install with a Node.js package manager (
npm install -g openwikiorpnpm add -g openwiki). Installing withbuncan fall back to compiling thebetter-sqlite3native dependency, which needs Visual Studio Build Tools with the Desktop development with C++ workload.
Repository generation is an ordered queue of independently durable page jobs. openwiki/.run.json checkpoints the active run and its progress. A page advances only after its Markdown, Claims, verification, and openwiki/.page-manifest.json entry are durable, preserving completed work and page-specific source baselines across interruptions and future runs.
OpenWiki can run inside an existing coding agent instead of launching its own model. The coding agent investigates the repository, plans the wiki, and writes each assigned page sequentially with its native repository tools. OpenWiki provides the durable MCP page-job lifecycle, validates each completion, and deterministically finalizes Claims, indexes, provenance, setup files, and metadata.
Install the integration for your coding agent (choose one):
openwiki integrations install codex
openwiki integrations install claude
openwiki integrations install opencode
openwiki integrations install cursor
The supported targets are Codex, Claude Code, OpenCode, and Cursor. All install at user level by default, so one installation works from any Git repository. Project paths are resolved to their Git repository root. User-level OpenCode integrations live under ~/.config/opencode, OpenCode's global configuration directory on every supported platform. Restart the coding agent after installation, open the repository, and ask:
Initialize this repository's OpenWiki from the current source and tests.
For an existing wiki, ask:
Update this repository's OpenWiki for changes since its last successful run.
Host-driven runs currently support repository code wikis, not personal brains. They use the coding agent's authenticated model session, so OpenWiki provider credentials are not required. OpenWiki owns the durable queue, Claims validation and persistence, source-drift handling, and deterministic finalization; the coding agent owns repository research, planning, and factual authoring.
External coding-agent integrations currently use repository source and tests only. Connector-sourced context, including LangSmith, is not yet supported.
The integration exposes the native generation lifecycle through openwiki_begin, openwiki_submit_plan, openwiki_next_page, optional on-demand openwiki_inspect_page_claims, openwiki_submit_page, and openwiki_finish. Codex, Claude, OpenCode, or Cursor submits only sparse Claim decisions for each page; OpenWiki automatically retains current unaffected Claims, applies explicit confirmations, revisions, additions, or retractions, and refuses to finish until the final state is durable.
Use openwiki integrations list to inspect user-level installation status or openwiki integrations uninstall <host> to remove an integration safely. Add --project [path] to list, install, or uninstall for repository-scoped state.
Contributors adding another coding agent should follow Adding a coding-agent integration.
OpenWiki makes code wikis self-correcting by tracking the material propositions behind factual pages—not just when a Markdown file was last generated. Claims cover the truths future agents rely on: behavior, responsibilities, architecture, data flow, invariants, failure semantics, configuration, and security boundaries. Each one points to exact repository evidence such as repo://src/server.ts#L40-L82, with the evidence version OpenWiki observed when the claim was established.
Before an update, OpenWiki checks every persisted evidence version, before even deciding whether the repository is a no-op. A stale or unresolved Claim requires work for its owning page even if the planner omits it. The page worker receives only Claims requiring attention; current issue-free Claims are retained deterministically without being repeated through every model turn. The worker explicitly confirms rechecked issue Claims, submits only revisions and additions, and names retractions. Complete current Claims remain available through on-demand inspection for broad rewrites. The Markdown stays clean; structured Claim state lives alongside it under openwiki/.claims/.
Page completion is a durability boundary. OpenWiki persists the reconciled Claims, projects verification, synchronizes the sidecar's page version, and proves the complete result before marking that page's job complete. Finalization repeats the whole-run proof before deleting openwiki/.run.json.
Grounded Claims currently apply to repository code wikis and repository evidence. Connector-derived facts, including LangSmith-only observations, are not claimed.
OpenWiki runs in one of two modes. Bare openwiki, openwiki --init, and openwiki --update default to code mode; add the personal positional (or --mode personal) for the personal brain.
openwiki/ in the repo
openwiki --init
Personal
Your connected sources
~/.openwiki/wiki
openwiki personal --init
By default the CLI stays open after a run so you can send follow-up messages. Add -p / --print for a one-shot, non-interactive run that prints the final output and exits. --init and --update auto-exit on success in an interactive terminal, so the same command works one-shot or interactively.
OpenWiki stores local credentials, the personal wiki, connector data, conversation history, and skills under ~/.openwiki by default. Set OPENWIKI_CONFIG_DIR before starting OpenWiki to use a different writable directory, such as a mounted container volume:
OPENWIKI_CONFIG_DIR=/data/openwiki openwiki personal --init
The override selects a separate state directory; OpenWiki does not move or delete an existing ~/.openwiki directory. Copy any state you want to preserve yourself, and point the variable at a dedicated directory because OpenWiki restricts its permissions for the current user.
Turn any wiki into an interactive node graph with a live, side-by-side Markdown reader:
openwiki visualize
This serves ./openwiki on a local loopback address (127.0.0.1, never exposed on the network) and opens your browser to the graph. Edits to the wiki files are picked up automatically while the server runs. Pass a path to visualize a different directory, --port <port> to choose the port (it increments on conflict; default 4321), and --no-open to leave the browser alone:
openwiki visualize openwiki --port 4400 --no-open
To publish the visualizer beside generated documentation, export a static directory instead of starting the server:
openwiki visualize openwiki --export docs/openwiki-visualizer
The export contains index.html, client.js, client-lib.js, styles.css, and graph.json. Its client reads the sibling graph file and does not use live reload, so the directory can be hosted by GitHub Pages, MkDocs, or any other static host. --export cannot be combined with --port or --no-open.
[!NOTE] The page loads its graph, Markdown, and diagram libraries from a public CDN, so an internet connection is required for both local and static viewers.
In personal mode, OpenWi