agentleFS
Sagargupta16Sagargupta16/agent-recipes/skills/api-docs-generator/SKILL.md

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
  1. Distinctive:

    Add a clear description of what the API does

    line 28
  2. Distinctive:

    Use environment variable placeholders for URLs

    line 32
  3. Distinctive:

    Add descriptions and examples for every parameter

    line 56
  4. Distinctive:

    Add realistic examples that would pass validation

    line 61
  5. Distinctive:

    Document content types (application/json, multipart/form-data, etc.)

    line 62
  6. Very specific:

    Use $ref to reference shared schemas instead of duplicating

    line 79
  7. Distinctive:

    Document all model properties with types, formats, descriptions, and examples

    line 80
  8. Distinctive:

    Use proper OpenAPI types: string (with format: date-time, email, uuid, uri), integer, number, boolean, array, object

    line 81
  9. Distinctive:

    Use realistic data (real names, plausible emails, UUIDs, timestamps)

    line 85

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- 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:

  1. Route definitions - Express router files, FastAPI decorators, Spring annotations, Go handlers, etc.
  2. Request validation - Joi, Zod, Pydantic, class-validator schemas, or manual validation logic
  3. Response structures - What objects are returned in successful responses
  4. Error handling - Error response formats, status codes, error messages
  5. Authentication - Middleware, decorators, or guards that enforce auth
  6. 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 $ref to 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:

  1. The complete OpenAPI 3.0 YAML specification
  2. A summary of all endpoints found with their HTTP methods
  3. 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")
  4. 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.