Introduction
"The self-maintaining wiki. Built for agents, explored by humans."
This is article #199 in the "One Open Source Project a Day" series. Today's project is OpenWiki — LangChain AI's open-source CLI for automatic codebase documentation generation and maintenance, 15,600 Stars, MIT license.
OpenWiki addresses a problem every engineering team has: written documentation goes stale, but undocumented codebases leave AI agents disoriented. OpenWiki's solution: let an agent write the docs, let an agent maintain them. The output is a Markdown wiki that lives in your repository — agents can read it as memory, and humans can explore it through an interactive visualization.
What You'll Learn
- Two modes: the difference between a
codewiki (for a repository) and apersonalwiki (for personal knowledge) - Grounded Claims: how material facts are tracked back to exact code lines
- Coding-agent integrations with Claude Code, Codex, and OpenCode
- Support for 13 model providers and 9 knowledge-source connectors
- Interactive node-graph visualization and static site export
- CI auto-update (GitHub Actions / GitLab CI / Bitbucket Pipelines)
Prerequisites
- Basic command-line experience
- Familiarity with LLM APIs (API keys, model names)
- Git workflow basics are helpful
Project Background
Overview
OpenWiki is built on Deep Agents, LangChain's deep agent framework. It's not a "generate once and forget" documentation tool — it's a documentation lifecycle management system:
- Initialize: the agent reads source code and generates a structured Markdown wiki
- Track: binds each material fact (Grounded Claims) to precise code lines
- Update: when code changes, checks which facts' "evidence" changed and rewrites only affected pages
- Integrate: maintains
AGENTS.mdandCLAUDE.mdat the repo root so coding agents can find and read the wiki
Author / Team
- Organization: LangChain AI
- Primary language: TypeScript
- License: MIT
- Created: 2026-06-22
Project Stats
- ⭐ GitHub Stars: 15,600+
- 🍴 Forks: 1,133+
- 📄 License: MIT
- 📅 Created: 2026-06-22
Quick Start
Installation
# Requires Node.js 22 or newer
npm install -g openwikiGenerate a Wiki for the Current Repository
cd your-project
openwiki --initThe first run walks you through selecting a model provider (default: OpenAI + gpt-5.6-terra), entering your API key, and choosing a model. Documentation is written to openwiki/.
Update an Existing Wiki
# Detect code changes, update only affected pages
openwiki --updateLaunch the Visualizer
# Open an interactive node graph in your browser
openwiki visualizeTwo Modes
| Mode | Documents | Writes to | Command |
|---|---|---|---|
| code (default) | Current repository source | openwiki/ (inside the repo) | openwiki --init |
| personal | Connected sources (Notion/Gmail/Slack, etc.) | ~/.openwiki/wiki/ | openwiki personal --init |
Code mode is built for teams: the wiki is committed alongside code, CI keeps it current, and AGENTS.md + CLAUDE.md give coding agents a direct entry point to the documentation.
Personal mode is built for individuals: aggregates knowledge scattered across tools (Notion, email, X/Twitter, Hacker News…) into a local wiki that an AI agent structures into a knowledge graph.
Core Mechanism: Grounded Claims
This is what sets OpenWiki apart from ordinary documentation generators.
A typical documentation tool only tracks "when was this page last generated." OpenWiki goes further: it tracks every material fact in the documentation, down to the exact source lines that back it up.
// A Claim's structure (stored under openwiki/.claims/)
{
id: "claim-abc123",
proposition: "AuthMiddleware returns 401 on failure without rethrowing",
evidence: "repo://src/middleware/auth.ts#L40-L82",
evidence_version: "git-sha-of-that-commit"
}Claims cover:
- Function and module behavior and responsibilities
- Architectural relationships and data flows
- Invariants and failure semantics
- Configuration requirements and security boundaries
Before an update, OpenWiki checks the evidence for every Claim before even deciding whether anything needs regenerating:
openwiki --update execution order:
1. Check whether each Claim's evidence (to exact line numbers) has changed
2. If evidence changed → that page needs rewriting, regardless of how much code changed
3. If evidence unchanged → the page's content probably doesn't need updating
4. After a page completes, Claims are atomically persisted (no partial updates)This handles a subtle correctness problem: lots of code can change while a key fact stays correct, or a small refactor can silently invalidate a documented invariant. Line-level evidence tracking makes update decisions much more precise.
Resumable Page-Job Architecture
OpenWiki's generation flow is not a single monolithic batch — it's a stateful page queue:
begin → submit_plan → next_page → submit_page → ... → finishbegin: starts a new generation run, records run state toopenwiki/.run.jsonsubmit_plan: submits the page plan (which topics need documentation)next_page/submit_page: works page by page, atomically persisting Claims on each completionfinish: final verification, deletes.run.json, marks the run complete
Resumability: if generation is interrupted mid-run (e.g., CI timeout), rerunning on the same checkout picks up where it left off without redoing completed pages.
CI note: ephemeral CI runners that start fresh on every run don't retain .run.json after failure, so a failed run restarts from the beginning. Resume capability only works on persistent checkouts.
Coding-Agent Integrations: Let Claude Code Write the Docs
OpenWiki can run inside Claude Code, Codex, or OpenCode, delegating repository research and writing to the coding agent while OpenWiki manages the Claims lifecycle and persistence.
# Install the integration for your coding agent
openwiki integrations install claude
openwiki integrations install codex
openwiki integrations install opencodeAfter installation, restart the coding agent, open the repository, and ask:
Initialize this repository's OpenWiki from the current source and tests.Or to update an existing wiki:
Update this repository's OpenWiki for changes since its last successful run.The integration exposes five operations: openwiki_begin, openwiki_submit_plan, openwiki_next_page, openwiki_submit_page, and openwiki_finish. The coding agent submits a complete intended Claim set with each page; OpenWiki internally creates, updates, preserves, and retracts Claims — and refuses to call finish until the final state is fully durable.
The advantage of this integration: it uses the coding agent's already-authenticated model session, so separate OpenWiki provider credentials are not required.
9 Knowledge-Source Connectors (personal mode)
| Connector | Source | Auth |
|---|---|---|
custom-mcp | Any HTTP/stdio MCP server | MCP config |
git-repo | Local git repositories | None |
notion | Notion pages | OAuth (hosted MCP) |
gmail | Gmail | Google OAuth |
slack | Slack conversations | Slack OAuth |
x | X/Twitter timeline, bookmarks | X OAuth 2.0 (PKCE) |
web-search | Web search via Tavily | TAVILY_API_KEY |
hackernews | HN feed + search APIs | None |
langsmith | LangSmith run traces | OPENWIKI_LANGSMITH_API_KEY |
The LangSmith connector is an exception: it's for code mode, not personal. It pulls recent LangSmith traces (tool calls, outcomes, latency) for chosen projects and injects that runtime context into the codebase wiki — so documentation reflects how the code actually behaves at runtime, not just what the source says.
The same connector can be configured multiple times as separate instances (e.g., two Web Search sources: one tracking AI research, another tracking NBA news), stored as web-search-1 and web-search-2.
13 Model Providers
| Provider | Credential |
|---|---|
| OpenAI (default) | OPENAI_API_KEY |
| OpenAI (ChatGPT login) | Browser OAuth, uses ChatGPT plan |
| Anthropic | ANTHROPIC_API_KEY |
| Gemini (AI Studio) | GEMINI_API_KEY |
| Gemini Enterprise (Vertex AI) | Google ADC, keyless |
| AWS Bedrock | IAM credentials |
| GitHub Copilot | GitHub CLI session |
| OpenRouter | OPENROUTER_API_KEY |
| Nebius / Fireworks / Baseten / NVIDIA NIM | Provider API key |
| OpenAI-compatible (LiteLLM/Ollama/LM Studio) | Base URL + key |
Local model example with Ollama:
OPENWIKI_PROVIDER=openai-compatible
OPENAI_COMPATIBLE_API_KEY=ollama
OPENAI_COMPATIBLE_BASE_URL=http://localhost:11434/v1
OPENWIKI_MODEL_ID=llama3.2Interactive Visualization
# Open an interactive node graph in your local browser
openwiki visualize
# Export as a static site (GitHub Pages, MkDocs, etc.)
openwiki visualize openwiki --export docs/openwiki-visualizerThe visualization is a live node graph + Markdown reader side by side: nodes are wiki pages, edges are links between them, clicking a node loads that page in the reader on the right.
The static export contains index.html, client.js, styles.css, and graph.json — deploy directly to any static host.
CI Auto-Update
Copy the example workflow file into your repository:
# .github/workflows/openwiki-update.yml
# Runs on a schedule, checks for code changes,
# opens a documentation PR if the wiki needs updatingOfficial examples for GitHub Actions, GitLab CI, and Bitbucket Pipelines are all in the examples/ directory. The auto-update flow: detect changes → update wiki → open a PR. It doesn't merge automatically — the documentation change stays in a PR for human review.
Your Wiki Stays Yours
OpenWiki's core design principle: your documentation belongs to you.
- The wiki is plain Markdown files committed in your repository — no external service dependency
openwiki/INSTRUCTIONS.mdis user-authored; normal update runs never overwrite it- OpenWiki only touches its own block (
<!-- OPENWIKI:START -->…<!-- OPENWIKI:END -->) insideAGENTS.mdandCLAUDE.md, leaving the rest untouched - Claims files live in
openwiki/.claims/, versioned alongside Markdown in git history - No-op runs don't churn docs — only
.last-update.jsonis updated, page content is left alone
Resources
- 🌟 GitHub: langchain-ai/openwiki
- 📦 npm: openwiki
- 🔧 Deep Agents: langchain-ai/deepagentsjs
- 📋 OKF spec: Open Knowledge Format v0.2
Summary
OpenWiki represents a different way of thinking about documentation engineering: the documentation quality problem isn't that the writing is bad — it's that nothing maintains what was written.
Three things worth noting:
Grounded Claims is the key innovation. Traditional documentation tools have "last updated" timestamps at the page level. OpenWiki takes granularity down to "proposition + code line": each fact knows which lines are its evidence, and when those lines change, the system knows exactly what to rewrite. This transforms updates from "regenerate the whole file" to "only rewrite the propositions whose evidence changed" — far more precise.
Using a coding agent as a writer, not a Q&A tool. OpenWiki's Claude Code/Codex integration puts the coding agent in the role of "repository researcher and documentation author," not a one-shot text generator. The agent has full repository access, works through a page queue incrementally, persists each result, and the whole process is resumable.
The OKF format is a bet on interoperability. Emitting Google Open Knowledge Format v0.2 means the wiki isn't locked to this tool — any OKF-aware system can read it. This is an explicit anti-vendor-lock-in design choice.
If you're building an AI-native engineering team and need living documentation that automatically tracks code changes, OpenWiki is the most complete open-source solution available today.
Explore PrimeSkills — a curated marketplace of AI agents and skills, each validated against real enterprise workflows. No hype, just what actually works.
Visit my personal site for more insights and interesting products.