design-an-api
FeaturedDesigns the contract for an API change inside one codebase — a component's props, a function surface, URL or query parameters, an event payload, or a module boundary — through a discovery pass, an options document with one recommendation, a question round, and an adversarial validation round, with every element of the contract justified from one stated goal. Use when you want to design, shape, decide, or nail down an interface, contract, signature, or API change for a capability you can already describe, sized for roughly one pull request. Produces a design document and changes no code. Does not specify what a feature should do — use plan-a-feature. Does not plan delivery or sequencing — use plan-implementation. Does not assess the architecture of existing code — use architectural-analysis. Does not write the code — use tdd. Does not restructure existing code — use refactor. Runs its rounds without pausing for review; to review each round as it lands, use pairing.
Install
Quality Score: 94/100
Skill Content
Details
- Author
- testdouble
- Repository
- testdouble/han
- Created
- 4 months ago
- Last Updated
- today
- Language
- Shell
- License
- MIT
Integrates with
Bundled in these plugins
Similar Skills
Semantically similar based on skill content — not just same category
api-design
Design a public contract (HTTP/REST, RPC, webhook, CLI, or library API) before building it — consumers & compatibility promise first, resource model in the domain language, the contract checklist (error model, pagination, idempotency, partial updates, versioning), worked request/response examples including errors, and a consumer's-eyes review pass. TRIGGER when: designing or extending an API/endpoint/webhook/CLI surface or a library's public interface — "design the API", "какой сделать контракт/эндпоинт", adding endpoints consumers outside this repo will call. DO NOT TRIGGER when: designing an internal module seam (use /codebase-design), or the contract exists and the question is shipping a change to it safely (use /rollout).
plan-a-feature
Builds a feature specification from scratch through a relentless, evidence-based interview that walks the design tree decision-by-decision, resolving dependencies as it goes. Use when the user wants to plan, design, scope, specify, or flesh out a new feature, capability, or system behavior before implementation. Produces a feature specification focused on system behaviors, not implementation detail. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not document already-built features — use project-documentation. Does not design the contract for an interface — use design-an-api. Does not research open-ended options before there is a feature to specify — use research.
pairing
Build work collaboratively in reviewable pieces, handing each piece back for review before starting the next, so the person stays in the lead and steers while the work happens instead of reviewing a finished result. Use when someone says to pair with them on something, asks to collaborate rather than direct, wants to review as it goes, or wants to guide the work piece by piece — on code, on a design decision, or on writing. For a test-first build it runs tdd, for restructuring it runs refactor, for an interface contract it runs design-an-api, and for plan work it runs iterative-plan-review or plan-implementation, each collaboratively; invoke any of those directly instead to run it straight through without pausing. Does not pace someone through code that already exists and builds nothing — use code-walkthrough. Does not explain, summarize, or research something instead of producing it — use code-overview or research.