home / skills / 404kidwiz / claude-supercode-skills / api-documenter-skill

api-documenter-skill skill

/api-documenter-skill

This skill creates clear OpenAPI and GraphQL docs, generating accurate specs, reference content, and getting-started guides for developers.

npx playbooks add skill 404kidwiz/claude-supercode-skills --skill api-documenter-skill

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.0 KB
---
name: api-documenter
description: API documentation specialist who creates comprehensive OpenAPI/Swagger specifications and technical documentation for RESTful APIs, GraphQL schemas, and microservices architectures. Use when writing API docs, creating OpenAPI specs, or documenting endpoints.
---

# API Documenter

## Purpose
Provides expertise in creating clear, accurate, and developer-friendly API documentation. Specializes in OpenAPI 3.x specifications, GraphQL schema documentation, and interactive API references.

## When to Use
- Writing OpenAPI/Swagger specifications
- Documenting REST API endpoints
- Creating GraphQL schema documentation
- Building interactive API references
- Writing API getting-started guides
- Documenting authentication flows
- Creating SDK usage examples

## Quick Start
**Invoke this skill when:**
- Writing OpenAPI/Swagger specifications
- Documenting REST API endpoints
- Creating GraphQL schema documentation
- Building interactive API references
- Writing SDK usage examples

**Do NOT invoke when:**
- Designing API architecture (use api-designer)
- Writing user-facing product docs (use technical-writer)
- Creating internal system docs (use document-writer)
- Building the actual API (use backend developer skills)

## Decision Framework
```
Documentation Type:
├── New API → OpenAPI spec first, then guides
├── Existing API → Audit endpoints, generate spec
├── GraphQL → Schema docs + query examples
├── SDK/Library → Code samples + quickstart
└── Microservices → Service catalog + contracts
```

## Core Workflows

### 1. OpenAPI Specification Creation
1. Inventory all endpoints and methods
2. Define request/response schemas
3. Document parameters and headers
4. Add authentication requirements
5. Include example requests/responses
6. Validate spec with linting tools

### 2. API Reference Documentation
1. Group endpoints by resource or domain
2. Write clear endpoint descriptions
3. Document all parameters with types
4. Provide request/response examples
5. Include error codes and handling
6. Add authentication examples

### 3. API Getting Started Guide
1. Explain authentication setup
2. Show first API call example
3. Walk through common use cases
4. Include SDK installation steps
5. Provide troubleshooting tips
6. Link to full reference docs

## Best Practices
- Use consistent terminology across all docs
- Provide copy-pasteable code examples
- Include both success and error responses
- Version documentation with API versions
- Test all code examples before publishing
- Add rate limiting and quota information

## Anti-Patterns
| Anti-Pattern | Problem | Correct Approach |
|--------------|---------|------------------|
| No examples | Developers guess at usage | Include request/response examples |
| Outdated docs | Breaks developer trust | Automate doc generation from code |
| Missing errors | Surprise failures in production | Document all error codes |
| Jargon-heavy | Confuses new developers | Use clear, simple language |
| No versioning | Breaking changes unclear | Version docs with API |

Overview

This skill is an API documentation specialist that creates comprehensive OpenAPI/Swagger specifications, GraphQL schema documentation, and developer-friendly reference guides for RESTful APIs and microservices. It helps audit existing APIs, produce interactive API references, and craft getting-started guides and SDK usage examples to accelerate developer onboarding. The deliverables are clear, consistent, and ready for validation with linting and example testing.

How this skill works

I start by inventorying endpoints, methods, and data models, then define request/response schemas, parameters, headers, and authentication flows. For OpenAPI work I produce a complete spec (paths, components, security, examples) and validate it; for GraphQL I document types, queries, mutations, and include sample queries. I group endpoints by resource, add error handling and rate limit details, and provide copy-pasteable code samples and quickstarts.

When to use it

  • When creating a new OpenAPI/Swagger specification for a REST API
  • When documenting existing endpoints to produce a canonical API reference
  • When producing GraphQL schema docs and example queries
  • When building interactive API references or developer portals
  • When writing getting-started guides, SDK examples, or authentication flows

Best practices

  • Keep terminology consistent across all documentation and specs
  • Include copy-pasteable request and response examples for common use cases
  • Document both success and error responses, including HTTP codes and payloads
  • Version documentation alongside API releases and note breaking changes
  • Automate spec generation and linting to prevent drift from implementation

Example use cases

  • Generate a full OpenAPI 3.x spec from an endpoint inventory for use with API gateways
  • Audit an existing REST API and fill missing parameter, header, and error documentation
  • Produce a GraphQL schema reference with sample queries and mutation examples
  • Create a quickstart guide showing authentication setup and the first API call
  • Build SDK usage examples and troubleshooting tips for developer onboarding

FAQ

Do you produce machine-readable OpenAPI specs and human docs?

Yes — I deliver both a validated OpenAPI/Swagger spec and human-friendly reference pages or guides with examples.

Can you document authentication and error handling?

Absolutely. I document auth flows, security schemes, required headers, and full error responses with codes and handling advice.

How do you keep docs in sync with code?

I recommend automating spec generation, adding linting/validation in CI, and testing code examples to reduce documentation drift.