api-and-interface-design

Designs stable REST APIs, TypeScript contracts, and module boundaries with consistent error semantics.

Updated Jul 22, 2026
One-click install
npx skills add https://github.com/Chau165/local_skill --skill api-and-interface-design-chau165
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-and-interface-design
Source: https://github.com/Chau165/local_skill/tree/main/codex/skills/api-and-interface-design
Command: npx skills add https://github.com/Chau165/local_skill --skill api-and-interface-design-chau165

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Poorly designed interfaces create breaking changes, inconsistent error handling, and hidden dependencies that break consumers. This Skill guides the design of stable APIs and module boundaries that are hard to misuse, applying principles like Hyrum's Law, contract-first design, and the One-Version Rule. ## Core Features & Use Cases - Contract-First Design: Define typed interfaces before implementation, with input/output separation, discriminated unions, and branded ID types in TypeScript. - REST API Patterns: Standard conventions for resource naming, pagination, filtering, partial updates (PATCH), and consistent error response shapes with proper HTTP status codes. - Idempotency Implementation: Detailed guidance on idempotency keys, atomic claiming via unique constraints, payload guarding, in-flight duplicate handling, and retention windows. - Use Case: When creating a new REST endpoint for a task management service, use this Skill to define the typed contract, error format, pagination scheme, and idempotency behavior before writing any handler code. ## Quick Start Use the api-and-interface-design skill to review my new REST endpoint design for consistency, pagination, and idempotency.

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. Define the contract first with typed input and output schemas, and plan deprecation paths before removing any observable behavior.

How to implement idempotency keys for payment or POST endpoints?

Accept a client-generated Idempotency-Key header and claim it atomically using a database unique constraint, not a check-then-insert. Reject reused keys with different payloads, decide how in-flight duplicates are handled (409, wait, or 202), and retain keys longer than the longest retry path.

Where should input validation happen in an API?

Validate only at system boundaries: API route handlers, form submissions, external service responses, and environment configuration. Internal functions that share type contracts should trust already-validated data rather than re-validating.

Should I use PUT or PATCH for updating resources?

Use PATCH for partial updates where only provided fields change, which matches what clients actually need. PUT requires sending the full object every time and increases the risk of accidentally overwriting fields.

What is Hyrum's Law and why does it matter for API design?

Hyrum's Law states that all observable behaviors of a system will be depended on by someone, regardless of the documented contract. It means every public behavior, including undocumented quirks and error text, is a de facto commitment, so design intentionally about what you expose.