Generate comprehensive technical documentation including API docs (OpenAPI/Swagger), code documentation (TypeDoc/Sphinx), documentation sites (Docusaurus/MkDocs), Architecture Decision Records (ADRs), and diagrams (Mermaid/PlantUML). Use when documenting APIs, libraries, systems architecture, or building developer-facing documentation sites.
npx skills add https://github.com/ancoleman/ai-design-components --skill generating-documentation
Generate comprehensive technical documentation across multiple layers: API documentation, code documentation, documentation sites, architecture decisions, and system diagrams.
Use this skill when:
Technical documentation operates at five distinct layers:
Layer 1: API Documentation - OpenAPI specs for REST/GraphQL APIs (Swagger UI, Redoc, Scalar)
Layer 2: Code Documentation - Generated from code comments (TypeDoc, Sphinx, godoc, rustdoc)
Layer 3: Documentation Sites - Comprehensive guides and tutorials (Docusaurus, MkDocs)
Layer 4: Architecture Decisions - ADRs using MADR template format
Layer 5: Diagrams - Visual architecture (Mermaid, PlantUML, D2)
See references/api-documentation.md, references/code-documentation.md, and references/documentation-sites.md for detailed guides.
API for external consumers?
→ Layer 1: API Documentation (OpenAPI + Swagger UI/Redoc)
Code for maintainers?
→ Layer 2: Code Documentation (TypeDoc/Sphinx/godoc/rustdoc)
Comprehensive guides?
→ Layer 3: Documentation Site (Docusaurus/MkDocs)
Architectural decision?
→ Layer 4: ADR (MADR template)
Visual system design?
→ Layer 5: Diagrams (Mermaid/PlantUML/D2)
| Need | Primary Tool | Best For |
|------|-------------|----------|
| Doc Site | Docusaurus | Feature-rich React sites |
| Doc Site | MkDocs Material | Simple Python docs |
| API Docs (Interactive) | Swagger UI | Testing |
| API Docs (Read-Only) | Redoc | Professional design |
| TypeScript | TypeDoc | All TS projects |
| Python | Sphinx | All Python projects |
| Go | godoc | Built-in |
| Rust | rustdoc | Built-in |
| Diagrams | Mermaid | All-purpose |
Create OpenAPI specification:
openapi: 3.1.0
info:
title: User API
version: 1.0.0
servers:
- url: https://api.example.com/v1
paths:
/users/{userId}:
get:
summary: Get a user
parameters:
- name: userId
in: path
required: true
schema:
type: string
responses:
'200':
description: Success
content:
application/json:
schema:
$ref: '#/components/schemas/User'
components:
schemas:
User:
type: object
required: [id, email, name]
properties:
id:
type: string
email:
type: string
format: email
name:
type: string
securitySchemes:
bearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
security:
- bearerAuth: []
Render with Swagger UI, Redoc, or Scalar. See references/api-documentation.md for complete examples and templates/openapi-template.yaml for starter template.
/**
* Calculate the sum of two numbers.
*
* @param a - The first number
* @param b - The second number
* @returns The sum of a and b
*
* @example
* ```typescript
* const result = add(2, 3);
* console.log(result); // 5
* ```
*/
export function add(a: number, b: number): number {
return a + b;
}
Generate docs:
npm install -D typedoc
npx typedoc --entryPoints src/index.ts --out docs
def calculate_total(items: list[dict], tax_rate: float = 0.0) -> float:
"""Calculate the total price including tax.
Args:
items: List of items with 'price' and 'quantity' keys.
tax_rate: Tax rate as decimal (e.g., 0.1 for 10%).
Returns:
Total price including tax.
Example:
>>> items = [{'price': 10, 'quantity': 2}]
>>> calculate_total(items, tax_rate=0.1)
22.0
"""
subtotal = sum(item['price'] * item['quantity'] for item in items)
return subtotal * (1 + tax_rate)
Generate docs:
pip install sphinx sphinx-rtd-theme
sphinx-quickstart docs
cd docs && make html
See references/code-documentation.md for Go and Rust examples.
npx create-docusaurus@latest my-website classic
cd my-website
npm start
Basic config:
// docusaurus.config.js
module.exports = {
title: 'My Project',
url: 'https://docs.example.com',
themeConfig: {
navbar: {
items: [
{type: 'doc', docId: 'intro', label: 'Docs'},
],
},
},
presets: [
['@docusaurus/preset-classic', {
docs: {
sidebarPath: require.resolve('./sidebars.js'),
},
}],
],
};
pip install mkdocs mkdocs-material
mkdocs new my-project
mkdocs serve
Basic config:
# mkdocs.yml
site_name: My Project
theme:
name: material
features:
- navigation.tabs
- search.suggest
plugins:
- search
nav:
- Home: index.md
- Getting Started: getting-started.md
See references/documentation-sites.md for versioning and deployment.
Use MADR template for recording decisions:
# Use PostgreSQL for Primary Database
* Status: accepted
* Deciders: Engineering Team, CTO
* Date: 2025-01-15
## Context and Problem Statement
Application requires relational database with complex queries,
ACID transactions, JSON support, and full-text search.
## Decision Drivers
* Data integrity (ACID compliance)
* Performance (10K+ queries/second)
* Cost (open-source preferred)
* Features (JSONB, full-text search)
## Considered Options
* PostgreSQL
* MySQL
* Amazon Aurora
## Decision Outcome
Chosen "PostgreSQL" for best balance of features and cost.
### Positive Consequences
* Open-source with no licensing costs
* Advanced features (JSONB, full-text search)
* Strong ACID compliance
### Negative Consequences
* Self-hosting requires DevOps investment
* Horizontal scaling requires changes
Copy full template from templates/adr-template.md. See references/adr-guide.md for workflow and examples/adr/0001-database-selection.md for complete example.
Create diagrams with Mermaid:
sequenceDiagram
User->>Frontend: Click "Login"
Frontend->>API: POST /auth/login
API->>Database: Verify credentials
Database-->>API: User found
API-->>Frontend: JWT token
Frontend->>User: Redirect to dashboard
Mermaid renders in GitHub, Docusaurus, and MkDocs. See references/diagram-generation.md for PlantUML and D2 examples.
Design-First:
Pros: Contract before implementation, parallel development
Cons: Spec authoring can be verbose
Code-First:
Pros: Faster development, spec matches code
Cons: Documentation lags behind
Recommendation: Design-first for new APIs, code-first for existing.
Docusaurus integration:
// docusaurus.config.js
plugins: [
['docusaurus-plugin-openapi-docs', {
config: {
api: {
specPath: 'openapi/api.yaml',
outputDir: 'docs/api',
},
},
}],
],
themes: ['docusaurus-theme-openapi-docs'],
See references/api-documentation.md for MkDocs integration.
# .github/workflows/docs.yml
name: Documentation
on:
push:
branches: [main]
jobs:
build-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
- name: Generate API docs
run: npm run docs:api
- name: Generate code docs
run: npm run docs:code
- name: Build site
run: npm run docs:build
- name: Deploy to GitHub Pages
uses: peaceiris/actions-gh-pages@v3
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
publish_dir: ./build
See references/ci-cd-integration.md for validation and versioning.
Write ADRs for:
✅ Technology selection (database, framework, cloud)
✅ Architecture patterns (microservices, event-driven)
✅ Decisions with trade-offs (pros/cons)
✅ Team alignment needed
Don't write ADRs for:
❌ Trivial decisions (naming, formatting)
❌ Easily reversible (config tweaks)
❌ Implementation details (document in code)
See references/adr-guide.md for workflow and examples.
For detailed guides:
references/api-documentation.md - OpenAPI, Swagger UI, Redoc, Scalar, design-first vs code-firstreferences/code-documentation.md - TypeDoc, Sphinx, godoc, rustdoc with examplesreferences/documentation-sites.md - Docusaurus and MkDocs setup, versioning, deploymentreferences/adr-guide.md - MADR template, workflow, when to write ADRsreferences/diagram-generation.md - Mermaid, PlantUML, D2 syntax and integrationreferences/ci-cd-integration.md - Automation, validation, deployment strategiestemplates/adr-template.md - MADR template for Architecture Decision Recordstemplates/openapi-template.yaml - OpenAPI 3.1 specification starterexamples/openapi/ - Complete OpenAPI specificationsexamples/typescript/ - TypeDoc configuration and TSDoc examplesexamples/python/ - Sphinx configuration and docstring examplesexamples/adr/ - Real-world Architecture Decision Recordsexamples/diagrams/ - Mermaid, PlantUML, D2 examplesBased on research (December 2025):
Documentation Sites:
API Documentation:
Code Documentation:
Diagrams:
api-patterns - API implementation and documentationbuilding-ci-pipelines - Automate documentation generationtesting-strategies - Document test patternssdk-design - Generate SDK documentationDocumentation Drift - Docs become outdated
→ Automate generation, validate in CI/CD
Over-Documentation - Documenting obvious behavior
→ Focus on "why" not "what"
Fragmented Docs - Information scattered
→ Single site with clear navigation
No Examples - Theory without practice
→ Include runnable examples
Interact with Obsidian vaults using the Obsidian CLI to read, create, search, and manage notes, tasks, properties, and more. Also supports plugin and theme development with commands to reload plugins, run JavaScript, capture errors, take screenshots, and inspect the DOM. Use when the user asks to interact with their Obsidian vault, manage notes, search vault content, perform vault operations from the command line, or develop and debug Obsidian plugins and themes.
Comprehensive project architecture blueprint generator that analyzes codebases to create detailed architectural documentation. Automatically detects technology stacks and architectural patterns, generates visual diagrams, documents implementation patterns, and provides extensible blueprints for maintaining architectural consistency and guiding new development.
Securely inspect and automate microscopy data workflows against OMERO.server with omero-py, BlitzGateway, OMERO CLI, tables, annotations, ROIs, rendering, and documented OMERO.web APIs. Use for scoped OMERO inventory, metadata export, import/export planning, or reviewed write workflows.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Master API documentation with OpenAPI 3.1, AI-powered tools, and modern developer experience practices. Create interactive docs, generate SDKs, and build comprehensive developer portals.
Creates comprehensive API changelogs documenting breaking changes, deprecations, and migration strategies for API consumers. Use when managing API versions, communicating breaking changes, or creating upgrade guides.
Master API documentation with OpenAPI 3.1, AI-powered tools, and modern developer experience practices. Create interactive docs, generate SDKs, and build comprehensive developer portals. Use PROACTIVELY for API documentation or developer portal creation.
Analyze fundamental data primitives, type systems, and state management patterns in a codebase. Use when (1) evaluating typing strategies (Pydantic vs TypedDict vs loose dicts), (2) assessing immutability and mutation patterns, (3) understanding serialization approaches, (4) documenting state shape and lifecycle, or (5) comparing data modeling approaches across frameworks.
Take ancoleman/generating-documentation from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.
The instructions reference pip, npm, npx.
Without those the skill loads but fails at the first command.