api-and-interface-design

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

1|Updated May 29, 2026
One-click install
npx skills add https://github.com/memasanz/agent-harness --skill api-and-interface-design-memasanz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-and-interface-design
Source: https://github.com/memasanz/agent-harness/tree/main/.github/skills/api-and-interface-design
Command: npx skills add https://github.com/memasanz/agent-harness --skill api-and-interface-design-memasanz

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 and contract-first development. ## Core Features & Use Cases - Contract-First Design: Define TypeScript interfaces, REST endpoints, and error schemas before implementation, with consistent error semantics across all endpoints. - Boundary Validation Patterns: Enforce validation at system edges (API routes, forms, third-party responses) while trusting internal typed code. - Backward-Compatible Evolution: Apply additive-only changes, pagination standards, discriminated unions, and branded ID types to prevent breaking consumers. - Use Case: When creating a new REST endpoint for a task management feature, use this Skill to define the typed input/output contract, standard error shape, pagination scheme, and naming conventions before writing any handler code. ## Quick Start Use the api-and-interface-design skill to design a versioned REST API contract with typed inputs, outputs, and error responses for a new tasks resource.

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?

Design REST APIs for extension rather than modification: add only optional fields, never change existing field types or remove fields, and paginate list endpoints from the start. Follow the One-Version Rule by extending a single API version instead of maintaining parallel versions.

What is the best way to structure API error responses?

Use one consistent error format across all endpoints: a machine-readable code, a human-readable message, and optional details. Map errors to standard HTTP status codes like 400 for invalid data, 404 for missing resources, 409 for conflicts, and 422 for validation failures.

Where should input validation happen in an application?

Validate only at system boundaries where external input enters: API 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 API responses are untrusted data and must be validated before use in any logic or rendering. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.

When should I use PATCH instead of PUT for updates?

Use PATCH for partial updates where only provided fields change, which is what clients typically need. PUT requires sending the full object every time, making it fragile for resources with many fields or server-generated values.

What are the limitations of relying on API documentation alone?

Under Hyrum's Law, all observable behaviors become de facto contracts once users depend on them, regardless of documentation. Types and schemas are the real documentation, so define them first and treat every public behavior as a commitment.