api-documentation

Name: api-documentation
Author: LambdaTest

335stars67forks

How to install api-documentation?

lambdatest/agent-skills/api-documentation

$npx -y skills add LambdaTest/agent-skills --skill api-documentation

Installs into the current project.

Summary

Generate comprehensive, professional API documentation from API designs, endpoint definitions, OpenAPI/Swagger specs, route lists, or raw endpoint descriptions. Use this skill whenever a user provides API endpoints, route definitions, controller code, OpenAPI YAML/JSON, or any st

Files · 1

View on GitHub

SKILL.md

1	# API Documentation Skill
2
3	Generate clear, complete, professional API documentation from any form of API input.
4
5	---
6
7	## Supported Input Formats
8
9	Accept any of the following as input:
10	- OpenAPI / Swagger (YAML or JSON, v2 or v3)
11	- Endpoint list (plain text, e.g. `GET /users/:id`)
12	- Route definitions (Express, FastAPI, Django, Rails, etc.)
13	- Controller / handler code (infer from function signatures and decorators)
14	- Informal descriptions ("I have an endpoint that creates a user and takes name + email")
15	- Postman collections (JSON)
16	- gRPC proto files (document as method-based API)
17	- GraphQL schema (document as query/mutation reference)
18
19	If the input is ambiguous, make reasonable inferences and note assumptions clearly.
20
21	---
22
23	## Output Structure
24
25	Produce documentation with these sections, omitting any that are not applicable:
26
27	### 1. Overview
28	- API name and short description
29	- Base URL (if known or inferable)
30	- Authentication method(s) (API key, Bearer token, OAuth2, etc.)
31	- Versioning scheme (if present)
32	- General conventions (date formats, pagination, error codes)
33
34	### 2. Authentication
35	- How to authenticate
36	- Token/key location (header, query param, cookie)
37	- Example header or request snippet
38	- Token expiry / refresh flow (if mentioned)
39
40	### 3. Endpoints (one section per endpoint)
41
42	For each endpoint, document:
43
44	```
45	### [METHOD] /path/to/endpoint
46	Summary: One-line description of what this endpoint does.
47
48	Description: (Optional) Longer explanation, use cases, side effects.
49
50	Authentication: Required / Optional / None
51
52	#### Path Parameters
53	\| Name \| Type \| Required \| Description \|
54	\|------\|------\|----------\|-------------\|
55	\| id \| string \| Yes \| Unique identifier of the resource \|
56
57	#### Query Parameters
58	\| Name \| Type \| Required \| Default \| Description \|
59	\|------\|------\|----------\|---------\|-------------\|
60	\| page \| integer \| No \| 1 \| Page number for pagination \|
61
62	#### Request Body
63	Content-Type: application/json
64
65	\`\`\`json
66	{
67	"field": "value"
68	}
69	\`\`\`
70
71	\| Field \| Type \| Required \| Description \|
72	\|-------\|------\|----------\|-------------\|
73	\| field \| string \| Yes \| Description of field \|
74
75	#### Responses
76
77	200 OK
78	\`\`\`json
79	{
80	"id": "abc123",
81	"name": "Example"
82	}
83	\`\`\`
84
85	400 Bad Request — Validation error
86	401 Unauthorized — Missing or invalid token
87	404 Not Found — Resource does not exist
88	500 Internal Server Error — Unexpected server error
89
90	#### Example Request
91	\`\`\`bash
92	curl -X POST https://api.example.com/v1/users \
93	-H "Authorization: Bearer <token>" \
94	-H "Content-Type: application/json" \
95	-d '{"name": "Alice", "email": "alice@example.com"}'
96	\`\`\`
97
98	#### Example Response
99	\`\`\`json
100	{
101	"id": "u_abc123",
102	"name": "Alice",
103	"email": "alice@example.com",
104	"createdAt": "2026-03-20T10:00:00Z"
105	}
106	\`\`\`
107	```
108
109	### 4. Data Models / Schemas
110	- Document reusable objects (User, Order, Error, etc.)
111	- Include field name, type, required/optional, and description
112	- Use tables or JSON schema notation
113
114	### 5. Error Reference
115	Standard error format and all documented error codes, e.g.:
116
117	\| Code \| Meaning \| Resolution \|
118	\|------\|---------\|------------\|
119	\| 400 \| Bad Request \| Check request body \|
120	\| 401 \| Unauthorized \| Provide valid token \|
121
122	### 6. Rate Limits & Quotas
123	If mentioned or inferable, document limits and headers used (e.g. `X-RateLimit-Remaining`).
124
125	### 7. Changelog / Versioning Notes
126	If version info is present, summarize breaking vs non-breaking changes.
127
128	---
129
130	## Output Format Rules
131
132	- Default output: Markdown (renders in GitHub, Notion, Confluence, readme.io, etc.)
133	- If user requests HTML: Produce a self-contained HTML page with a sidebar nav and syntax highlighting
134	- If user requests OpenAPI: Produce a valid OpenAPI 3.0 YAML document
135	- If user requests Postman: Produce a Postman Collection v2.1 JSON
136
137	Ask the user which format they want if not specified and the request is substantial (5+ endpoints).
138
139	---
140
141	## Quality Standards
142
143	- Be complete: Don't skip parameters, response fields, or status cod

