agentleFS
GhostekenGhosteken/agent-harness/skills/api-documentation-generator/SKILL.md

api-documentation-generator

Skill2 starsChanged 41 days agoMITView on GitHub

Generate comprehensive, developer-friendly API documentation from code, including endpoints, parameters, examples, and best practices

  • Sends data out

6 other projects use a version of this, 5 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

26 rules. 23 are common, 3 are distinctive, and 0 are very specific to this project.

  • 23

    Common

    Most of the 6 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Use when you need to document a new API

    line 16
  2. Common:

    Use when updating existing API documentation

    line 17
  3. Common:

    Use when your API lacks clear documentation

    line 18
  4. Common:

    Use when onboarding new developers to your API

    line 19
  5. Common:

    Use when preparing API documentation for external users

    line 20
  6. Common:

    Use when creating OpenAPI/Swagger specifications

    line 21
  7. Common:

    All possible error codes

    line 76
  8. Common:

    Be Consistent: - Use the same format for all endpoints

    line 322
  9. Common:

    Show Real Data: - Use realistic example data, not "foo" and "bar"

    line 325
  10. Common:

    Include Rate Limits: - Document any rate limiting policies

    line 330
  11. Common:

    Don't Forget Authentication: - Always document auth requirements

    line 337
  12. Common:

    Don't Ignore Edge Cases: - Document pagination, filtering, sorting

    line 338
  13. Common:

    Don't Leave Examples Broken: - Test all code examples

    line 339
  14. Common:

    Don't Use Outdated Info: - Keep documentation in sync with code

    line 340
  15. Common:

    Don't Overcomplicate: - Keep it simple and scannable

    line 341
  16. Common:

    Don't Forget Response Headers: - Document important headers

    line 342
  17. Common:

    Use tools like Swagger/OpenAPI

    line 398
  18. Common:

    Add API tests that validate documentation

    line 399
  19. Common:

    Document every possible error code

    line 405
  20. Common:

    Test every code example

    line 413
  21. Common:

    Use real, working endpoints

    line 414
  22. Common:

    Document data types and formats

    line 422
  23. Common:

    Pro Tip: Keep your API documentation as close to your code as possible.

    line 484
  24. Distinctive:

    Use this skill only when the task clearly matches the scope described above.

    line 487
  25. Distinctive:

    Do not treat the output as a substitute for environment-specific validation, testing, or expert review.

    line 488
  26. Distinctive:

    Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

    line 489

“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

API Documentation Generator

Overview

Automatically generate clear, comprehensive API documentation from your codebase. This skill helps you create professional documentation that includes endpoint descriptions, request/response examples, authentication details, error handling, and usage guidelines.

Perfect for REST APIs, GraphQL APIs, and WebSocket APIs.

When to Use This Skill

  • Use when you need to document a new API
  • Use when updating existing API documentation
  • Use when your API lacks clear documentation
  • Use when onboarding new developers to your API
  • Use when preparing API documentation for external users
  • Use when creating OpenAPI/Swagger specifications

How It Works

Step 1: Analyze the API Structure

First, I'll examine your API codebase to understand:

  • Available endpoints and routes
  • HTTP methods (GET, POST, PUT, DELETE, etc.)
  • Request parameters and body structure
  • Response formats and status codes
  • Authentication and authorization requirements
  • Error handling patterns

Step 2: Generate Endpoint Documentation

For each endpoint, I'll create documentation including:

Endpoint Details:

  • HTTP method and URL path
  • Brief description of what it does
  • Authentication requirements
  • Rate limiting information (if applicable)

Request Specification:

  • Path parameters
  • Query parameters
  • Request headers
  • Request body schema (with types and validation rules)

Response Specification:

  • Success response (status code + body structure)
  • Error responses (all possible error codes)
  • Response headers

Code Examples:

  • cURL command
  • JavaScript/TypeScript (fetch/axios)
  • Python (requests)
  • Other languages as needed

Step 3: Add Usage Guidelines

I'll include:

  • Getting started guide
  • Authentication setup
  • Common use cases
  • Best practices
  • Rate limiting details
  • Pagination patterns
  • Filtering and sorting options

Step 4: Document Error Handling

