OpenWiki: A CLI for Generating and Maintaining Agent-Readable Code Documentation

What OpenWiki Produces and Who Should Use It

AI coding agents have no memory between sessions. Each conversation starts without any knowledge of the codebase the agent is working in, so engineers end up re-explaining architecture, naming conventions, and module responsibilities every time they open a new chat. OpenWiki addresses that gap by generating a linked Markdown wiki in an openwiki/ directory at the root of the repository. The wiki is written once and updated incrementally, so agents always have a starting reference.

The tool is built for teams that already use one of the supported coding agents: Codex, Claude Code, OpenCode, Cursor, IBM Bob, Bob Shell, Kiro, Oh My Pi, or Antigravity. The README describes OpenWiki as most effective when used inside these agents because they supply the authenticated model session and access to repository files without any additional configuration. The same Markdown pages the agent reads are also human-readable, so engineers can browse the generated wiki alongside their codebase.

OpenWiki also supports standalone use for personal knowledge bases (referred to in the documentation as personal brains) and for scheduling automated updates via CI pipelines. The examples/ directory in the repository includes workflow files for GitHub Actions, GitLab CI, and Bitbucket Pipelines.

The Claim-Based Architecture and Evidence Tracking

The central design principle in OpenWiki is what the documentation calls Claims: factual statements about the codebase that are each tied back to a specific source in the repository. When the source code changes, Claims pointing to that evidence can be identified and reviewed rather than left silently stale. This makes incremental updates meaningful: OpenWiki knows which facts have been confirmed, which are under revision, and which have been retracted.

The generation lifecycle runs as a sequence of MCP tool calls. The coding agent begins with openwiki_begin, submits a wiki plan with openwiki_submit_plan, processes each page through openwiki_next_page and openwiki_submit_page, and finalizes with openwiki_finish. At any point, openwiki_inspect_page_claims is available to review the Claims state of a specific page.

The host agent submits sparse Claim decisions for each page: explicit confirmations, revisions, additions, or retractions. OpenWiki retains all unaffected Claims from prior runs and refuses to finish until the final state is durable on disk. Completed pages survive interruptions, so a generation run that is cancelled or rate-limited can be resumed without losing work. The documentation describes this behavior as resumable updates with grounded Claims.

Parallel page workers are available when running OpenWiki as a standalone CLI rather than through a coding agent. The CLI can document multiple pages concurrently, saving progress page by page and adapting to provider rate limits. Host-driven (agent-integrated) runs process pages sequentially because the agent drives the cycle.

Installing OpenWiki and Connecting a Coding Agent

OpenWiki requires Node.js 22.22.0 or newer. On Windows, the README notes that using bun as the package manager may fall back to compiling the better-sqlite3 native dependency from source, which requires Visual Studio Build Tools with the Desktop development with C++ workload. The npm-based install avoids that complication:

npm install -g openwiki

After installing, connect it to the coding agent you already use. The following example connects it to Claude Code:

openwiki integrations install claude

The integration installs at user level by default, which means it applies to every Git repository on the machine. To scope an installation to a specific repository, add the --project flag. Use openwiki integrations list to check the current status of all integrations, and openwiki integrations uninstall to remove one.

Once the integration is installed, restart the coding agent, open a repository, and ask:

Initialize this repository's OpenWiki from the current source and tests.

The agent investigates the repository, plans the wiki, and writes each assigned page to openwiki/. Pages are saved as each one completes, so the directory fills incrementally rather than all at once after a long wait.

Searching, Linking, and Exploring the Generated Wiki

Once a wiki exists, coding agents access it through two MCP tools. The openwiki_search tool returns compact, ranked results for a natural-language question. The openwiki_read tool retrieves the complete text of sections the agent selects. Both tools are local, read-only, and model-free: they do not trigger a new generation run or make any model calls of their own.

OpenWiki also supports visual exploration. The publishable visualizer renders the wiki as an interactive graph, showing how pages link to each other. This is useful for understanding the structure of a large wiki without reading every page.

When a project spans multiple repositories, openwiki link groups them into a workspace. The openwiki_list_workspaces and openwiki_list_wikis tools provide discovery across linked wikis, and openwiki_search operates across the full workspace. This is relevant for monorepos that have been split or for service architectures where a backend repository and a shared library repository each have their own wiki.

Output can be exported in OKF v0.2 (Open Knowledge Format), a portable format documented in the repository. This makes it possible to consume the wiki outside of OpenWiki's own tooling if needed.

Where OpenWiki Does Not Apply

Host-driven generation through a coding agent currently supports only repository code wikis. Personal brains and connector-sourced context, including LangSmith, are not available when the agent is driving the cycle. For personal brains, the standalone CLI is necessary.

The tool does not replace inline code comments, architecture decision records, or human-written explanations in a README. If a repository is lightly commented or relies on implicit conventions that are never stated anywhere in source, tests, or docs, the generated wiki will reflect those gaps rather than fill them. OpenWiki researches what is present in the repository; it does not synthesize information that is not there.

The Windows installation path adds a real obstacle for teams that standardize on bun. The compilation of better-sqlite3 from source requires a specific Visual Studio workload, and a missing dependency there produces an error that is not immediately obvious to engineers unfamiliar with C++ toolchains on Windows.

Integration with Visual Studio Code is not listed in the README's supported agents table. Engineers who use VS Code's built-in chat or a VS Code-based agent not on the supported list cannot use the host-driven integration path and would have to rely on the standalone CLI.

OpenWiki Against a Static Documentation Approach

The obvious alternative is a team wiki in Confluence, Notion, or a plain Markdown directory maintained by hand. The difference is that manually maintained wikis drift: when an engineer renames a module or replaces a library, there is no mechanism that connects the changed code to the affected documentation page. OpenWiki's Claims model ties each fact to a specific source location, so a code change can be traced to the Claims that may need revision.

Another common approach is to document a codebase in the README alone. This works for small projects but breaks down when the README grows beyond a few screens or when different engineers need to find answers to different questions. OpenWiki produces multiple linked pages organized by topic, which makes a large codebase navigable for agents and for human readers alike.

Neither approach is free of cost. OpenWiki requires an ongoing model budget to generate and update pages. The README does not document pricing, but generation runs involve LLM calls through the coding agent's authenticated session. Manual documentation is free at the point of writing but accumulates an invisible maintenance debt as the code changes.

Maintenance, Licensing, and the OpenWiki Protocol

The repository published v0.6.0 on 2026-09-23, with the last push on 2026-09-26. Prior releases v0.5.2 and v0.5.1 landed on 2026-09-15 and 2026-09-10, indicating a rapid release cadence. The project uses changesets for versioning and pnpm for the monorepo workspace.

The package is MIT-licensed, which permits use in commercial projects without restriction. The OKF v0.2 output format is also documented in the repository and intended as a portable standard; the README describes it as openly specified.

The integration for each coding agent installs configuration files at host-specific locations documented in the README. For example, the Claude Code integration writes to the .claude/ directory, while the Kiro integration uses ~/.kiro/skills and ~/.kiro/settings/mcp.json. These paths matter for teams that manage dotfile configuration in a shared repository or that enforce a clean home directory policy.

Editorial conclusion

Teams using Claude Code, Codex, or Cursor on repositories with more than a handful of contributors benefit most from OpenWiki. A solo project with a single active maintainer has little to gain. Before running a first generation, confirm that Node.js 22.22.0 or newer is present by running node --version, and verify the integration is registered by running openwiki integrations list after the install step.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes