doc-wiki

内容来源:README.md(说明文档) · 原始地址 · 查看安装指南

原始内容

doc-wiki

doc-wiki demo — a living, ecosystem-aware wiki your coding agent reads

60-second demo: media/demo.mp4 · 2-minute product overview: media/product-explainer.mp4 · reproducible benchmark: benchmark/

The LLM Wiki layer for enterprise coding agents.

Your coding agent — Claude Code, Codex, Antigravity, OpenCode, Gemini, Cursor, or Aider — reads an ecosystem-aware wiki of your code (single repo, monolith, or root-of-microservices in submodules) before it touches the diff. One command, /doc-wiki:atlas, documents the whole codebase: per-topic architecture pages, ER diagrams derived from your actual ORM models, a cross-service map generated automatically when it sees more than one service, and cited answers via /doc-wiki:query. Jira / Confluence / GitHub / GitLab / Notion / Linear / AWS / GCP and your DB schemas route in through one connector planner — configure credentials once.

Does the wiki make the agent fix more tickets fully autonomously? We built a hardened benchmark and measured: four configurations, 92 paired runs on OSS repos — no measured lift, and we publish that null in full at benchmark/RESULTS.md. What doc-wiki demonstrably gives you is the artifact: the map, the diagrams, the history, the cited answers — context you and your agent navigate together. The author's ~10%→~50% experience on a private 500k-LOC enterprise codebase is exactly that: one engineer's anecdote, in a regime (ecosystem-heavy enterprise code, human in the loop) the benchmark doesn't reach. Scales down too: a small single-repo project gets the same wiki, leaner.

claude plugin install narailabs/doc-wiki
5-min walkthrough · reproducible benchmark · Apache-2.0 forever

doc-wiki is a tool you run inside your coding agent — Claude Code, Codex, Antigravity, OpenCode, Gemini, Cursor, and Aider all read the same wiki via their standard project-convention files (CLAUDE.md, AGENTS.md, GEMINI.md, etc. — see multi-platform wrappers). Seven /doc-wiki:* slash commands cover the full lifecycle: init (scaffold + onboard), atlas (full-codebase documentation in one pass), ingest, query, lint, edit, and stats. External services are reached through a single planner — gather() from narai-primitives — so you configure credentials once and every command can use them.


Why this exists

Claude Code is shockingly good on clean, small, well-documented codebases. On real-world enterprise codebases — eight years of accumulated patterns, a database schema that drifted from the ORM models three refactors ago, half the answers buried in old Jira tickets, decision rationale stuck in GitHub PR discussions from a year ago — it falls off a cliff. The model can't see what isn't in its context window, and dumping the whole repo is impossible (and useless even when it fits).

Andrej Karpathy named the LLM Wiki pattern in April 2026: a maintained, compounding artifact of distilled knowledge that an LLM reads instead of re-deriving everything from raw sources every time. doc-wiki applies that pattern to enterprise code — and extends it to ingest Jira, Confluence, GitHub, Notion, AWS, GCP, and your ORM/DB schemas, so the wiki carries the whole ecosystem your codebase actually depends on, not just the code.

The output is a structured wiki under docs/<app>-wiki/. Your coding agent reads it (via CLAUDE.md, AGENTS.md, GEMINI.md, or whichever convention your agent uses) before touching code. /doc-wiki:atlas documents an entire codebase in one phased pass; /doc-wiki:ingest keeps it current as the project evolves; /doc-wiki:query returns cited answers synthesised from wiki pages. Seven /doc-wiki:* slash commands cover the lifecycle; external services route through one planner — gather() from narai-primitives — so you configure credentials once and every command can use them. Everything runs inside your existing agent session. No SaaS, no daemon, no telemetry.

Works across seven coding agents — Claude Code, Codex, Antigravity, OpenCode, Gemini, Cursor, and Aider (see multi-platform wrappers). Single-repo monolith, root-of-microservices, or polyglot multi-team — same workflow. See Setup patterns for each. Manifesto: docs/manifesto.md (what "LLM Wiki for enterprise code" means and why the standard should stay Apache 2.0).