Clear error documentation including:

  • All possible error codes
  • Error message formats
  • Troubleshooting guide
  • Common error scenarios and solutions

Step 5: Create Interactive Examples

Where possible, I'll provide:

  • Postman collection
  • OpenAPI/Swagger specification
  • Interactive code examples
  • Sample responses

Examples

Example 1: REST API Endpoint Documentation

## Create User

Creates a new user account.

**Endpoint:** `POST /api/v1/users`

**Authentication:** Required (Bearer token)

**Request Body:**
\`\`\`json
{
  "email": "user@example.com",      // Required: Valid email address
  "password": "SecurePass123!",     // Required: Min 8 chars, 1 uppercase, 1 number
  "name": "John Doe",               // Required: 2-50 characters
  "role": "user"                    // Optional: "user" or "admin" (default: "user")
}
\`\`\`

**Success Response (201 Created):**
\`\`\`json
{
  "id": "usr_1234567890",
  "email": "user@example.com",
  "name": "John Doe",
  "role": "user",
  "createdAt": "2026-01-20T10:30:00Z",
  "emailVerified": false
}
\`\`\`

**Error Responses:**

- `400 Bad Request` - Invalid input data
  \`\`\`json
  {
    "error": "VALIDATION_ERROR",
    "message": "Invalid email format",
    "field": "email"
  }
  \`\`\`

- `409 Conflict` - Email already exists
  \`\`\`json
  {
    "error": "EMAIL_EXISTS",
    "message": "An account with this email already exists"
  }
  \`\`\`

- `401 Unauthorized` - Missing or invalid authentication token

**Example Request (cURL):**
\`\`\`bash
curl -X POST https://api.example.com/api/v1/users \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "user@example.com",
    "password": "SecurePass123!",
    "name": "John Doe"
  }'
\`\`\`

**Example Request (JavaScript):**
\`\`\`javascript
const response = await fetch('https://api.example.com/api/v1/users', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${token}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    email: 'user@example.com',
    password: 'SecurePass123!',
    name: 'John Doe'
  })
});

const user = await response.json();
console.log(user);
\`\`\`

**Example Request (Python):**
\`\`\`python
import requests

response = requests.post(
    'https://api.example.com/api/v1/users',
    headers={
        'Authorization': f'Bearer {token}',
        'Content-Type': 'application/json'
    },
    json={
        'email': 'user@example.com',
        'password': 'SecurePass123!',
        'name': 'John Doe'
    }
)

user = response.json()
print(user)
\`\`\`

Example 2: GraphQL API Documentation

## User Query

Fetch user information by ID.

**Query:**
\`\`\`graphql
query GetUser($id: ID!) {
  user(id: $id) {
    id
    email
    name
    role
    createdAt
    posts {
      id
      title
      publishedAt
    }
  }
}
\`\`\`

**Variables:**
\`\`\`json
{
  "id": "usr_1234567890"
}
\`\`\`

**Response:**
\`\`\`json
{
  "data": {
    "user": {
      "id": "usr_1234567890",
      "email": "user@example.com",
      "name": "John Doe",
      "role": "user",
      "createdAt": "2026-01-20T10:30:00Z",
      "posts": [
        {
          "id": "post_123",
          "title": "My First Post",
          "publishedAt": "2026-01-21T14:00:00Z"
        }
      ]
    }
  }
}
\`\`\`

**Errors:**
\`\`\`json
{
  "errors": [
    {
      "message": "User not found",
      "extensions": {
        "code": "USER_NOT_FOUND",
        "userId": "usr_1234567890"
      }
    }
  ]
}
\`\`\`

Example 3: Authentication Documentation

## Authentication

All API requests require authentication using Bearer tokens.

### Getting a Token

**Endpoint:** `POST /api/v1/auth/login`

**Request:**
\`\`\`json
{
  "email": "user@example.com",
  "password": "your-password"
}
\`\`\`

**Response:**
\`\`\`json
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expiresIn": 3600,
  "refreshToken": "refresh_token_here"
}
\`\`\`

### Using the Token

Include the token in the Authorization header:

\`\`\`
Authorization: Bearer YOUR_TOKEN
\`\`\`

### Token Expiration

Tokens expire after 1 hour. Use the refresh token to get a new access token:

**Endpoint:** `POST /api/v1/auth/refresh`

**Request:**
\`\`\`json
{
  "refreshToken": "refresh_token_here"
}
\`\`\`

Best Practices

✅ Do This

  • Be Consistent - Use the same format for all endpoints
  • Include Examples - Provide working code examples in multiple languages
  • Document Errors - List all possible error codes and their meanings
  • Show Real Data - Use realistic example data, not "foo" and "bar"
  • Explain Parameters - Describe what each parameter does and its constraints
  • Version Your API - Include version numbers in URLs (/api/v1/)
  • Add Timestamps - Show when documentation was last updated
  • Link Related Endpoints - Help users discover related functionality
  • Include Rate Limits - Document any rate limiting policies
  • Provide Postman Collection - Make it easy to test your API

❌ Don't Do This

  • Don't Skip Error Cases - Users need to know what can go wrong
  • Don't Use Vague Descriptions - "Gets data" is not helpful
  • Don't Forget Authentication - Always document auth requirements
  • Don't Ignore Edge Cases - Document pagination, filtering, sorting
  • Don't Leave Examples Broken - Test all code examples
  • Don't Use Outdated Info - Keep documentation in sync with code
  • Don't Overcomplicate - Keep it simple and scannable
  • Don't Forget Response Headers - Document important headers

Documentation Structure

Recommended Sections

  1. Introduction
    • What the API does
    • Base URL
    • API version
    • Support contact
  2. Authentication
    • How to authenticate
    • Token management
    • Security best practices
  3. Quick Start
    • Simple example to get started
    • Common use case walkthrough
  4. Endpoints
    • Organized by resource
    • Full details for each endpoint
  5. Data Models
    • Schema definitions
    • Field descriptions
    • Validation rules
  6. Error Handling
    • Error code reference
    • Error response format
    • Troubleshooting guide
  7. Rate Limiting
    • Limits and quotas
    • Headers to check
    • Handling rate limit errors
  8. Changelog
    • API version history
    • Breaking changes
    • Deprecation notices
  9. SDKs and Tools
    • Official client libraries
    • Postman collection
    • OpenAPI specification

Common Pitfalls

Problem: Documentation Gets Out of Sync

Symptoms: Examples don't work, parameters are wrong, endpoints return different data Solution:

  • Generate docs from code comments/annotations
  • Use tools like Swagger/OpenAPI
  • Add API tests that validate documentation
  • Review docs with every API change

Problem: Missing Error Documentation

Symptoms: Users don't know how to handle errors, support tickets increase Solution:

  • Document every possible error code
  • Provide clear error messages
  • Include troubleshooting steps
  • Show example error responses

Problem: Examples Don't Work

Symptoms: Users can't get started, frustration increases Solution:

  • Test every code example
  • Use real, working endpoints
  • Include complete examples (not fragments)
  • Provide a sandbox environment

Problem: Unclear Parameter Requirements

Symptoms: Users send invalid requests, validation errors Solution:

  • Mark required vs optional clearly
  • Document data types and formats
  • Show validation rules
  • Provide example values

Tools and Formats

OpenAPI/Swagger

Generate interactive documentation:

openapi: 3.0.0
info:
  title: My API
  version: 1.0.0
paths:
  /users:
    post:
      summary: Create a new user
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/CreateUserRequest'

Postman Collection

Export collection for easy testing:

{
  "info": {
    "name": "My API",
    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
  },
  "item": [
    {
      "name": "Create User",
      "request": {
        "method": "POST",
        "url": "{{baseUrl}}/api/v1/users"
      }
    }
  ]
}

Related Skills

  • @doc-coauthoring - For collaborative documentation writing
  • @copywriting - For clear, user-friendly descriptions
  • @test-driven-development - For ensuring API behavior matches docs
  • @systematic-debugging - For troubleshooting API issues

Additional Resources


Pro Tip: Keep your API documentation as close to your code as possible. Use tools that generate docs from code comments to ensure they stay in sync!

Limitations

  • Use this skill only when the task clearly matches the scope described above.
  • Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

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.