Open source · MIT licensed

Generate a documentation wiki from your codebase.

Point Wiki Pilot at a repo. It reads what's actually there and drafts a sectioned wiki — then records which source files every page was built from, so you can tell which pages have fallen behind the code.

Get started
Public repo on GitHub — go read the source if you don't believe any of this.
terminal — ~/my-project
pagebilling/refunds.md
sourcessrc/billing/refunds.ts
last_synced2026-04-02
statusstale
Week one

Someone writes the page the week the feature ships. Then the feature keeps changing for two years.

No signal

Nothing on the page says whether it still matches the code.

Found late

Usually by whoever followed the instructions into a broken deploy, and then asked in Slack anyway.

Why now

Code moves faster than anyone writes it down.

An afternoon with a coding agent can touch more files than a team used to change in a sprint. Nobody decides to let a page go out of date — documentation drift happens between one merge and the next, and by the time anyone notices, the page has been wrong for a month.

Wiki Pilot makes that measurable instead of hoping. Each page names the paths it covers and the commit and release it was last checked against. Rewrite a service overnight and every page describing it flags itself on the next build — so reviewing what the agent changed is a list you work through, not an excavation.

# Monday git log --oneline -1 a1b2c3d refactor billing to the new adapter # the wiki, on the next build billing/refunds.md may be outdated billing/invoices.md may be outdated 6 other pages unchanged — nothing to review
How it works

From repo to published wiki, in four steps.

01

Pick a type

wikipilot init asks who the wiki is for: technical, user guide, or both (the default). Your answer decides which sections get drafted.

02

Investigate

A draft lands instantly from the README and manifest. With an API key, an AI agent — Claude, OpenAI, or Gemini, your pick — then digs through the source itself and rewrites the pages from what the code actually does, including a user-flow diagram and an onboarding path for whoever joins the team next.

03

Build

One folder of static files. Host it wherever you already host things.

04

Resync

Edit the code and the pages built from those files start showing a "may be outdated" banner. The bundled Claude Code skill can then rewrite them against the current source.

Live examples

Real wikis, generated from repos you know.

Each of these was generated from the project's public repository — drafted by the CLI, rewritten by an AI investigation of the source, and not hand-edited afterwards. Open one and poke around — the navigation, search, and diagrams are all standard output.

Independent demonstrations of Wiki Pilot output. Not affiliated with or endorsed by the Express, Zod, or Hono projects.

Features

What you get in the box.

Freshness contract

Change a file the page depends on and the rendered page grows a banner at the top: may be outdated, verified at commit abc1234. The next person hears it from the wiki instead of from you.

An agent that reads the code

Add an API key and init goes past the README: an agent lists, greps, and traces its way through the repo, then writes the pages from what it found — snippets copied out of real files, diagrams that follow actual call paths. Runs on Claude out of the box; --provider switches it to OpenAI, Gemini, or your own endpoint. Without a key you still get the mechanical draft.

A skill that maintains it

init writes a Claude Code skill into your repo. Ask it to update the wiki and it re-reads the changed files, rewrites the affected prose, and re-stamps the pages it was sure about. The ones it wasn't sure about get flagged rather than guessed.

An onboarding section for new hires

Technical wikis open their dev-facing half with onboarding: environment setup using the repo's own scripts, a tour of where things live, and a suggested first change. The investigation agent isn't allowed to finish without writing it.

Static output, search included

Put the output folder in a bucket, a Pages project, or behind your VPN — there's no process to keep alive, and full-text search runs in the browser against a prebuilt index. The one optional exception is the ask-the-wiki assistant: a separate server, grounded in the wiki's own pages, that says so when something isn't documented instead of producing a confident guess.

The freshness contract

Three fields in the frontmatter do all the work.

sources — glob patterns, as narrow as you can make them.

last_synced — a commit SHA. Diffing it against HEAD is the whole detection mechanism.

stale — a boolean anyone can set by hand when they know a page is wrong but can't fix it yet.

It's plain YAML in a Markdown file. Nothing stops you writing it by hand, and nothing breaks if you do.

--- sources: [src/billing/refunds.ts] last_synced: 2026-04-02 stale: true --- # Refund handling > This page hasn't been regenerated since > src/billing/refunds.ts last changed. > Treat it as unverified.

The CLI is MIT licensed and stays that way.

Everything on this page works without an account, a key, or a subscription. The hosted tier is the only thing anyone pays for.

Pricing

Start free. Upgrade when hosting gets old.

Free

The open-source CLI, self-hosted.

$0forever
Get started
Coming soon

Pro

Skip the hosting. Skip the API key too.

$20/mo
Join the waitlist
Coming soon

Team

For teams tracking more than one repo.

$40/mo
Join the waitlist

Try it on a repo you already know.

You'll know within five minutes whether the pages it drafts are worth keeping. That's the whole evaluation.