Setup patterns

doc-wiki documents the codebase from wherever you run /doc-wiki:atlas. Three patterns cover most of what people actually do:

  • Single repo / monolith. cd <repo> && /doc-wiki:atlas. The wiki lands under docs/<app>-wiki/ and gets committed to the same repo. Works out of the box.

  • Microservices. Create a root repository, add each service repo as a git submodule, and run /doc-wiki:atlas from the root. The wiki indexes every service, sees cross-service dependencies (HTTP clients, queue producers/consumers, shared schemas), and documents how the services relate to each other — not just what each one does internally. Commit the wiki to the root repo. This is one of doc-wiki's biggest strengths: cross-repo architectural context that no single-service indexer can produce.

    mkdir my-org-wiki && cd my-org-wiki && git init
    git submodule add <repo-url-1> services/svc-a
    git submodule add <repo-url-2> services/svc-b
    # ...add the rest of the service repos as submodules
    /doc-wiki:init && /doc-wiki:atlas
    git add docs/ .gitmodules && git commit -m "atlas v1"   # the wiki (incl. wiki.config.yaml) lives under docs/<name>-wiki/
    
  • Polyglot / multi-team. Same as the microservices pattern, with language and team ownership picked up automatically by /doc-wiki:atlas's code-inventory step.

Reproducible benchmark

A hardened SWE-bench-style harness ships in benchmark/ — container-isolated runs with an Anthropic-only egress firewall, sanitized + detainted ticket bodies, training-data contamination floors, and pre-registered test calibration. Design: docs/superpowers/specs/2026-06-10-benchmark-harness-design.md.

The published result is a null, and we ship it in full: across four configurations (vitest and saleor, Sonnet and Opus, including a schema-ticket regime hand-picked to favor the wiki) — 92 valid ticket pairs — the wiki did not improve the agent's autonomous ticket-fix pass rate (baseline 57/92 vs wiki 54/92). The per-regime mechanics (an 88% baseline ceiling on one repo, a 21% floor on the schema set, and a backport-duplicate artifact behind the one positive-looking cell) are analyzed in benchmark/RESULTS.md. What the benchmark does not measure — and where doc-wiki actually lives — is human-in-the-loop work on enterprise codebases with cross-service and external-service context. We make no quantitative claim about that regime until there's a benchmark for it.

Why publish a null against our own tool? Because the alternative — shipping the one favorable-looking cell — is how dev-tool launches lose trust. The harness is the deliverable: re-run it, swap the ticket list, argue with the numbers.

An earlier (V1) run of this benchmark was withdrawn on 2026-06-10: its sessions had unrestricted network access, several curated ticket bodies carried root-cause analysis, and there were no training-data contamination controls — together these inflate both arms, so the numbers were not defensible in either direction. The V1 post-mortem stays in benchmark/ANALYSIS.md.

The "~10% to ~50%" figure mentioned above is the author's measurement on a private 500k-LOC enterprise codebase, not an OSS benchmark — explicitly anecdotal, and from human-in-the-loop use.

Apache 2.0 — forever

doc-wiki is Apache-2.0 licensed and will stay that way. No relicensing, no rug-pull, no "open core" with the good parts behind a paywall. The Terraform → OpenTofu and Redis → Valkey lessons are why enterprise legal teams now check for explicit relicense-risk language — here it is. The release policy — signed tags + GitHub Attestations — and the maintainership contract are documented in docs/governance.md.

What it is good for

  • Generating project documentation from a mix of code, README files, design docs, Jira tickets, Confluence pages, GitHub issues, and (read-only) database schemas.
  • Maintaining a per-repo knowledge base that survives refactors — content-hash drift detection flags pages whose source code has moved.
  • Mapping ORM entities (JPA, SQLAlchemy, Django, Prisma, TypeORM, ActiveRecord, Entity Framework) to live database tables and emitting Mermaid ER diagrams.
  • Keeping CLAUDE.md (and per-submodule CLAUDE.md files) in sync with the wiki.
  • Letting you /doc-wiki:query instead of grep-ing through stale files.

What it is not

  • A standalone server or web app. There is no daemon, no UI, no cloud — it lives in your terminal under Claude Code.
  • A replacement for code comments or upstream documentation. It complements them.
  • A write-back tool for external services. Every connector is read-only; the db connector ships with a policy gate (ALLOW / DENY / ESCALATE / PRESENT_ONLY).

Prerequisites

  • Node 20.10.0 or newer (20.x only). Node 21+ isn't supported because some upstream deps (better-sqlite3, pdfjs-dist) haven't shipped Node-21 binaries, and narai-primitives requires >=20.10.0. Check with node --version; install via nvm install 20 if needed.
  • Claude Code, Codex, Antigravity, OpenCode, Gemini, Cursor, or Aider to invoke the slash commands. doc-wiki ships wrappers for each — see Multi-platform wrappers.
  • Optional: credentials for any external services you want doc-wiki to read from (Jira, Confluence, GitHub, Notion, AWS, GCP, or a database). You can skip these now — /doc-wiki:init Phase 3 (Onboarding) will walk you through them.

Install

From zero to a queryable wiki in ~5 minutes.

1. Scaffold and onboard

/doc-wiki:init

Four-phase flow: creates wiki.config.yaml and directory tree, then walks through onboarding (stack detection, ORM, database, external services, autonomy mode, hooks). On an already-initialized wiki, re-running prompts to re-run onboarding only.

2. Ingest or Atlas

/doc-wiki:ingest README.md                             # single source
/doc-wiki:ingest https://my-org.atlassian.net/PROJ-1   # Jira ticket
/doc-wiki:atlas --dry-run                              # full-codebase plan
/doc-wiki:atlas                                        # full-codebase commit

4. Query

/doc-wiki:query "How does the cache work?"

Returns a cited answer synthesised from wiki pages. Archives to outputs/queries/; promote with /doc-wiki:query --promote last.

Full walkthrough → docs/getting-started.md

From the NarAI marketplace (recommended)

doc-wiki ships as a Claude Code plugin. One-time marketplace setup, then install:

claude plugin marketplace add narailabs/narai-claude-plugins
claude plugin install doc-wiki@narai

After install, the seven /doc-wiki:* slash commands are available in every Claude Code session — no per-project clone, no per-project build.

Direct from GitHub (no marketplace)

claude plugin install narailabs/doc-wiki

From source (contributors only)

git clone https://github.com/narailabs/doc-wiki.git
cd doc-wiki
npm install
npm run build

The TypeScript scripts compile to sibling .js files; the plugin layout under commands/, skills/doc-wiki/, and agents/ is what Claude Code picks up after claude plugin install --local <path>. See CONTRIBUTING.md for the dev loop.

First run

Open the project you want to document in Claude Code. The three-command happy path takes ~5 minutes; you'll have a queryable wiki by the end.

1. Init (scaffold + onboard)

/doc-wiki:init

Creates wiki.config.yaml and the wiki directory tree (defaults to docs/<app-name>-wiki/):

<wiki-root>/
├── wiki.config.yaml
├── wiki/                    # compiled pages live here
├── raw/                     # raw fetched sources (cached)
├── graph/edges.jsonl        # typed relationships
├── log/events.jsonl         # operation event stream
├── outputs/queries/         # archived /doc-wiki:query answers
└── .wiki-cache/             # SHA256 dedup cache

Then runs a four-phase onboarding Q&A that detects and configures the project:

  1. Language / framework — reads package.json, pyproject.toml, go.mod, Cargo.toml, etc.
  2. ORM — scans for entity definitions (Prisma, SQLAlchemy, Django, JPA, TypeORM, ActiveRecord, Entity Framework).
  3. Database — reads docker-compose.yml, .env, ORM config; redacts credentials before showing.
  4. External services — six yes/no questions (Jira, Confluence, GCP, AWS, Notion, GitHub).
  5. Connector access — for every "yes" above, asks one credential question and writes a starter ~/.connectors/config.yaml.
  6. Autonomy mode — pick conservative / balanced / autonomous / auto. Default balanced is right for most cases. See docs/autonomy-modes.md.