People who liked this also viewed

6 picks

Type

api-documentation

335stars67forks

View on GitHub

How to install api-documentation?

lambdatest/agent-skills/api-documentation

$npx -y skills add LambdaTest/agent-skills --skill api-documentation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# API Documentation Skill
2
3	Generate clear, complete, professional API documentation from any form of API input.
4
5	---
6
7	## Supported Input Formats
8
9	Accept any of the following as input:
10	- OpenAPI / Swagger (YAML or JSON, v2 or v3)
11	- Endpoint list (plain text, e.g. `GET /users/:id`)
12	- Route definitions (Express, FastAPI, Django, Rails, etc.)
13	- Controller / handler code (infer from function signatures and decorators)
14	- Informal descriptions ("I have an endpoint that creates a user and takes name + email")
15	- Postman collections (JSON)
16	- gRPC proto files (document as method-based API)
17	- GraphQL schema (document as query/mutation reference)
18
19	If the input is ambiguous, make reasonable inferences and note assumptions clearly.
20
21	---
22
23	## Output Structure
24
25	Produce documentation with these sections, omitting any that are not applicable:
26
27	### 1. Overview
28	- API name and short description
29	- Base URL (if known or inferable)
30	- Authentication method(s) (API key, Bearer token, OAuth2, etc.)
31	- Versioning scheme (if present)
32	- General conventions (date formats, pagination, error codes)
33
34	### 2. Authentication
35	- How to authenticate
36	- Token/key location (header, query param, cookie)
37	- Example header or request snippet
38	- Token expiry / refresh flow (if mentioned)
39
40	### 3. Endpoints (one section per endpoint)
41
42	For each endpoint, document:
43
44	```
45	### [METHOD] /path/to/endpoint
46	Summary: One-line description of what this endpoint does.
47
48	Description: (Optional) Longer explanation, use cases, side effects.
49
50	Authentication: Required / Optional / None
51
52	#### Path Parameters
53	\| Name \| Type \| Required \| Description \|
54	\|------\|------\|----------\|-------------\|
55	\| id \| string \| Yes \| Unique identifier of the resource \|
56
57	#### Query Parameters
58	\| Name \| Type \| Required \| Default \| Description \|
59	\|------\|------\|----------\|---------\|-------------\|
60	\| page \| integer \| No \| 1 \| Page number for pagination \|
61
62	#### Request Body
63	Content-Type: application/json
64
65	\`\`\`json
66	{
67	"field": "value"
68	}
69	\`\`\`
70
71	\| Field \| Type \| Required \| Description \|
72	\|-------\|------\|----------\|-------------\|
73	\| field \| string \| Yes \| Description of field \|
74
75	#### Responses
76
77	200 OK
78	\`\`\`json
79	{
80	"id": "abc123",
81	"name": "Example"
82	}
83	\`\`\`
84
85	400 Bad Request — Validation error
86	401 Unauthorized — Missing or invalid token
87	404 Not Found — Resource does not exist
88	500 Internal Server Error — Unexpected server error
89
90	#### Example Request
91	\`\`\`bash
92	curl -X POST https://api.example.com/v1/users \
93	-H "Authorization: Bearer <token>" \
94	-H "Content-Type: application/json" \
95	-d '{"name": "Alice", "email": "alice@example.com"}'
96	\`\`\`
97
98	#### Example Response
99	\`\`\`json
100	{
101	"id": "u_abc123",
102	"name": "Alice",
103	"email": "alice@example.com",
104	"createdAt": "2026-03-20T10:00:00Z"
105	}
106	\`\`\`
107	```
108
109	### 4. Data Models / Schemas
110	- Document reusable objects (User, Order, Error, etc.)
111	- Include field name, type, required/optional, and description
112	- Use tables or JSON schema notation
113
114	### 5. Error Reference
115	Standard error format and all documented error codes, e.g.:
116
117	\| Code \| Meaning \| Resolution \|
118	\|------\|---------\|------------\|
119	\| 400 \| Bad Request \| Check request body \|
120	\| 401 \| Unauthorized \| Provide valid token \|
121
122	### 6. Rate Limits & Quotas
123	If mentioned or inferable, document limits and headers used (e.g. `X-RateLimit-Remaining`).
124
125	### 7. Changelog / Versioning Notes
126	If version info is present, summarize breaking vs non-breaking changes.
127
128	---
129
130	## Output Format Rules
131
132	- Default output: Markdown (renders in GitHub, Notion, Confluence, readme.io, etc.)
133	- If user requests HTML: Produce a self-contained HTML page with a sidebar nav and syntax highlighting
134	- If user requests OpenAPI: Produce a valid OpenAPI 3.0 YAML document
135	- If user requests Postman: Produce a Postman Collection v2.1 JSON
136
137	Ask the user which format they want if not specified and the request is substantial (5+ endpoints).
138
139	---
140
141	## Quality Standards
142
143	- Be complete: Don't skip parameters, response fields, or status cod

People who liked this also viewed

6 picks

Type