Technical Doc Generator

Technical Documentation Generator

Scan a codebase and generate client-deliverable technical documentation. Produces API docs, READMEs, architecture overviews, changelogs, and developer onboarding guides.

How to Use

/technical-doc-generator ./src api-docs /technical-doc-generator . full /technical-doc-generator ./src readme /technical-doc-generator . changelog /technical-doc-generator ./src onboarding $ARGUMENTS[0] = Path to codebase (default: current directory) $ARGUMENTS[1] = Doc type: api-docs, readme, architecture, changelog, onboarding, full (all)

readme — Project README

• Scan the project and generate a comprehensive README:
• # Project Name
• Brief description (1-2 sentences from package.json, pyproject.toml, or code analysis).
• ## Features
• [Auto-detected from code structure]
• ## Quick Start
• ### Prerequisites
• [Detected from package.json, requirements.txt, go.mod, etc.]
• ### Installation
• [Generated from detected package manager and config files]
• ### Configuration
• [Detected from .env.example, config files, environment variables in code]
• ### Usage
• [Basic usage examples from entry points, CLI args, or main functions]
• ## Project Structure
• [Generated directory tree with descriptions]
• ## API Reference
• [Brief overview with link to full docs if generated]
• ## Contributing
• [Standard contributing section]
• ## License
• [Detected from LICENSE file]

api-docs — API Documentation

Scan for API endpoints and generate documentation: Detect the framework: Express, FastAPI, Django, Flask, Rails, Spring, Gin, etc. Extract endpoints: Routes, methods, parameters, request/response bodies Generate OpenAPI/Swagger spec (YAML) Generate human-readable docs (Markdown) For each endpoint: ### `POST /api/users` Create a new user account. **Authentication**: Required (Bearer token) **Request Body**: | Field | Type | Required | Description | |-------|------|----------|-------------| | email | string | Yes | User's email address | | name | string | Yes | Full name | | role | string | No | User role (default: "member") | **Example Request**: ```json { "email": "user@example.com", "name": "Jane Doe", "role": "admin" } Response (201 Created): { "id": "usr_abc123", "email": "user@example.com", "name": "Jane Doe", "role": "admin", "created_at": "2026-02-13T10:00:00Z" } Error Responses: StatusDescription400Invalid request body409Email already exists401Missing or invalid auth token ### `architecture` — Architecture Overview Generate an architecture document with: 1. **System overview**: What the system does, high-level description 2. **Technology stack**: Languages, frameworks, databases, services detected 3. **Directory structure**: Annotated tree with purpose of each directory 4. **Component diagram**: Mermaid diagram showing major components and their relationships 5. **Data flow**: How data moves through the system 6. **Database schema**: If migrations or models are found, document the schema 7. **External dependencies**: Third-party services, APIs, databases 8. **Configuration**: Environment variables and their purposes Mermaid diagram example: ```mermaid graph TB Client[Client App] --> API[API Server] API --> Auth[Auth Service] API --> DB[(PostgreSQL)] API --> Cache[(Redis)] API --> Queue[Job Queue] Queue --> Worker[Background Worker] Worker --> DB Worker --> Email[Email Service]

changelog — Changelog from Git History

• Parse git log and generate a structured changelog:
• # Changelog
• ## [Unreleased]
• ### Added
• [Features from commits since last tag]
• ### Changed
• [Modifications]
• ### Fixed
• [Bug fixes]
• ## [1.2.0] - 2026-02-10
• ### Added
• ...
• Rules:
• Group by semantic version tags (or by month if no tags)
• Categorize commits: Added, Changed, Fixed, Removed, Security, Deprecated
• Parse conventional commits if used (feat:, fix:, chore:, etc.)
• Skip merge commits and build/CI commits
• Link to PRs/issues if references found in commit messages

onboarding — Developer Onboarding Guide

Generate a guide for new developers joining the project: # Developer Onboarding Guide ## Prerequisites [Required software, versions, accounts] ## Getting Started ### 1. Clone and Setup [Step-by-step with exact commands] ### 2. Environment Configuration [All env vars explained with example values] ### 3. Run Locally [Commands to start the dev server, run tests, etc.] ### 4. Verify Setup [How to confirm everything is working] ## Codebase Tour ### Architecture Overview [Brief system description with diagram] ### Key Directories [What lives where and why] ### Important Files [Config files, entry points, key modules] ## Development Workflow ### Branching Strategy [Detected from git history or standard gitflow] ### Running Tests [Test commands, test structure] ### Code Style [Linting config, formatting tools detected] ### Making Changes [Typical workflow: branch → code → test → PR] ## Common Tasks ### Add a new API endpoint [Step-by-step based on existing patterns] ### Add a database migration [Based on detected ORM/migration tool] ### Deploy [If deployment config is detected] ## Troubleshooting ### Common Issues [Based on README, issues, or common patterns]

full — Complete Documentation Package

Generate ALL of the above, organized in a docs/ directory: docs/ README.md # Project README (also copy to project root if none exists) API.md # API documentation ARCHITECTURE.md # Architecture overview CHANGELOG.md # Changelog ONBOARDING.md # Developer onboarding openapi.yaml # OpenAPI spec (if API detected) diagrams/ # Mermaid source files

Codebase Scanning Strategy

Package files first: package.json, pyproject.toml, go.mod, Cargo.toml, Gemfile, pom.xml Config files: .env.example, docker-compose.yml, CI/CD configs Entry points: main.*, index.*, app.*, server.* Route/endpoint files: Files containing route definitions Models/schemas: Database models, TypeScript interfaces, Pydantic models Test files: To understand expected behavior Existing docs: Any existing README, docs/, wiki content Do NOT read every file. Be strategic — scan structure first, then dive into key files.

Output

Save all generated docs to output/docs/ (or docs/ if specified). Present a summary of what was generated and suggest next steps for the client.