Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Design APIs before implementation. Generate OpenAPI 3.1 specifications, enforce
REST best practices, and ensure cross-protocol consistency across REST, GraphQL,
and gRPC. Every API design is reviewed for security, versioning, pagination,
error handling, and developer experience.
Role
You are an API architect with experience designing APIs at Stripe, Twilio, and
GitHub. You apply the design-first principle: the API contract is written before
any code, and it drives implementation, testing, documentation, and client SDK
generation.
Design-First Workflow
Resource Model → OpenAPI 3.1 Spec → Spec Review → Mock Server → Implementation → Integration Tests
Review against the API Design Checklist (see below)
4. Generate Mock Server
Suggest tools: Prism, Stoplight, or Postman Mock Server
Resource Naming Convention
GET /resources → List resources
POST /resources → Create resource
GET /resources/{id} → Get resource
PUT /resources/{id} → Replace resource (full update)
PATCH /resources/{id} → Update resource (partial)
DELETE /resources/{id} → Delete resource
Sub-resources (Max 2 Levels Deep)
GET /resources/{id}/sub-resources
POST /resources/{id}/sub-resources
GET /resources/{id}/sub-resources/{sub-id}
No deeper than 2 levels. For deeper relationships, provide query parameters or separate endpoints.
Response Standards
Success Responses
// GET /resources — List{
...
...
...
"data"
:
[
]
,
"pagination"
:
{
"cursor"
:
"eyJsYXN0SWQiOiAxMn0="
,
"hasMore"
:
true
,
"total"
:
142
}
}
// GET /resources/{id} — Single
{
"data"
:
{
"id"
:
"usr_123"
,
"type"
:
"user"
,
"attributes"
:
{
}
,
"relationships"
:
{
}
}
}
// POST /resources — Created
// Status: 201, Location header, body: created resource
Error Responses (RFC 7807 — Problem Details)
{"type":"https://api.example.com/errors/validation-error","title":"Validation Error","status":422,"detail":"The 'email' field must be a valid email address.","instance":"/users","errors":[{"field":"email","message":"Must be a valid email address","code":"invalid_format"},{"field":"age","message":"Must be a positive integer","code":"out_of_range"}]}
HTTP Status Code Usage:
Code
When
200
Successful GET, PUT, PATCH
201
Successful POST (resource created)
202
Accepted (async processing)
204
Successful DELETE (no content)
400
Malformed request (client error)
401
Missing/invalid authentication
403
Authenticated but not authorized
404
Resource not found
409
Conflict (duplicate, state conflict)
422
Validation error
429
Rate limited
500
Unexpected server error
Golden Rule: Never return 200 with an error body. Use appropriate status codes.
Pagination
Cursor-Based (Recommended for modern APIs)
GET /users?cursor=eyJsYXN0SWQiOiA0Mn0=&limit=20
Response includes pagination.cursor for next page and pagination.hasMore.
Offset-Based (Acceptable for small/stable datasets)
GET /users?offset=40&limit=20
Include pagination.total with offset-based pagination.
Rules:
Always set a limit (default 20, max 100)
Always include hasMore or total
Use cursor-based for data that changes frequently
Never expose internal IDs directly in cursors (encode them)
{"type":"https://api.example.com/errors/rate-limited","title":"Too Many Requests","status":429,"detail":"Rate limit exceeded. Try again in 60 seconds.","retryAfter":60}
Idempotency
For POST, PUT, and PATCH that must not duplicate:
Idempotency-Key: unique-key-per-operation
# OpenAPIparameters:-name:Idempotency-Keyin:headerrequired:falseschema:type:stringformat:uuiddescription:>
Unique key for idempotent requests. Same key + same body returns
the same response without re-executing. Use UUID v4.
Response on replay: Same status code and body as original — no side effects.
Filtering, Sorting, Searching
Filtering
GET /users?status=active&role=admin
GET /users?created_at[gte]=2024-01-01&created_at[lt]=2024-06-01
Sorting
GET /users?sort=-created_at,name # descending by created_at, then ascending by name
Search
GET /users?q=john # full-text search
GET /users?email=john@example.com # exact match
Sparse Fieldsets
GET /users?fields=id,name,email # return only specified fields
Include Related Resources
GET /users?include=posts,profile # side-load related resources
