api

Designs and reviews REST API contracts covering endpoints, errors, pagination, and idempotency.

1|Updated Apr 24, 2026
One-click install
npx skills add https://github.com/kreek/consult --skill api-kreek
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: api
Source: https://github.com/kreek/consult/tree/main/plugin/skills/api
Command: npx skills add https://github.com/kreek/consult --skill api-kreek

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Public REST APIs break consumers when teams rename fields, change status codes, or skip pagination and idempotency planning. This Skill enforces contract-first design so APIs evolve additively without breaking existing callers. ## Core Features & Use Cases - Contract-first design: Sketch OpenAPI or the repo's contract source before writing controller code, with explicit response, error, and pagination shapes. - Evolution and versioning rules: Distinguish additive changes from breaking ones, pick one versioning strategy per service, and manage deprecation with overlap windows and Sunset headers. - Status-by-origin error handling: Map 4xx to consumer-request problems and 5xx to upstream or service faults, using one consistent error shape (JSON:API, Problem Details, or FHIR OperationOutcome). - Use Case: When adding a new endpoint that charges customers, use this Skill to define the idempotency-key contract, bounded cursor pagination, and signed webhook delivery before any handler code is written. ## Quick Start Use the api skill to review this OpenAPI spec for breaking changes, error-shape consistency, and missing pagination or idempotency contracts.

Frequently Asked Questions about api

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I version a REST API without breaking existing clients?▼

Evolve in place with additive changes: new optional fields, parameters, headers, or endpoints that old callers can ignore. For renames, removals, or required additions, ship a successor contract under a new version with a deprecation overlap window and Sunset headers.

How do I choose HTTP status codes for REST API errors?▼

Pick status by failure origin: 4xx when the consumer can fix the request (400 malformed, 401 unauthenticated, 403 forbidden, 422 domain-rule violation), and 5xx for upstream or service faults (502, 503, 504). Never leak raw upstream or internal errors to consumers.

Should I use JSON:API or Problem Details for API error responses?▼

Default to JSON:API for resource-oriented REST APIs, which uses a top-level errors array with string status and source pointers. Use RFC 9457 Problem Details for plain JSON APIs and FHIR OperationOutcome for healthcare. Pick one shape per API; the conventions are structurally distinct and not interchangeable.

How do I make POST endpoints safe to retry?▼

Define an idempotency-key contract specifying key scope, replay window, duplicate-response behavior, and conflict semantics. The server persists key-to-response mappings, claims keys atomically, and rejects same-key different-body requests with a documented conflict status.

When should validation logic go in middleware versus the route handler?▼

Middleware handles transport-wide concerns like logging, tracing, CORS, body parsing, and authentication context. Endpoint-specific validation, resource ownership checks, privileged authorization, and domain invariants belong in the handler or domain layer where the resource and actor are visible.

Does this API guidance apply to GraphQL or gRPC services?▼

No. This Skill covers REST resource APIs only. gRPC, GraphQL, and message-queue contracts have their own ecosystem conventions for contract shape, errors, and evolution, which are explicitly out of scope.