Generate project documentation from codebase analysis — ARCHITECTURE.md, API_ENDPOINTS.md, DATABASE_SCHEMA.md. Reads source code, schema files, routes, and config to produce accurate, structured docs. Use when starting a project, onboarding contributors, or when docs are missing or stale. Triggers:

Project Documentation Generator Generate structured project documentation by analysing the codebase. Produces docs that reflect the actual code , not aspirational architecture. When to Use New project needs initial documentation Docs are missing or stale Onboarding someone to the codebase Post refactor doc refresh Workflow 1. Detect Project Type Scan the project root to determine what kind of project this is: Indicator Project Type wrangler.jsonc / wrangler.toml Cloudflare Worker vite.config.ts + src/App.tsx React SPA astro.config.mjs Astro site next.config.js Next.js app package.json with hono Hono API src/index.ts with Hono API server drizzle.config.ts Has database layer schema.ts or schema/ Has database schema pyproject.toml / setup.py Python project Cargo.toml Rust project 2. Ask What to Generate Only offer docs that match the project. Don't offer API ENDPOINTS.md for a static site. Don't offer DATABASE SCHEMA.md if there's no database. 3. Scan the Codebase For each requested doc, read the relevant source files: ARCHITECTURE.md — scan: package.json / pyproject.toml (stack, dependencies) Entry points ( src/index.ts , src/main.tsx , src/App.tsx ) Config files ( wrangler.jsonc , vite.config.ts , tsconfig.json ) Directory structure (top 2 levels) Key modules and their exports API ENDPOINTS.md — scan: Route files ( src/routes/ , src/api/ , or inline in index) Middleware files (auth, CORS, logging) Request/response types or Zod schemas Error handling patterns DATABASE SCHEMA.md — scan: Drizzle schema files ( src/db/schema.ts , src/schema/ ) Migration files ( drizzle/ , migrations/ ) Raw SQL files if present Seed files if present 4. Generate Documentation Write each doc to docs/ (create the directory if it doesn't exist). If the project already has docs there, offer to update rather than overwrite. For small projects with no docs/ directory, write to the project root instead. Document Templates ARCHITECTURE.md API ENDPOINTS.md DATABASE SCHEMA.md Quality Rules 1. Document what exists, not what's planned — read the actual code, don't invent endpoints or tables 2. Include versions — extract from package.json/lock files, not from memory 3. Show real response shapes — copy from TypeScript types or Zod schemas in the code 4. Keep it scannable — tables over paragraphs, code blocks over prose 5. Don't duplicate CLAUDE.md — if architecture info is already in CLAUDE.md, either move it to ARCHITECTURE.md or reference it 6. Flag gaps — if you find undocumented routes or tables without clear purpose, note them with <! TODO: document purpose Updating Existing Docs If docs already exist: 1. Read the existing doc 2. Diff against the current codebase 3. Show the user what's changed (new endpoints, removed tables, updated stack) 4. Apply updates preserving any hand written notes or sections Never silently overwrite custom content the user has added to their docs.

project-docs