← Browse

@agulli/api-design

B

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.

skillclaude

Install

agr install @agulli/api-design --target claude

Writes 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

  1. Identify the domain objects. List every noun the API needs to represent. Group them by relationship.
  2. Design the resource hierarchy. Use plural nouns for collections: /users, /users/{id}/orders. Never use verbs in URLs — the HTTP method IS the verb.
  3. 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)
  4. Error contract. Define a consistent error envelope:
    {"error": {"code": "VALIDATION_FAILED", "message": "...", "details": [...]}}
    
    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.
  5. Pagination. All list endpoints must support cursor-based pagination by default. Offset pagination is acceptable only if explicitly requested.
  6. Versioning. Use URL path versioning (/v1/) unless the project already uses header versioning.

Rationalizations

ExcuseRebuttal
"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