Guide

Get a live wiki from your repo in five minutes.

Install the CLI, draft a wiki from the repository you're standing in, build it to static HTML, preview it. Four commands, and the only step that wants an API key is the one you can skip.

Install

Nothing to install if you just want to try it — run it straight from npm, in the root of any repo:

$ npx wikipilot init

For repeat use, install it globally. Needs Node.js 18 or newer, and nothing else — no config file, no account. An API key is optional; it unlocks the AI pass described below.

$ npm install -g wikipilot

Prefer to run the unreleased version, or hack on it? Build from source:

$ git clone https://github.com/guymoyal/wikipilot $ cd wikipilot && npm install && npm run build $ npm link # now the wikipilot command runs from ./dist

Initialize

Run this from the root of the repo you want documented. It asks who the wiki is for, then drafts real pages from your repo's own content — no blank templates to fill in.

$ wikipilot init What kind of wiki should this be? 1) Everything Technical and user guide together — both audiences, one wiki. 2) Technical For people working on this codebase — architecture, dependencies, internals. 3) User guide For people using what it produces — install, guides, FAQ, troubleshooting.

Your answer decides which sections get drafted:

  • Everything (the default) — all ten sections, ordered so the pages a newcomer needs come before the ones you look things up in: start-here, getting-started, guides, onboarding, how-it-works, technologies, cookbook, faq, troubleshooting, reference
  • Technicalstart-here, onboarding, how-it-works, technologies, reference, cookbook
  • User guidestart-here, getting-started, guides, faq, troubleshooting

The choice is saved to wikipilot.config.json, so later builds and the sync skill both know what belongs in this wiki.

  • --preset <technical|user-guide|all> — answer up front and skip the question
  • -y, --yes — take the default (both audiences); use this in CI
  • -o, --out <dir> — where to scaffold the wiki (default ./wiki)
  • --no-skill — skip scaffolding the Claude Code sync skill

The prompt only appears on an interactive terminal. Piped or non-TTY runs take the default instead of hanging, so wikipilot init is safe to put in a script.

The AI deep investigation

After drafting, init asks two more questions: whether to run the deep-investigation pass, and which provider should do it — Anthropic (the default, claude-sonnet-5), OpenAI, Gemini, or a custom OpenAI-compatible endpoint. Say yes and the agent lists, reads, and greps your repository, traces the main flow through the code, then rewrites the drafted pages. The overview leads with what the product does and who it's for; how-it-works gets architecture and user-flow diagrams in Mermaid; dependency pages cite the code that imports them; snippets are copied from real files and captioned with their paths. Technical wikis also gain an onboarding section that takes a new developer from clean checkout to a first change. Budget a few minutes for a mid-size repo.

No key for the provider you picked — ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, or WIKI_INIT_API_KEY for custom — in your environment or the repo's .env? The wizard prompts for one with input hidden, and can save it to .env — which it keeps gitignored. In scripts and CI the pass runs only when you pass --ai with a key present; --no-ai skips it entirely. --provider and --base-url pin the provider and endpoint, and --model picks the model (WIKI_INIT_MODEL also works, but only for the default Claude provider). If the pass fails partway, the drafted wiki is untouched on disk.

Spend is bounded regardless of repo size — capped turns, a fixed read budget, and a prompt-cached conversation — and the run prints its token count with an estimated cost when it finishes. A mid-size repo comes in at low single-digit dollars on the default model; --model claude-haiku-4-5-20251001 is the budget option.

Build & serve

The defaults line up with what init wrote, so both commands take no arguments:

$ wikipilot build # ./wiki → ./wiki-dist $ wikipilot serve # http://localhost:4400

The site is named after your project — @acme/billing-service becomes "Billing Service" — and --site-name overrides it. The output is plain HTML, CSS, and JS: search, theme toggle, and Mermaid diagrams all work with no server-side code, so you can host it anywhere.

Ask-the-wiki assistant

Run a small local API that grounds a chat widget in your wiki's own content only.

$ export ANTHROPIC_API_KEY=sk-... $ wikipilot agent --port 4402

Pass --agent-port 4402 to wikipilot build and the built site's chat widget will call it automatically. If the API lives somewhere else — a Worker, a container, another domain — use --agent-url https://api.example.com/api/chat instead. The wiki itself stays static either way; the assistant is the only part that talks to a server, and the API key never leaves it.

Deploy

Today: host the wiki-dist/ output anywhere that serves static files — GitHub Pages, S3, your own nginx box. Soon: skip that step entirely.

# coming with Pro — not live yet $ wikipilot login $ wikipilot deploy

Join the hosted-wiki waitlist →

Next steps

  • Star the repo and skim the source — it's a plain TypeScript CLI, nothing exotic.
  • Open an issue if a command behaves differently than this guide says — that's a bug in one of us.
  • Wire wikipilot init's scaffolded skill into your normal workflow so the wiki stays synced without a separate chore.
  • Not sure which sections your project actually needs? There's an argument for each of the ten, and a case for starting with fewer.

View source on GitHub