api-and-interface-design

Designs stable REST, GraphQL, and TypeScript interfaces with consistent contracts and error semantics.

665|3|Updated Sep 12, 2026
One-click install
npx skills add https://github.com/rizqinrr/viserys-agent --skill api-and-interface-design-rizqinrr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-and-interface-design
Source: https://github.com/rizqinrr/viserys-agent/tree/main/skills/api-and-interface-design
Command: npx skills add https://github.com/rizqinrr/viserys-agent --skill api-and-interface-design-rizqinrr

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 unsafe retries create breaking changes and duplicate side effects that are expensive to fix later. ## Core Features & Use Cases - Contract-First Design: Define typed input/output schemas, discriminated unions, and branded ID types before implementation so the contract acts as the spec. - Consistent Error Semantics: Enforce a single error shape with machine-readable codes and correct HTTP status mapping across all endpoints. - Idempotency Key Handling: Implement atomic key claiming via unique constraints, payload hash guards, in-flight duplicate strategies, and retention aligned with retry windows. - Use Case: When adding a new payments endpoint, use this Skill to design the REST resource layout, define the TypeScript request/response types, and implement idempotency-key handling so client retries never double-charge. ## Quick Start Use the api-and-interface-design skill to design a versioned REST endpoint for creating tasks with typed contracts and idempotency-key support.

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 by adding only optional fields, never changing or removing existing ones. Use plural-noun resource URLs, PATCH for partial updates, and pagination on list endpoints from the start so growth never forces a breaking change.

How to implement idempotency keys for payment or mutation endpoints?

Implement idempotency keys by inserting the key in one atomic operation guarded by a unique constraint, then storing the result against it. Reject the same key with a different payload, and set key retention longer than the longest retry path including dead-letter replays.

Where should input validation happen in an API?

Input validation belongs at system boundaries: API route handlers, form submissions, environment loading, and third-party response parsing. 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 updates because it accepts partial objects and only changes provided fields. PUT requires sending the full object every time, which is fragile for clients and increases the risk of overwriting concurrent changes.

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

Hyrum's Law states that all observable behaviors of an API will be depended on by someone, regardless of the documented contract. It means every public behavior is a commitment, so avoid leaking implementation details and plan deprecation at design time.