@agulli/api-design
BDesign or review REST and GraphQL API interfaces. Use when asked to design an API, review endpoint structure, define request/response schemas, or improve API ergonomics.
Install
agr install @agulli/api-design --target claudeWrites 1 file into .claude/skills/, pinned to git-ff3ee3c2.
- .claude/skills/api-design/SKILL.md
Document
name: api-design description: Design or review REST and GraphQL API interfaces. Use when asked to design an API, review endpoint structure, define request/response schemas, or improve API ergonomics. license: MIT
Overview
You are designing APIs that other developers — and other agents — will consume. Clarity and predictability matter more than cleverness.
Process
- Identify the domain objects. List every noun the API needs to represent. Group them by relationship.
- Design the resource hierarchy. Use plural nouns for collections:
/users,/users/{id}/orders. Never use verbs in URLs — the HTTP method IS the verb. - Define schemas. Write request and response schemas as JSON examples. Every field must have:
- A type
- Whether it's required or optional
- An example value
- Validation constraints (min/max length, regex pattern, allowed values)
- Error contract. Define a consistent error envelope:
Use HTTP status codes correctly: 400 for bad input, 401 for auth, 403 for forbidden, 404 for not found, 409 for conflicts, 422 for semantic errors.{"error": {"code": "VALIDATION_FAILED", "message": "...", "details": [...]}} - Pagination. All list endpoints must support cursor-based pagination by default. Offset pagination is acceptable only if explicitly requested.
- Versioning. Use URL path versioning (
/v1/) unless the project already uses header versioning.
Rationalizations
| Excuse | Rebuttal |
|---|---|
| "We can add pagination later" | No. Adding pagination to an existing endpoint is a breaking change. Design it in from day one. |
"Let's use a generic /api/action endpoint with a type field" | This is RPC masquerading as REST. Use proper resource URLs. |
| "We don't need error codes, the message is enough" | Machines parse codes, humans read messages. You need both. |
Verification
- Every endpoint has a documented request schema, response schema, and at least one error response
- All list endpoints support pagination
- No verbs in URL paths
- Error responses follow the standard envelope format
Trustgrade B
- passBody integrity
Whether the stored document is plausibly the kind of file the artifact declares, rather than something fetched by mistake.
- passType matchnot applicable to this artifact type
Whether the artifact is really the kind of thing its metadata claims it is.
- passFreshness
How long since the source repository was last pushed to.
- passPrompt injection
Scans the artifact's own text for instructions aimed at your agent rather than at you.
- warnLicenseno SPDX license detected
Whether the source repository declares an SPDX license permissive enough to redistribute.
How the grade is calculated
Each check contributes 0 points when it passes, 1 when it warns, and 2 when it fails. The total maps to a letter:
- Aevery check passed
- Bone warning
- Ctwo warnings
- Dprompt injection or body integrity failed, or three warnings
- Fone of those failed, and something else is wrong
These are automated hygiene checks, not a security audit, and not a dependency or vulnerability scan. A grade of A means nothing was flagged — not that the artifact is safe.
Versions
git-ff3ee3c2236a2026-07-31