api-and-interface-design

Guides design of stable REST APIs, TypeScript contracts, and module boundaries.

Updated May 5, 2026
One-click install
npx skills add https://github.com/UlaYuga/promo-preflight --skill api-and-interface-design-ulayuga
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: api-and-interface-design
Source: https://github.com/UlaYuga/promo-preflight/tree/main/.agents/skills/api-and-interface-design
Command: npx skills add https://github.com/UlaYuga/promo-preflight --skill api-and-interface-design-ulayuga

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Public interfaces become hard to change once consumers depend on them, and inconsistent error handling, missing pagination, or breaking changes create maintenance debt. This Skill provides concrete principles and patterns for designing APIs and module contracts that are hard to misuse and safe to evolve. ## Core Features & Use Cases - Contract-First Design: Define typed interfaces before implementation, with input/output separation and branded ID types in TypeScript. - Consistent Error Semantics: Standardized error shapes, HTTP status code mapping, and boundary-only validation rules. - REST Conventions: Resource naming, pagination, filtering, and PATCH partial-update patterns with red-flag checklists. - Use Case: When adding a new endpoint to a service, apply the verification checklist to confirm typed schemas, paginated list responses, additive-only field changes, and consistent naming before shipping. ## Quick Start Ask the AI to review or design a REST endpoint for a new resource using the api-and-interface-design guidelines and checklist.

Frequently Asked Questions about api-and-interface-design

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

FAQPage Schema
How do I design a REST API that won't break existing consumers?▼

Prefer addition over modification: add new fields as optional and never change or remove existing field types. Use PATCH for partial updates, version only when unavoidable, and treat every observable behavior as a commitment under Hyrum's Law.

What is the best way to structure API error responses?▼

Use one consistent error shape everywhere: a machine-readable code, a human-readable message, and optional details. Map errors to standard HTTP status codes such as 400 for invalid data, 404 for missing resources, and 422 for validation failures.

Where should input validation happen in an API?▼

Validate only at system boundaries: route handlers, form submissions, environment variables, and third-party API responses. Internal functions that share type contracts should trust already-validated data instead of re-validating.

Should third-party API responses be validated before use?▼

Yes. Third-party responses are untrusted data and must be validated for shape and content before use in logic, rendering, or decisions. A compromised external service can return unexpected types or malicious content.

When should I use discriminated unions in TypeScript interfaces?▼

Use discriminated unions when a value has distinct variants with different fields, such as task statuses. A shared discriminator field like 'type' gives consumers automatic type narrowing in switch statements.