Finally, asks whether to kick off /doc-wiki:atlas immediately for a comprehensive first-run sweep.

On an already-initialized wiki, re-running /doc-wiki:init prompts "Wiki already initialized. Re-run onboarding?" and only re-runs the onboarding Q&A above.

For the full anatomy, see docs/wiki-output.md.

2. Wire up your first connector (optional, takes 2 minutes)

If you want to ingest from external services, configure at least one connector. The smallest example uses GitHub via an environment variable.

Edit ~/.connectors/config.yaml (created by onboard) and uncomment the GitHub block:

connectors:
  github:
    enabled: true
    skill: github-agent-connector
    token: env:GITHUB_TOKEN

Set the env var in your shell rc (~/.zshrc, ~/.bashrc):

export GITHUB_TOKEN=ghp_xxx_your_personal_access_token

Reload your shell (or source the rc file). That's it — gather() will lazy-resolve env:GITHUB_TOKEN inside the connector subprocess on every ingest from a github.com URL.

Other credential ref forms work too — keychain:LABEL, file:/abs/path, cloud:aws-secret/<arn>, cloud:gcp-secret/<resource>. See docs/configuration.md § credential reference grammar for all five and docs/connectors.md for the credential block per connector.

If you only ingest local files, skip this step — every connector is opt-in and the example file ships with all of them commented out.

4. Ingest your first source

Pick something small. Your README.md is a natural starting point:

/doc-wiki:ingest README.md

Behind the scenes, doc-wiki runs a 13-step pipeline: SHA256 cache check → security validation → source extraction → entity surface → gather() for related external context → page compilation → Mermaid augmentation → "How to Go Deeper" generation → index/summaries update → event log → crosslink + tag-harmonize.

The result is a compiled wiki page with frontmatter, narrative, optional Mermaid diagrams, and a "How to Go Deeper" footer. A truncated example:

---
title: doc-wiki — Documentation Wiki Generator
type: concept
tags: [documentation, knowledge-base, claude-code, narai-primitives]
sources: [README.md]
created: 2026-05-07
updated: 2026-05-07
quality: 0.78
summary: >
  doc-wiki is a Claude Code plugin that generates and maintains a wiki...
---

# doc-wiki

doc-wiki is a documentation wiki generator that runs entirely inside
Claude Code as skills + agents + TypeScript helpers...

```mermaid
flowchart LR
    src[Source files / URLs] --> ingest[/doc-wiki:ingest/]
    ingest --> wiki[wiki/*.md]
    wiki --> query[/doc-wiki:query/]
```

## How to Go Deeper

