api-design-skill

Designs and reviews REST, GraphQL, RPC, event, and webhook API contracts.

1|Updated Aug 7, 2025
One-click install
npx skills add https://github.com/zzafergok/arktos --skill api-design-skill-zzafergok
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: api-design-skill
Source: https://github.com/zzafergok/arktos/tree/main/.agent/skills/api-design-skill
Command: npx skills add https://github.com/zzafergok/arktos --skill api-design-skill-zzafergok

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams building APIs often ship inconsistent, insecure, or breaking contracts that frustrate consumers and force costly migrations. This Skill guides the design, review, and evolution of API contracts so they stay consistent, secure, observable, and compatible with their consumers. ## Core Features & Use Cases - Contract-First Design: Models domain resources and operations from consumer needs before choosing routes or framework code, with stable identifiers, explicit types, and clear error semantics. - Protocol-Specific Guidance: Covers REST semantics and caching, GraphQL schema ownership and cost limits, event/webhook schema evolution and delivery guarantees, and streaming/RPC cancellation and flow control. - Compatibility Management: Defines additive-change strategies, breaking-change migration paths, parallel contract operation, and versioning criteria. - Use Case: When adding a new payments endpoint to an existing REST API, use this Skill to define pagination, idempotency keys, error codes, and an OpenAPI contract that matches existing conventions before writing any controller code. ## Quick Start Ask the AI to design a versioned REST contract for a new orders resource including pagination, idempotency, and error codes.

Frequently Asked Questions about api-design-skill

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

FAQPage Schema
How do I design a REST API contract before writing code?▼

Start from consumer needs and domain behavior, then model resources and operations with stable identifiers and explicit types. Define filtering, sorting, pagination, error codes, and authentication before choosing route names or framework code.

How to handle breaking changes in an API without disrupting consumers?▼

Prefer additive changes that preserve meaning. For breaking changes, inventory consumers, provide a migration path, run old and new contracts in parallel when justified, observe adoption, and define removal criteria before versioning.

When should I use cursor pagination instead of offset pagination?▼

Use cursor pagination when collections change during traversal or when offsets become costly at scale. Offset pagination can skip or duplicate items in frequently mutated collections, while cursors remain stable.

What should an API error response include?▼

Error responses should include stable machine-readable codes, safe user-facing messages, and correlation identifiers for debugging. Never expose stack traces, queries, secrets, or provider internals to consumers.

How do I make API mutations safe to retry?▼

Specify idempotency, concurrency control, and duplicate handling for each mutation. Use idempotency keys for externally retried operations where duplicate effects would be harmful, such as payment creation.

What are the key concerns when designing webhooks?▼

Webhook design requires schema evolution rules, ordering and replay semantics, signature verification, delivery attempt tracking, deduplication, and consumer lag monitoring to ensure reliable event delivery.