Deep codebase analyzer that generates comprehensive technical documentation. Reads every source file and produces numbered markdown docs covering architecture, subsystems, APIs, schemas, and configuration.
Analyzes the entire project codebase and generates a complete set of technical documentation as numbered markdown files in docs/project/.
Explore the project structure to build a documentation plan.
List all source files (exclude node_modules, .next, build artifacts, test fixtures):
find . -type f \( -name '*.ts' -o -name '*.tsx' -o -name '*.js' -o -name '*.mjs' -o -name '*.py' -o -name '*.json' \) | grep -v node_modules | grep -v .next | grep -v dist | sort
Read entry points: package.json, CLAUDE.md, README.md, main index files, server entry points
Identify subsystems: Map directories to their purpose. Each major directory or cohesive module becomes a documentation topic.
Check existing docs: If docs/project/ already exists, read them to understand what's documented and what needs updating.
Create documentation plan: A numbered list of XX-topic.md files to generate, targeting 10-20 docs depending on project complexity.
For each planned doc, systematically:
Each doc must follow this structure:
# Topic Title
Introductory paragraph explaining what this subsystem does, where it lives, why it exists.
Source files:
- `path/to/main-file.ts` -- primary implementation
- `path/to/related.ts` -- supporting module
## Section Title
Detailed documentation with:
- Tables for schemas, APIs, configuration, enums, mappings
- Code blocks for key data structures (types, interfaces, SQL)
- Exact values: default values, timeouts, limits, column types
- Source attribution: which file contains what
| Column | Type | Default | Description |
|--------|------|---------|-------------|
| id | TEXT | -- | Primary key |
## Another Section
Continue documenting...
---
Cross-references to related docs: [Related Topic](./XX-related.md)
| Aspect | What to Document |
|---|---|
| Purpose | What does it do, why does it exist |
| Source files | Exact paths to implementation files |
| Data model | DB schemas, types, interfaces with column details |
| API surface | Endpoints, functions, tools, commands with params |
| Configuration | Env vars with defaults, options, feature flags |
| Algorithms | Key logic: scoring, matching, processing flows |
| Error handling | How failures are managed, fallbacks |
| Dependencies | What does this subsystem import/require |
After all docs are generated, create docs/project/README.md:
# Project Name — Technical Documentation
> Version X.Y.Z | Last updated: YYYY-MM-DD
One-paragraph project description.
## Table of Contents
### Category Name
| Document | Description |
|----------|-------------|
| [01 — Title](./01-title.md) | One-line description |
| [02 — Title](./02-title.md) | One-line description |
### Another Category
...
## Quick Links
- **Entry point:** `path/to/main.ts`
- **Config:** `path/to/config`
- **Tests:** `path/to/tests/`
If the project uses Quoth, also generate a condensed quoth-plugin/context/{project}.md or .quoth-context.md in the project root. This file (under 100 lines) contains the essential architecture, subsystem map, and key technical details for session-start injection.
docs/project/01-, 02-, etc. (zero-padded)XX-kebab-case-topic.md./XX-other.md)For large projects, spawn sub-agents to work in parallel:
Give each sub-agent explicit file lists and doc assignments.
When running on a project that already has docs/project/: