Generation from your code
`claudux update` drafts a full VitePress docs site straight from your source, so you start from a real draft instead of an empty folder.
Draft a docs site from your code with Claude or Codex, keep unrelated source paths outside the write boundary, and opt into manifest-owned section updates when you need tighter control.
# latest main
curl -fsSL https://raw.githubusercontent.com/firstbitelabsllc/claudux/main/install.sh | sh
# pin the current release
curl -fsSL https://raw.githubusercontent.com/firstbitelabsllc/claudux/v2.0.7/install.sh | CLAUDUX_REF=v2.0.7 shcd your-project
claudux update # generate or update the VitePress docs
claudux serve # preview at http://localhost:5173Run claudux with no arguments for an interactive menu.
Anyone can ask a model to write docs now. The hard part is making the write boundary explicit: which paths the backend may edit, which sections code will accept, and which failures stop the checkpoint.
claudux separates two trust levels. Default generation lets the backend write documentation paths but rejects and restores unrelated source mutations. A committed manifest goes further: the backend becomes read-only and code applies only validated section patches.
One command drives the pipeline, but the write boundary depends on whether the repository has a manifest.
--strict makes unresolved link failures fatal.| Command | Purpose |
|---|---|
claudux | Interactive menu (adapts to project state) |
claudux update | Generate or update docs, enforce write boundaries, and validate local links |
claudux update -m "..." | Update with a focused directive |
claudux serve | Start dev server at localhost:5173 |
claudux check | Environment diagnostics |
claudux --version | Show installed version |
claudux --help | Show help and usage |
claudux supports multiple AI backends. Claude is the default; Codex is available as an alternative via the CLAUDUX_BACKEND environment variable.
# Default -- uses Claude
claudux update
# Use Codex instead
CLAUDUX_BACKEND=codex claudux update