- **Live source:** [`README.md`](https://github.com/narailabs/doc-wiki/blob/HEAD/../../README.md)
- **All commands:** see `docs/commands.md`

For the full page anatomy, see docs/wiki-output.md.

5. Ask a question

/doc-wiki:query "what does this project do?"

Returns a synthesized answer with inline citations to wiki pages. The full transcript is archived under wiki/outputs/queries/<timestamp>.md so you can /doc-wiki:query --promote last to turn it into a permanent page later.

After three or four /doc-wiki:ingest (or one /doc-wiki:atlas), /doc-wiki:query becomes the way you look things up — cheaper than re-reading source, more durable than chat history.

Comprehensive bootstrap with /doc-wiki:atlas

If running /doc-wiki:ingest five or ten times by hand feels tedious:

/doc-wiki:atlas --dry-run    # show plan + cost estimate, no writes
/doc-wiki:atlas              # commit

Atlas auto-discovers topics, batches ingest across (topic × facet) pairs, and synthesizes 3–7 global pages (overview.md, integrations.md, deploy.md, etc.). Default --max-cost is $200; override with --max-cost 50 or --scope <topic> for narrower runs. See docs/atlas.md.

Common pitfalls

Symptom Likely cause Fix
npm install fails with EBADENGINE Node 21+ Switch to Node 20 (nvm install 20 && nvm use 20)
Cannot find module '<script>.js' Forgot npm run build after source clone Run npm install && npm run build once
gather() returns empty plan Connector not enabled, env var unset, or source mentions nothing dispatchable Inspect ~/.connectors/config.yaml and verify echo $GITHUB_TOKEN (etc.) is non-empty
/doc-wiki:query returns "no relevant pages" Wiki is too sparse Run a few more /doc-wiki:ingest (or one /doc-wiki:atlas)
npm test shows 5 skipped Live-DB integration tests gated behind TEST_LIVE_* env vars Normal — set the vars only if you need them

Full diagnostics: docs/troubleshooting.md.

What's in the box

  • 7 slash commands/doc-wiki:init, :atlas, :ingest, :query, :lint, :edit, :stats. See docs/commands.md.
  • 3 sub-agentswiki-orm-agent (entity-to-table mapping), wiki-mermaid-agent (deterministic diagram generation), wiki-claude-md-agent (CLAUDE.md maintenance with managed sections).
  • 9 connectors via narai-primitivesdb / github / gitlab / jira / confluence / notion / linear / aws / gcp. Used read-only. Credentials resolved inside the connector subprocess via narai-primitives/credentials (env var / keychain / file / cloud secret).
  • 4 autonomy modesconservative / balanced / autonomous / auto, with per-category overrides for fine-grained control.
  • 18 REST framework profiles — atlas auto-detects HTTP endpoints from Express, FastAPI, Django, Spring, Rails, ASP.NET, and 12 more. Custom profiles via inline YAML.
  • 934 vitest tests (5 skipped, gated behind TEST_LIVE_* env vars).

Documentation

Documentation under docs/ is organized by audience:

Get started

Doc When to read
docs/getting-started.md Step-by-step tutorial — install through maintenance loop
docs/manifesto.md What "LLM Wiki for enterprise code" means and why it's the wedge
docs/doc-wiki-starter.md 65-line drop-in CLAUDE.md taste of the pattern (zero install)
docs/recipes.md Common end-to-end command sequences for typical jobs
docs/wiki-output.md What your wiki looks like after first ingest
docs/faq.md Anticipated common questions

Reference

Doc When to read
docs/commands.md Every /doc-wiki:* command — args, examples
docs/configuration.md wiki.config.yaml and .connectors/config.yaml schemas, credential grammar
docs/connectors.md The 9 built-in connectors and credentials
docs/atlas.md The eight-phase /doc-wiki:atlas walkthrough
docs/autonomy-modes.md When to pick conservative / balanced / autonomous / auto
docs/troubleshooting.md Common failures and fixes

Advanced

Doc When to read
docs/rest-profiles.md Author custom REST profiles for atlas Phase 1b

Contributor reference

Doc When to read
docs/internals/architecture.md Three-layer model, ingest pipeline, invariants
docs/internals/connectors-api.md gather() API, toolkit, error codes, contributing a built-in connector
docs/governance.md License-forever commitment, release process, maintainership, security disclosures
docs/superpowers/specs/2026-06-10-benchmark-harness-design.md Reproducible benchmark methodology (V2)
CONTRIBUTING.md Dev setup, test loop, where things live

Multi-platform wrappers

doc-wiki is primarily a Claude Code project, but the same skill is exposed in every major coding agent via project-convention files:

File Tool(s)
CLAUDE.md Claude Code
AGENTS.md Codex (OpenAI), OpenCode (sst/opencode), Antigravity (CLI fallback)
GEMINI.md Gemini CLI, Antigravity (IDE + CLI primary)
.cursor/rules/doc-wiki.mdc Cursor IDE
.aider/conventions.md Aider

All five files route into the same orchestrator skill. Slash commands work the same; only the prompt UI differs. Seven coding agents covered.

License

doc-wiki is released under the Apache License 2.0.

Contributing

See CONTRIBUTING.md. PRs welcome; please run npm test and npm run typecheck before opening one.

Status

This is a 0.1.x project under active development. Architecture contracts are stable (see docs/internals/architecture.md) but the surface API may evolve.