What problem does it solve? Teams building REST APIs often ship inconsistent endpoints with wrong status codes, ad-hoc error formats, and missing pagination, which creates confusion for API consumers and costly breaking changes later. ## Core Features & Use Cases - Resource and URL Conventions: Enforces plural kebab-case resource naming, correct HTTP method semantics, and semantic status codes (201 with Location, 422 for validation, 429 for rate limits). - Pagination, Filtering, and Sorting: Provides offset-based and cursor-based pagination patterns with guidance on when to use each, plus query parameter conventions for filtering, sorting, and sparse fieldsets. - Standard Response Formats: Defines success, collection, and error response envelopes with field-level validation details, plus rate limiting headers and versioning strategy. - Use Case: When adding a new orders endpoint to a FastAPI or Next.js backend, apply the checklist to return 201 with a Location header on creation, cursor-paginate the list endpoint, and emit structured validation errors. ## Quick Start Use the api-design skill to review my new /api/v1/orders endpoints and fix the status codes, pagination, and error response format.
