| name | design-api |
| description | Produces a contract-first interface spec before implementation, covering OpenAPI/Swagger, AsyncAPI, and GraphQL schemas. Use when asked to design an API contract, endpoints, schemas, request/response shapes, or "what should the API look like?" |
| license | Apache-2.0 |
| metadata | {"author":"Oleg Shulyakov","version":"1.1.3","source":"github.com/olegshulyakov/agent.md","catalog":"software-engineering","category":"api","tags":["design","api","contract"]} |
design-api
Produce a contract-first API specification. Route to the right reference, load only that file, and output the finished contract in the requested format.
Route the Work
| User signal | Load | Output |
|---|
| REST, HTTP, CRUD, endpoints, resources, OpenAPI, Swagger | references/openapi.md | OpenAPI 3.1 YAML |
| Events, messages, pub/sub, Kafka, RabbitMQ, AMQP, WebSocket event streams | references/asyncapi.md | AsyncAPI 2.6 YAML |
| GraphQL, schema, queries, mutations, subscriptions, resolvers | references/graphql.md | GraphQL SDL plus operation notes |
| Ambiguous API design request | references/openapi.md | OpenAPI 3.1 YAML, with the assumption stated once |
If the prompt mixes styles, produce separate contract sections only when both are clearly required. Otherwise choose the primary style from the user's nouns and verbs.
Shared Rules
Extract resources, operations, consumers, auth, data ownership, pagination, versioning, idempotency, and error behavior from the prompt. If details are missing, make conservative assumptions and mark them with [assumed]; ask one question only when a missing decision would change the contract shape.
Always produce concrete names and fields from the domain. Do not leave bracket placeholders, empty schemas, TODOs, or "domain-specific fields go here" comments in the final contract.
Use stable public identifiers: UUIDs for externally visible resource IDs, ISO 8601 timestamps, explicit enum values, and consistent error/event envelopes. Include examples only when they clarify the contract without bloating it.
Boundaries
This skill designs an API contract. It does not generate server code, client SDKs, implementation patterns, or reference documentation for an already-built API unless the user explicitly asks for those after the contract.
Verification
Check that the final contract is concrete, syntactically plausible for the selected format, and free of placeholders, empty schemas, and unmarked assumptions.
