void-api-and-interface-design

Designs contract-first public interfaces with minimal surface, typed errors, and SemVer versioning.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Public interfaces become permanent promises the moment a consumer depends on them, yet teams routinely leak implementation details, expose unstable types, and ship breaking changes without warning. This Skill enforces contract-first design so every public API — package exports, HTTP/REST, RPC/tRPC, SDKs, module boundaries — is minimal, hard to misuse, and versioned before implementation begins. ## Core Features & Use Cases - Contract-First Design: Write signatures, input/output types, error sets, and invariants before any implementation, making the contract reviewable on its own. - Misuse-Resistant Surfaces: Replace positional booleans and bare primitives with named options objects, branded types, and discriminated unions so invalid calls fail at compile time. - Versioning & Deprecation Discipline: Apply SemVer rules with an additive-first policy and a deprecate-coexist-remove cycle for breaking changes. - Use Case: When designing a new REST endpoint or tRPC router, use this Skill to define the OpenAPI contract, a closed typed error set with stable codes, idempotency keys for mutations, and cursor pagination before writing any handler logic. ## Quick Start Ask the agent to design the public contract for a new user-creation endpoint, including input validation, typed errors, and pagination, before writing the implementation.

Frequently Asked Questions about void-api-and-interface-design

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

FAQPage Schema
How do I design a public API contract before implementation?

Write the contract first: operations and names, input types validated at the boundary, dedicated output DTOs, a closed typed error set, and invariants like idempotency and pagination. For HTTP this is an OpenAPI spec; for a package it is the exported .d.ts. Review the contract before writing any logic.

What makes an API hard to misuse in TypeScript?

Make illegal states unrepresentable using branded types and validated value objects, replace positional booleans with named options objects, and use discriminated unions instead of boolean flags. Invalid calls should fail at compile time rather than at runtime.

When is an API change breaking under SemVer?

Removing or renaming a field, narrowing an input, tightening an output, or changing an error code is breaking and requires a MAJOR version or a deprecation cycle. Additive changes like new optional fields or new operations are non-breaking MINOR releases.

Should I return database rows from my API?

No. Never leak ORM rows, DB models, or framework request objects across a public boundary. Map internal types to dedicated boundary DTOs in the adapter layer so schema changes do not silently break consumers.

How should API errors be structured for consumers?

Return a typed Result with a closed set of error variants, each carrying a stable code and HTTP status. Consumers match on codes, not message strings, and messages must never leak stack traces, SQL, internal IDs, or PII.

When should an API support idempotency keys and pagination?

Decide both at contract time. Any retryable non-GET mutation should accept an idempotency key, and any growable collection should be paginated with a stable cursor from day one, since retrofitting either is a breaking change.