메뉴
Contract-first API design. Use when asked to design an API contract, OpenAPI/Swagger spec, AsyncAPI event contract, GraphQL schema, endpoints, schemas, request/response shapes, or "what should the API look like?" Produces an interface spec before implementation.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Review any artifact and output results in a Retrospective board format — what is well, what is bad, what should be improved, what to change. Use when the user says "review", "critique", "evaluate", "what's wrong with", "compare", or passes a skill, rule, doc, spec, code, diff, or pull request for assessment. Works on a single artifact, an artifact against a reference, a diff or PR, or two artifacts side by side.
Compare options and recommend a direction. Use for decision requests like "choose", "which option", "tradeoffs", "recommend", "should we", and option selection with criteria, risks, and reversibility.
Organize material into meaningful groups. Use for classification requests like "categorize", "group", "cluster", "sort", "taxonomy", "organize these", and grouping by criteria, priority, dependency, similarity, or abstraction level.
Explain any knowledge topic simply and accurately. Use for explanation requests like "explain X", "why/how/what is X?", concepts, science, definitions, code, design, architecture, and walkthroughs.
Investigate local repository, document, and attached-artifact context. Use for local investigation requests like "investigate", "find where", "understand this repo", "trace", and local-context research; do not use for web search.
Manage active work across people, agents, tasks, dependencies, blockers, and handoffs. Use for coordination requests like "manage this work", "lead this", "assign", "delegate", "track blockers", "status", "handoff", and multi-workstream execution.
| name | design-api |
| description | Contract-first API design. Use when asked to design an API contract, OpenAPI/Swagger spec, AsyncAPI event contract, GraphQL schema, endpoints, schemas, request/response shapes, or "what should the API look like?" Produces an interface spec before implementation. |
| license | MIT |
| tags | ["design","api","contract"] |
| metadata | {"author":"Oleg Shulyakov","version":"1.1.1","source":"github.com/olegshulyakov/agent.md","catalog":"software-team-roles","category":"api"} |
Produce a contract-first API specification before implementation code exists. Route to the right reference, load only that file, and output the finished contract in the requested format.
| 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.
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.
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.
Check that the final contract is concrete, syntactically plausible for the selected format, and free of placeholders, empty schemas, and unmarked assumptions.
