api-documentation
npx machina-cli add skill zircote/documentation-review/api-documentation --openclawAPI Documentation
<!-- BEGIN MNEMONIC PROTOCOL -->Memory Operations
You have PERSISTENT MEMORY across sessions.
BEFORE starting any task:
if [ -d ~/.claude/mnemonic ]; then
rg -i "{api_documentation}" ~/.claude/mnemonic/ --glob "*.memory.md" -l | head -5
fi
If results exist, READ the most relevant and apply that context.
AFTER completing work, if you discovered:
- A decision → capture to _semantic/decisions
- A pattern → capture to _procedural/patterns
- A learning → capture to _semantic/knowledge
- A blocker → capture to _episodic/blockers
Guidance for creating comprehensive API documentation using OpenAPI/Swagger, AsyncAPI, and manual documentation patterns.
OpenAPI/Swagger Overview
OpenAPI Specification (OAS) is the standard for describing REST APIs. Use it for:
- Auto-generating documentation portals
- Client SDK generation
- API testing and validation
- Contract-first development
Supported Versions
- OpenAPI 3.1 - Current standard, JSON Schema compatible
- OpenAPI 3.0 - Widely supported, stable
- Swagger 2.0 - Legacy, still common
Basic Structure
openapi: 3.1.0
info:
title: API Name
version: 1.0.0
description: Brief API description
servers:
- url: https://api.example.com/v1
paths:
/resource:
get:
summary: Get resources
responses:
'200':
description: Success
Documenting Endpoints
Required Elements
For each endpoint, document:
- HTTP Method and Path -
GET /users/{id} - Summary - One-line description
- Description - Detailed explanation (when needed)
- Parameters - Path, query, header parameters
- Request Body - For POST/PUT/PATCH
- Responses - All possible response codes
- Examples - Request/response examples
Path Parameters
parameters:
- name: userId
in: path
required: true
description: Unique user identifier
schema:
type: string
format: uuid
example: "123e4567-e89b-12d3-a456-426614174000"
Query Parameters
parameters:
- name: limit
in: query
required: false
description: Maximum number of results
schema:
type: integer
minimum: 1
maximum: 100
default: 20
Request Bodies
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateUser'
example:
name: "John Doe"
email: "john@example.com"
Response Documentation
Document all response codes:
responses:
'200':
description: Successful response
content:
application/json:
schema:
$ref: '#/components/schemas/User'
'400':
description: Invalid request parameters
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
'404':
description: User not found
'500':
description: Internal server error
Schema Definitions
Component Schemas
Define reusable schemas in components:
components:
schemas:
User:
type: object
required:
- id
- email
properties:
id:
type: string
format: uuid
description: Unique identifier
email:
type: string
format: email
description: User email address
name:
type: string
description: Display name
createdAt:
type: string
format: date-time
Common Patterns
Pagination:
PaginatedResponse:
type: object
properties:
data:
type: array
items:
$ref: '#/components/schemas/Item'
pagination:
type: object
properties:
total:
type: integer
page:
type: integer
limit:
type: integer
Error Response:
Error:
type: object
required:
- code
- message
properties:
code:
type: string
description: Error code
message:
type: string
description: Human-readable message
details:
type: array
items:
type: object
Authentication Documentation
Security Schemes
components:
securitySchemes:
bearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
apiKey:
type: apiKey
in: header
name: X-API-Key
oauth2:
type: oauth2
flows:
authorizationCode:
authorizationUrl: https://auth.example.com/authorize
tokenUrl: https://auth.example.com/token
scopes:
read: Read access
write: Write access
Applying Security
# Global security
security:
- bearerAuth: []
# Per-endpoint override
paths:
/public:
get:
security: [] # No auth required
AsyncAPI for Event-Driven APIs
For message-based APIs (WebSocket, MQTT, Kafka):
asyncapi: 2.6.0
info:
title: Events API
version: 1.0.0
channels:
user/created:
subscribe:
summary: User created events
message:
$ref: '#/components/messages/UserCreated'
components:
messages:
UserCreated:
payload:
type: object
properties:
userId:
type: string
timestamp:
type: string
format: date-time
Documentation Quality Checklist
Completeness
- All endpoints documented
- All parameters described
- All response codes listed
- Authentication explained
- Rate limits documented
Accuracy
- Schemas match actual responses
- Examples are valid JSON
- Status codes are correct
- Parameter types are accurate
Usability
- Clear summaries for endpoints
- Realistic examples provided
- Error responses helpful
- Common use cases covered
Generating Documentation
From Code (Code-First)
- Extract from decorators/annotations
- Generate from type definitions
- Tools: swagger-jsdoc, FastAPI, NestJS Swagger
From Spec (Design-First)
- Write OpenAPI spec first
- Generate server stubs
- Generate client SDKs
- Tools: Swagger Codegen, OpenAPI Generator
From Language Doc Toolchains
When a project uses a language-native doc toolchain, API documentation may come from source code comments rather than OpenAPI specs. Detect and support:
| Language | Toolchain | Build Command | Config Key |
|---|---|---|---|
| Rust | rustdoc | cargo doc --no-deps --all-features | api_docs.rustdoc |
| Go | godoc / pkgsite | go doc ./... | api_docs.godoc |
| Python | Sphinx autodoc / pdoc | sphinx-build / pdoc | api_docs.sphinx |
| TypeScript | TypeDoc | npx typedoc | api_docs.typedoc |
| Java | Javadoc | javadoc / ./gradlew javadoc | api_docs.javadoc |
| Kotlin | Dokka (KDoc) | ./gradlew dokkaHtml | api_docs.dokka |
| Swift | DocC | swift package generate-documentation | api_docs.docc |
| C# | DocFX / XML docs | docfx build | api_docs.docfx |
| Elixir | ExDoc | mix docs | api_docs.exdoc |
When reviewing a project with both OpenAPI and a language doc toolchain:
- OpenAPI/AsyncAPI = external API contract (HTTP/event surface)
- Language doc toolchain = internal/library API surface (code-level)
- Both should be reviewed — they document different audiences
- Cross-check: HTTP endpoint docs should align with handler function doc comments
See the documentation-standards skill for detailed per-language doc comment conventions and review criteria.
Documentation Portals
- Swagger UI - Interactive API explorer
- ReDoc - Clean reference documentation
- Stoplight - Collaborative API design
- Astro Starlight - Modern documentation sites with component islands
Additional Resources
Reference Files
For detailed patterns, consult:
references/openapi-patterns.md- Advanced OpenAPI patternsreferences/endpoint-templates.md- Copy-paste endpoint templates
Example Files
Working examples in examples/:
petstore-openapi.yaml- Complete OpenAPI exampleevents-asyncapi.yaml- AsyncAPI example
Source
git clone https://github.com/zircote/documentation-review/blob/main/skills/api-documentation/SKILL.mdView on GitHub Overview
This skill guides documenting APIs using OpenAPI/Swagger, AsyncAPI, and established endpoint documentation patterns. It covers how to describe REST endpoints, define parameters, requests, responses, and reusable schemas to produce clear, testable API references.
How This Skill Works
Start by selecting a spec format (OpenAPI 3.x, Swagger 2.0, or AsyncAPI). For each endpoint, document method and path, summarize the endpoint, describe the detailed description, list all parameters (path, query, header), specify the request body if applicable, and enumerate responses with examples. Define reusable schemas in components and provide concrete examples to anchor usage and testing.
When to Use It
- Document a REST API or AsyncAPI spec from existing endpoints
- Generate an OpenAPI/Swagger contract for a new project
- Review and improve endpoint documentation for clarity and completeness
- Define request bodies, responses, and reusable components for consistency
- Provide examples and naming patterns for API references and client usage
Quick Start
- Step 1: Gather all endpoints, methods, and current behavior to document
- Step 2: Pick a spec (OpenAPI 3.1 recommended) and scaffold paths, components, and info
- Step 3: Fill in parameters, request bodies, responses, and examples; validate and publish
Best Practices
- Document every endpoint with method, path, summary, and description
- Include all parameters (path, query, header) with types, constraints, and examples
- Capture request bodies and all response codes with examples
- Use reusable components/schemas to avoid duplication and ensure consistency
- Choose a spec version (OpenAPI 3.x or Swagger 2.0) early and validate with tooling
Example Use Cases
- OpenAPI 3.1 spec for a user management service with schemas for User and Error
- Swagger 2.0 file documenting a legacy order API with path parameters and responses
- AsyncAPI document describing a message broker topic for order events
- Endpoint doc pattern for GET /users/{id} including path param, query limits, and 200/404 responses
- API reference page that links to code samples and SDK generation from OpenAPI schemas