Generate Comprehensive API Documentation

A specialized workflow for creating comprehensive API documentation: OpenAPI/Swagger specs, developer guides, code examples, and interactive documentation. It's structured as 7 phases, each invoking specific sub-skills:

1. API Discovery - inventories endpoints, documents request/response shapes, identifies authentication, maps error codes and rate limits (invokes api-documenter, api-design-principles).
2. OpenAPI Specification - creates the OpenAPI schema, defines paths and schemas, configures security, adds examples (openapi-spec-generation, api-documenter).
3. Developer Guide - writes a getting-started guide, an authentication guide, common patterns, troubleshooting, and an FAQ (api-documentation-generator, documentation-templates).
4. Code Examples - writes example requests, SDK examples, curl examples, and tutorials, then tests them (api-documenter, tutorial-engineer).
5. Interactive Docs - sets up Swagger UI and Redoc with try-it functionality (api-documenter).
6. Documentation Site - chooses a platform, designs the structure, and adds navigation and search (docs-architect, wiki-page-writer).
7. Maintenance - sets up auto-generation, validation, a review process, and scheduled updates (api-documenter).

Use this workflow when creating API documentation, generating OpenAPI specs, writing developer guides, adding code examples, or setting up an API portal from scratch.

Each phase ships a copy-paste prompt to invoke its sub-skill, e.g. Use @api-documenter to discover and document API endpoints. Output includes an OpenAPI spec, a developer guide, working code examples, interactive docs, and a deployed documentation site - checked against a quality-gate checklist (spec complete, guide written, examples working, interactive docs functional, docs deployed).

Teams standing up or overhauling API documentation who want a repeatable, phase-by-phase process rather than an ad hoc writing effort. Related bundles: documentation, api-development, development.

Before considering the workflow complete, it checks: OpenAPI spec complete, developer guide written, code examples working, interactive docs functional, and documentation deployed. Each phase's copy-paste prompt invokes a named sub-skill directly, e.g. Use @openapi-spec-generation to create OpenAPI specification for phase 2, or Use @docs-architect to design API documentation site for phase 6 - so the workflow can be run phase-by-phase rather than requiring the whole pipeline in one pass. Each phase also names the specific sub-skills it invokes rather than leaving that implicit: phase 1 (API Discovery) uses api-documenter and api-design-principles; phase 3 (Developer Guide) uses api-documentation-generator and documentation-templates; phase 4 (Code Examples) uses api-documenter and tutorial-engineer; phase 6 (Documentation Site) uses docs-architect and wiki-page-writer - so a user who only needs one phase's output can invoke that sub-skill directly instead of running the full seven-phase workflow.