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.
Someone writes the page the week the feature ships. Then the feature keeps changing for two years.
Nothing on the page says whether it still matches the code.
Usually by whoever followed the instructions into a broken deploy, and then asked in Slack anyway.
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 — it 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.
From repo to published wiki, in four steps.
Pick a type
wikipilot init asks one question: technical wiki, user guide, or both. Your answer decides which sections get drafted.
Scan
It reads the README, the package manifest, and the directory tree, then writes real starter pages. No config file, no annotations in your code.
Build
One folder of static files. Host it wherever you already host things.
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.
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.
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.
Diagrams and real code
Mermaid renders from fenced blocks — flowcharts, sequence diagrams, ER models. Snippets can be captioned with the file they were copied from, which is also how the sync pass knows what to re-read.
Ask-the-wiki assistant
Grounded in the wiki's own pages. Ask it something nobody documented and it tells you that, instead of producing a confident guess.
Full-text search
Runs in the browser against a prebuilt index. No search server, no round-trip.
Static output
Put the output folder in a bucket, a Pages project, or behind your VPN. Nothing needs to keep running. The assistant is the one optional exception, and it's a separate process you point the site at.
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.
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.
Start free. Upgrade when hosting gets old.
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.