Auto-generated wiki

The wiki is repowise's documentation layer. An LLM writes a Markdown page for every module and every notable file at index time — then keeps them current incrementally on every commit. Pages cite the source ranges they're describing, get a confidence score, and are re-generated only when the underlying code changes meaningfully.

Incremental update flow

What gets written

Three page types:

• File pages — one per source file (skipping fixtures, tests if configured, and tiny files). Documents structure, key symbols, imports, and intent.
• Module pages — one per directory or logical cluster. Documents architecture, child files, and entry points.
• Symbol spotlights — for high-importance symbols (high PageRank, many callers). Documents purpose and usage.

What goes into the prompt

The LLM doesn't just see source. It sees:

• The file's parsed structure (classes, functions, signatures).
• Its imports and what imports it.
• Its top callers and callees with confidence scores.
• The 10 most significant commit messages from its history (filtered of merges, dependency bumps, lint runs).
• Ownership and trend signals.
• Cross-references to existing wiki pages it should link to.

That's the recipe for documentation that explains why, not just what.

Citations

Every page references the source ranges it's describing. The MCP get_context tool can pull the cited source back when the agent needs to verify.

Confidence and freshness

Each page carries a confidence_score and a freshness_status. The score reflects how well the underlying source maps to what the page claims. Pages drift over time as code changes; freshness is how recently the page was regenerated relative to the file's last meaningful change. Both surface through get_context(include=["freshness"]) — and they're included by default for exactly this reason.

Incremental regeneration

repowise update finds the files changed since the last sync, walks the dependency graph to find affected wiki pages, and regenerates only those. A typical single-commit update touches 3–10 pages and finishes in under 30 seconds.

There's a cascade-budget knob that caps how many pages a single update may regenerate (auto-scaled if unset) — useful for very large refactor commits where you'd otherwise regenerate hundreds of pages.

Search

The wiki is indexed two ways:

• SQLite FTS — exact keyword search.
• LanceDB vector store — semantic search via embeddings (Voyage by default; OpenAI / Gemini also supported).

Both feed search_codebase and get_answer.

When the LLM is gated

For free-tier and air-gapped use, repowise init --index-only skips LLM generation entirely. You still get hotspots, ownership, dead code, the dependency graph, and decision archaeology — just not the wiki pages. You can layer wiki generation on later by re-running repowise init without --index-only.