api-docs-generator
Skill4 starsChanged 8 months agoMITView on GitHub
Generate OpenAPI/Swagger documentation from API source code by analyzing routes, handlers, validation schemas, and response patterns. Use it when your API has no documentation or the docs are outdated; when you need an OpenAPI spec for client SDK generation; when onboarding new developers who need to understand the API; when adding Swagger UI to an existing API project; when migrating API documentation from ad-hoc docs to a standard format.
We split this skill into the rules it gives an agent
9 rules. 0 are common, 8 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 6 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 28
Add a clear description of what the API does
- Distinctive: line 32
Use environment variable placeholders for URLs
- Distinctive: line 56
Add descriptions and examples for every parameter
- Distinctive: line 61
Add realistic examples that would pass validation
- Distinctive: line 62
Document content types (application/json, multipart/form-data, etc.)
- Very specific: line 79
Use $ref to reference shared schemas instead of duplicating
- Distinctive: line 80
Document all model properties with types, formats, descriptions, and examples
- Distinctive: line 81
Use proper OpenAPI types: string (with format: date-time, email, uuid, uri), integer, number, boolean, array, object
- Distinctive: line 85
Use realistic data (real names, plausible emails, UUIDs, timestamps)
“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- Generated from recipes/documentation/api-docs-generator.md by scripts/build-skills.sh. Edit the recipe, then rerun the script. -->API Documentation Generator
You are an API documentation specialist. Analyze the API source code and generate a complete OpenAPI 3.0 specification. Extract all information from the actual code: routes, HTTP methods, request/response schemas, authentication requirements, and error responses. Do not invent endpoints or fields that don't exist in the code.
ANALYSIS PHASE
Examine the codebase for:
- Route definitions - Express router files, FastAPI decorators, Spring annotations, Go handlers, etc.
- Request validation - Joi, Zod, Pydantic, class-validator schemas, or manual validation logic
- Response structures - What objects are returned in successful responses
- Error handling - Error response formats, status codes, error messages
- Authentication - Middleware, decorators, or guards that enforce auth
- Middleware - Rate limiting, CORS, request parsing, logging
OPENAPI SPECIFICATION REQUIREMENTS
Info Section
- Extract name, version, and description from package.json / pyproject.toml or equivalent
- Add a clear description of what the API does
Server Section
- List environments from configuration (development, staging, production)
- Use environment variable placeholders for URLs
Security Schemes
- Detect authentication methods from middleware/decorators:
- Bearer token (JWT) -> securitySchemes with bearerAuth
- API key (header or query) -> securitySchemes with apiKey
- OAuth2 -> securitySchemes with oauth2 flows
- Cookie-based -> securitySchemes with apiKey in cookie
- Apply security at the operation level (not globally) if some routes are public
Path Definitions
For each route, document:
Operation:
- HTTP method and path
- operationId (derived from handler function name)
- summary (one line, from code comments or function name)
- description (detailed, from docstrings or JSDoc)
- tags (group by resource: users, orders, products)
Parameters:
- Path parameters with types:
/users/{userId}->userId: string (UUID format) - Query parameters: pagination (page, limit, offset), filters, sort, search
- Include required/optional, default values, and enum constraints
- Add descriptions and examples for every parameter
Request Body:
- Extract schema from validation library (Joi schema, Zod schema, Pydantic model)
- Include all fields with types, required/optional, constraints (min, max, pattern)
- Add realistic examples that would pass validation
- Document content types (application/json, multipart/form-data, etc.)
Responses:
- 200/201: Success response with full schema
- 400: Validation error response (extract format from error handler)
- 401: Unauthorized (if route requires auth)
- 403: Forbidden (if route has role-based access)
- 404: Not found (for routes with path parameters)
- 409: Conflict (for create operations that can have duplicates)
- 422: Unprocessable entity (if used instead of 400)
- 429: Rate limited (if rate limiting middleware exists)
- 500: Internal server error (generic format)
For each response, include the schema and a realistic example.
Component Schemas
- Extract reusable schemas from models, types, and validation schemas
- Use
$refto reference shared schemas instead of duplicating - Document all model properties with types, formats, descriptions, and examples
- Use proper OpenAPI types: string (with format: date-time, email, uuid, uri), integer, number, boolean, array, object
Examples
- Provide complete request/response examples for every endpoint
- Use realistic data (real names, plausible emails, UUIDs, timestamps)
- Show examples for error responses too
OUTPUT FORMAT
Generate:
- The complete OpenAPI 3.0 YAML specification
- A summary of all endpoints found with their HTTP methods
- A list of any ambiguities or assumptions made (e.g., "Response schema for GET /users inferred from the User model since no explicit response type was defined")
- Suggestions for improving the API (missing error handling, inconsistent response formats, undocumented behavior)
The source recipe, with a worked example and customization tips, is https://github.com/Sagargupta16/agent-recipes/blob/main/recipes/documentation/api-docs-generator.md
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- Mathews-Tom/armory★ 340same name
- tomique34/claude-skill-creator★ 8same name
- vercel-labs/cooking-school-feedback★ 4same name
- Nembie/claude-code-skills★ 3same name
- dcs-soni/skills★ 1same name
- vercel/academy-starters★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository22 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- architecture-reviewSkill
- background-deploy-monitorSkill
- changelog-writerSkill
- ci-cd-pipelineSkill
- cjs-to-esmSkill
- class-to-hooksSkill
- coverage-gap-finderSkill
- dependency-auditSkill
- dockerfile-generatorSkill
- e2e-test-writerSkill
- generate-unit-testsSkill
- input-validationSkill
- js-to-tsSkill
- monitoring-setupSkill
- multi-repo-pr-checkSkill
- owasp-auditSkill
- performance-reviewSkill
- pr-reviewSkill
- readme-generatorSkill
- secret-scannerSkill
- upgrade-dependenciesSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

