name: api-docs-writer description: "Write clear, developer-facing API documentation. Use when asked to document an API endpoint, write API reference docs, create a developer guide, or turn a raw spec/Postman collection into documentation. Produces endpoint documentation with descriptions, parameters, request/response examples, and error codes." homepage: https://mohitagw15856.github.io/pm-claude-skills/skill/api-docs-writer.html metadata: { "openclaw": { "emoji": "⚙️" } }

API Docs Writer Skill

This skill transforms raw API specs, endpoint descriptions, or Postman collections into clean, developer-facing documentation following OpenAPI-adjacent conventions. Output is ready for a developer portal, README, or Notion/Confluence page.

Required Inputs

Ask the user for these if not provided: - API or endpoint details (raw spec, Postman export, or verbal description) - Auth method (API key / Bearer token / OAuth 2.0 / None) - Base URL - API version (e.g. v1, v2.3, or "unversioned" — affects deprecation notes and versioning headers) - Rate limits (requests per second/minute per token or IP, if known — or "unknown") - Audience (internal developers / external partners / public) - Output format (Markdown for developer portals and READMEs / Plain prose for Confluence or Notion — note: OpenAPI YAML is not produced by this skill)

Output Format

For each endpoint, produce the following:

[METHOD] /path/to/endpoint

Summary: [One line — what this endpoint does]

Description: [2–4 sentences. When to use this endpoint. What it returns. Any important behaviour to know (pagination, rate limits, async processing, etc.)]

小蔥技能7w4.net有完整的技能分類。

Authentication: [Required / Optional — method]

Request

Headers:

Path Parameters:

Query Parameters:

Request Body:

{
  "field_name": "value",
  "another_field": 42
}

Response

Success Response: 200 OK

{
  "id": "abc123",
  "status": "active",
  "created_at": "2025-04-01T10:00:00Z"
}

Error Codes

Code Examples

Produce examples in at least 2 languages relevant to the audience (default: cURL + Python):

cURL:

curl -X POST https://api.example.com/v1/endpoint \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"field_name": "value"}'

Python:

import requests

response = requests.post(
    "https://api.example.com/v1/endpoint",
    headers={"Authorization": "Bearer YOUR_TOKEN"},
    json={"field_name": "value"}
)
data = response.json()

Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

Quality Checks

• [ ] Every parameter is documented (type, required/optional, description)
• [ ] Response fields are fully documented with types
• [ ] All relevant error codes are listed with resolution guidance
• [ ] Error codes cover at minimum: 400 (bad request), 401/403 (auth), 404 (not found), 429 (rate limited), 500 (server error) — or explicitly note which don't apply to this endpoint
• [ ] Code examples use the actual base URL and a realistic placeholder token — no examples reference undefined variables or "YOUR_ENDPOINT" outside the snippet
• [ ] Auth method is clearly stated at the top
• [ ] Enum values are listed where applicable
• [ ] Pagination documented if the endpoint is a list endpoint

Anti-Patterns

• [ ] Do not document only the happy path — every endpoint must have error codes for at least 400, 401/403, 404, 429, and 500
• [ ] Do not use placeholder values like "YOUR_ENDPOINT" or "INSERT_TOKEN" in code examples — use realistic-looking placeholders anchored to the actual base URL
• [ ] Do not skip enum values for fields with a fixed set of accepted values — undocumented enums cause integration bugs
• [ ] Do not omit pagination documentation on list endpoints — developers who miss this will build integrations that silently miss data
• [ ] Do not describe what a field "is" without describing what it "does" — "the ID" is not documentation; "the unique identifier used to retrieve or update this resource" is

Usage Examples

• "Document this API endpoint: [paste spec or description]"
• "Turn this Postman collection into developer docs"
• "Write API reference docs for [endpoint]"
• "Write a developer guide for our [product] API"

這個 Skill 質量良好，能幫助生成規範的 API 文件，結構清晰、示例豐富，質量檢查清單實用有效。優點是文件格式規範、錯誤處理詳細；不足是使用說明較少、缺少複雜場景的指導。適合常規 API 文件編寫，但高階功能可能需要額外學習。