메뉴
Use when designing a new HTTP/GraphQL API endpoint, evolving an existing one, writing or reviewing an OpenAPI / GraphQL schema, or "/design-api". Produces a contract-first design with request/response shapes, error model, and versioning notes before any code is written.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when reviewing a backend HTTP / GraphQL handler for validation, authz, errors, performance, observability, and security, or "/backend-review". Produces a structured review with file:line citations.
Use when running a cloud security posture scan (CSPM) on AWS, Azure, or GCP using prowler, scout-suite, or checkov, or "/cloud-scan". Requires read-only credentials; produces CIS-benchmark-aligned findings with remediation.
Use when scanning a container image or Dockerfile for vulnerabilities, misconfigurations, and best-practice violations using trivy, dockle, or hadolint, or "/image-scan". Flags base-image CVEs, root user, missing healthchecks, and bloat.
Use when running an authorized non-intrusive DAST baseline scan (OWASP ZAP baseline, nuclei, nikto) against a web app or API endpoint you own, or "/dast". Requires explicit authorization; refuses unowned targets.
Use when handed a stack trace, error log, or "this is broken" with a paste of output, and asked to find the root cause across frontend, backend, or DB tiers, or "/debug-trace". Produces a hypothesis tree, the evidence supporting each branch, and the next diagnostic step.
Use when scanning a project's third-party dependencies for known CVEs across npm, pip, Go, Maven, Cargo, etc., or "/dep-scan". Runs trivy, npm audit, pip-audit, govulncheck, or osv-scanner and produces a prioritized fix list.
| name | design-api-contract |
| description | Use when designing a new HTTP/GraphQL API endpoint, evolving an existing one, writing or reviewing an OpenAPI / GraphQL schema, or "/design-api". Produces a contract-first design with request/response shapes, error model, and versioning notes before any code is written. |
| tools | ["cursor","claude","copilot"] |
Clarify the resource and operation. One verb per use case:
GET /resources, POST /resources, GET /resources/{id}, PATCH /resources/{id}, DELETE /resources/{id}.query, mutation, subscription — name them <verb><Noun> (createOrder, not orderCreate).Define the request shape: path / query / body params with types and constraints, required vs optional, defaults, validation rules (length, regex, enum, range).
Define the success response shape: status code (200 / 201 / 204), full body schema, pagination shape (cursor preferred over offset for large sets).
Define the error model:
{ error: { code, message, details? } }.code the client may receive — UI must handle each.Authentication & authorization: scope/role/ownership rule. Rate limits (per user / per IP / per tenant). Idempotency keys for unsafe creates.
Performance & caching: P95 latency budget. Cache-Control, ETag, If-None-Match where relevant. N+1 risk for the implementer.
Versioning & evolution: additive optional fields only on existing version; breaking changes require a new version. Document deprecation path for any field you might remove.
Generate the spec. Output as OpenAPI 3.1 YAML or GraphQL SDL. The spec is the source of truth; types on both tiers are generated from it.
## API Contract — <verb> <resource>
**Style:** REST | GraphQL
**Auth:** <scope/role>
**Rate limit:** <n req/min>
**P95 budget:** <ms>
### Request
```yaml
# path / query / body
# 200 body
| Status | code | When |
|---|---|---|
| 400 | VALIDATION_FAILED | … |
| 409 | DUPLICATE_ORDER | … |
## Guardrails
- Do NOT write handler code in this skill — output the contract only.
- Do NOT invent fields not justified by the user story; lean minimal.
- Reject `200 OK` with `{ "error": ... }` patterns — use proper status codes.
- Reject leaking internal error messages (stack traces, SQL errors) into the response body.
- If the contract conflicts with an existing endpoint's conventions, flag it and propose the consistent option.
- If the auth model is unclear, **ask** before designing — don't assume "anyone authenticated".