api-design

Designs and reviews public TypeScript, React, and React Native library APIs.

172|8|Updated Apr 13, 2026
One-click install
npx skills add https://github.com/margelo/react-native-skills --skill api-design-margelo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-design
Source: https://github.com/margelo/react-native-skills/tree/main/skills/api-design
Command: npx skills add https://github.com/margelo/react-native-skills --skill api-design-margelo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Public library APIs often ship with inconsistent naming, nullable field clusters, ambiguous error behavior, and platform-specific leaks that are hard to fix after release. This Skill provides a structured rule set for designing and reviewing predictable public API surfaces before implementation locks them in. ## Core Features & Use Cases - API Shape Rules: Enforces single sources of truth, option objects, discriminated unions, and explicit lifecycle handles instead of boolean clusters and half-initialized objects. - Async, Events, and React Guidance: Defines when to use Promises versus listener subscriptions, how to return cleanup handles, and how to layer hooks over imperative cores. - Error and Platform Design: Standardizes throwing real Error objects, modeling cross-platform capabilities, and avoiding workaround APIs baked into public contracts. - Use Case: Before publishing a React Native barcode scanning library, run this Skill to review the exported TypeScript surface, split scanner variants into separate capability APIs, and verify JSDoc documentation contracts. ## Quick Start Ask the assistant to review the public API of your TypeScript or React Native library using the api-design skill before implementation.

Frequently Asked Questions about api-design

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

FAQPage Schema
How do I design a public API for a React Native library?

Sketch the user-facing TypeScript API first, write realistic call-site examples including error and cleanup paths, then check the surface against rules for option objects, discriminated unions, and cross-platform capabilities. Verify the exported types with the repo's typecheck and lint tooling before implementing internals.

When should a library use Promises versus listener APIs?

Use Promises for one-shot async work such as permissions, I/O, or capture. Use listener registration methods that return a subscription object with an idempotent remove function for repeated events, so each caller owns its own cleanup.

Should TypeScript libraries use string literal unions or enums?

Prefer string literal unions over runtime enums unless consumers need a runtime value. For public string literal unions, use lowercase kebab-case values such as 'manual-input' rather than camelCase.

How should a cross-platform API handle iOS and Android differences?

Design cross-platform capability concepts instead of mirroring native APIs one-to-one. Expose runtime capability fields like supportedFormats arrays rather than freezing platform support matrices into the type shape, and throw only when ignoring an option would violate user intent.

When should I avoid a JS wrapper over a Nitro HybridObject?

Avoid JS or TS facades over public Nitro HybridObjects by default; export the imperative API as defined in the .nitro.ts spec. Use wrappers only for intentionally higher-level APIs such as React hooks, components, or when the HybridObject is an internal implementation detail.