菜单
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?"
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Scans Jira for stale issues, duplicates, and missing fields, then fixes what the user approves. Use when the user says the board is a mess, asks for a backlog grooming pass, wants to clean up Jira, or asks about stale/duplicate tickets before sprint planning.
The front door to this plugin. Listens to what the user needs right now — vague or specific — and routes them to the right skill. Trigger whenever the user asks "what can you do," "help me with the team/board/sprint," "what should I focus on," or any open-ended project-management request that doesn't clearly match a single skill.
Update, create, or reprioritize the team's roadmap. Use when adding a new initiative and deciding what moves to make room, shifting priorities after new information comes in, moving timelines due to a dependency slip, or building a Now/Next/Later view from Jira epics.
Closes out a 2-week sprint — reconciles planned vs. completed scope, flags spillover and scope creep, writes a retro-ready summary, and gives a heads-up on the next sprint's readiness. Use when the user says the sprint is ending, asks for a sprint report, wants retro prep, or asks what's carrying over to next sprint.
Plan the next 2-week sprint — scope work from the Jira backlog, estimate team capacity (accounting for PTO), set a sprint goal, and draft a sprint plan. Use when kicking off a new sprint, sizing the backlog against team availability, deciding what's P0 vs. stretch, or handling carryover flagged by `sprint-close`.
Generates a one-page weekly status brief from Jira — sprint burndown, what shipped, what's blocked, and the week ahead. Built for a Scrum team running 2-week sprints. Use when the user asks for a status update, standup summary, sprint check-in, or "what's the team working on."
| 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"]} |
Produce a contract-first API specification. 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.
