Most projects that need documentation already exist. Nobody is starting fresh with a docs plan; there’s a repository with a few years of code in it, a README that describes the first month, and a new hire starting on Monday. “Automatic documentation” is what people search for at that point, and the phrase covers three quite different tools.

Three things called automatic documentation

API reference generators. JSDoc, TypeDoc, Sphinx autodoc, rustdoc, Javadoc. They read signatures and doc comments and print them as HTML. They are accurate, because they print exactly what’s in the source, and they answer one question well: what does this function take and return? They can’t tell a reader where to start, how a request travels through the system, or why the queue exists. If the comments are missing, so is the page.

AI chat over the code. Point a model at the repository and ask questions. It’s good for the person asking, at the moment they ask. Nothing is written down, the next person asks again, and nobody can check yesterday’s answer against today’s code.

Generated guides. A tool reads the codebase and writes the prose a person would have written: getting started, how it works, the main flows, onboarding, troubleshooting. This is the gap most teams actually have, and it’s where Wiki Pilot sits. The risk is obvious: generated prose that sounds right and isn’t. So the useful question about any tool in this category is how you find out when a page is wrong.

What a generated guide has to get right

Readable isn’t enough. A page that a reviewer can’t check is a page nobody will trust after the first mistake. Three things make one checkable:

  • It names its sources. Each page lists the files it describes. A reviewer opens those files, not the whole repo.
  • It records when it was true. A commit hash per page. When any listed file changes after that commit, the page is suspect, and a script can say which pages.
  • Its examples come from the code. Snippets copied from real files, diagrams drawn from calls the agent actually traced. Invented examples are where generated docs go wrong first.

Wiki Pilot writes all three into each page’s frontmatter. That’s the reason it exists, more than the generating.

A run, start to finish

From the root of the repository:

npx wikipilot init

This needs no API key and sends nothing anywhere. It scans the repo (package files, routes, folders, config, the README) and drafts a sectioned wiki into ./wiki: start here, getting started, guides, onboarding, how it works, technologies, cookbook, FAQ, troubleshooting, and reference. The draft is structure and facts the scanner could confirm, so it’s thin, but it’s correctly shaped.

For the full text, add the AI pass:

npx wikipilot init --ai                       # Anthropic API key
npx wikipilot init --ai --engine claude-code  # your Claude Pro or Max plan
npx wikipilot init --ai --provider openai     # or gemini, or any OpenAI-compatible model

The agent works out what the product is and who uses it, traces the main flow, then rewrites every page from what it read. If a wikipilot.md brief sits at the repo root, it follows that too: who the wiki is for, which sections to write, which sites it may screenshot.

Then build and look:

npx wikipilot build
npx wikipilot serve

The output is a static site, with search, dark and light themes, and Mermaid diagrams, that you can put on GitHub Pages, Cloudflare Pages, Netlify, or an S3 bucket.

Which pages to review first

If you only have time to review a few generated pages properly, review these, in order:

  1. Getting started. The commands to run the project locally. Run them on a clean machine. This page is either right or useless.
  2. How it works. The one-request-through-the-system walkthrough. It’s the page new developers read most and the one where a wrong arrow costs the most.
  3. Onboarding. From clone to a first merged change. Have the next new hire follow it and fix what they trip on.

Reference pages matter less than people expect. Developers read the code for that.

Keeping it true

The part that decides whether automatic documentation was worth it happens a month later. init also installs an update-wiki skill for Claude Code. Ask it to sync the wiki and it diffs each page’s sources against the commit the page recorded, patches the pages it can confirm, and marks the rest stale: true, which shows readers a “may be outdated” banner. Those marked pages are the only ones someone needs to reread. The guide covers the commands and CI setup, and what belongs in a codebase wiki argues for each of the ten sections.