api-design

Guides API design decisions using caller-count necessity checks and type-safe interface patterns.

96|8|Updated Aug 13, 2026
One-click install
npx skills add https://github.com/pingfanfan/hello-dsh --skill api-design-pingfanfan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: api-design
Source: https://github.com/pingfanfan/hello-dsh/tree/main/examples/skills/api-design
Command: npx skills add https://github.com/pingfanfan/hello-dsh --skill api-design-pingfanfan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Public APIs are easy to add but hard to remove, and speculative generalization leads to unused, undeletable surface area. This Skill provides judgment criteria for deciding whether an interface should exist and how to design it so misuse is caught at compile time rather than in production. ## Core Features & Use Cases - Necessity Judgment: Decides whether a new public method or data structure is justified based on the number of real callers, blocking speculative generalization. - Type-Safe Design Patterns: Shows how to make illegal states unrepresentable using branded types, discriminated unions, and named parameter objects in TypeScript. - Error and Evolution Rules: Defines when errors must be distinguishable by callers and prescribes a four-step migration path (add new, coexist, migrate, remove old) for breaking changes. - Use Case: When adding a public method to a shared service like a session manager, use this Skill to check whether the single internal caller should instead receive a private capability closure at construction time. ## Quick Start Ask the AI to review your proposed public interface or new module method using the api-design skill to check necessity, parameter design, and error distinguishability.

Frequently Asked Questions about api-design

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

FAQPage Schema
How do I decide whether to add a new public API method?▼

Count the real callers. Zero callers means do not add it; one internal caller means pass a private capability closure at construction instead; two or more callers with consistent usage justifies a public API. Speculative future needs are not a valid reason.

How to design TypeScript function parameters to prevent misuse?▼

Use branded types like AccountId instead of raw strings so swapped arguments fail compilation, and use named object parameters once you exceed three arguments. Avoid boolean flags; prefer options objects like { inline: true } or split into two functions.

What is the best way to model success and error states in TypeScript?▼

Use a discriminated union like { ok: true; data: T } | { ok: false; error: Error } so illegal states such as ok: true with undefined data cannot be expressed. This beats a flat interface with optional fields.

When should errors be distinguishable by callers?▼

Errors must be distinguishable whenever the caller needs to react differently to each failure type, using typed errors like NotFoundError rather than message matching. If all failures get the same handling, one generic error is sufficient.

How do I change an existing API without breaking callers?▼

Follow four steps: add the new interface, let both coexist, migrate all callers, then remove the old one. Adding optional fields is safe, but adding required fields, tightening parameter types, or widening return types is breaking.