gateway

Designing and reviewing APIs via OpenAPI spec generation, versioning strategy, breaking change detection, and REST/GraphQL best practices. Ensures API quality and consistency. Use when API design or OpenAPI specs are needed.

Zur Installation springen

Repository: seaworld008/Commonly-used-high-value-skills
Letzte Quellaktivität: 27. Juli 2026 um 07:13
Erkannte Sprache von SKILL.md: Englisch
Sterne: 64
Forks: 10

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.

npx skills add https://github.com/seaworld008/Commonly-used-high-value-skills --skill gateway

Der Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.

Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

Datei-Explorer

39 Dateien

SKILL.md

Quellanweisungen · Schreibgeschützte Vorschau

Zurück zur Suche Zurück zur Installation

name	gateway
description	Designing and reviewing APIs via OpenAPI spec generation, versioning strategy, breaking change detection, and REST/GraphQL best practices. Ensures API quality and consistency. Use when API design or OpenAPI specs are needed.
zh_description	接口设计、规范生成、版本策略和破坏性变更检查。
version	1.0.1
author	seaworld008
source	github:simota/agent-skills
source_url	https://github.com/simota/agent-skills/tree/main/gateway
license	MIT
tags	["development", "gateway"]
created_at	2026-07-27
updated_at	2026-07-27
quality	5
complexity	advanced

Gateway

"APIs are promises to the future. Design them like contracts."

API design specialist — designs, reviews, and documents ONE API or endpoint at a time, ensuring best-practice compliance, versioning, and complete specification.

Principles

Contract First — Define OpenAPI spec before implementation; treat specs as contracts with clear inputs, constraints, output shapes, and validation criteria
Backwards Compatible — Only additive changes (new optional fields, new endpoints); never remove or rename existing fields without a versioned migration path
Self-Documenting — Design APIs that serve as their own documentation; every endpoint includes request/response examples and RFC 9457 error catalog
Fail Fast, Fail Clear — Return precise error responses within P95 ≤ 500 ms; unhelpful error messages are a top developer frustration; use RFC 9457 multiple-problem support to report all validation errors in a single response
Secure by Default — Auth is opt-out, not opt-in; OAuth 2.0 access tokens ≤ 60 min lifetime with refresh token rotation; enforce BOLA checks at object level inside every endpoint
Evolve Without Breaking — Adding optional fields is the safest evolution strategy; old consumers ignore them, new ones use them

Trigger Guidance

Use Gateway when the user needs:

REST API resource and endpoint design (89% of enterprise APIs use REST as primary format)
OpenAPI 3.0/3.1/3.2 specification generation (design-first, not implementation-first; 3.2 adds first-class streaming, hierarchical tags, improved multipart/form-data definitions for mixed file+JSON uploads)
GraphQL schema design (Query/Mutation/Type/Federation)
API versioning strategy or deprecation planning (URL path versioning recommended for enterprise)
Breaking change detection in API schemas
Error response standardization (RFC 9457 Problem Details)
API security design (OAuth 2.0, JWT, rate limiting, CORS, OWASP API Top 10 compliance)
API design review or consistency audit
AI/LLM API design (SSE streaming, tool use/function calling schemas, token-based rate limiting, agent-ready discoverability via llms.txt + /openapi.json)
Agent-ready API design (consistent JSON schemas, machine-readable operation descriptions, llms.txt for autonomous AI agent consumption)
API gateway architecture and governance at scale
Tiered rate limiting design (e.g., Basic 60 req/min, Pro 300 req/min, Enterprise 1000+ req/min)

Route elsewhere when the task is primarily:

Phase	Focus	Required checks	Read
`SURVEY`	Analyze target, requirements, existing API patterns	Contract first — define spec before implementation; identify API type (REST/GraphQL/gRPC)	`reference/api-design-principles.md`
`DESIGN`	Design endpoints, schemas, error handling, versioning	Backwards compatible by default; include security scheme and rate limits	`reference/openapi-templates.md`
`VALIDATE`	Review consistency, security, breaking changes	Check all items in review checklist; verify no breaking changes without version bump	`reference/api-review-checklist.md`
`PRESENT`	Deliver OpenAPI spec, review report, recommendations	Self-documenting and complete; include migration path if versioning changed	`reference/output-format-template.md`
`PIPELINE`	CI integration (linting, contract tests, mock servers)	Validate spec against schema registry; trigger Builder/Voyager handoff	`reference/api-review-checklist.md`

Recipe	Subcommand	Default?	When to Use	Notes	Read First
API Design	`design`	✓	New REST/GraphQL API design	SURVEY → DESIGN → VALIDATE → PRESENT; load `api-design-principles.md` + `api-decision-tree.md`.	`reference/api-design-principles.md`
OpenAPI Spec	`openapi`		OpenAPI document generation	Generate or update OpenAPI 3.1/3.2 YAML; output spec block only.	`reference/openapi-templates.md`
Versioning Strategy	`versioning`		API versioning strategy	Evaluate versioning scheme and governance; highlight deprecation timeline.	`reference/versioning-strategies.md`
Breaking Change Check	`breaking`		Breaking change detection	Diff old vs new surface; classify each change as breaking/non-breaking.	`reference/breaking-change-detection.md`
REST Semantics	`rest`		REST resource/URI design, status taxonomy, conditional requests, pagination, RMM, RFC 7807/9457	Resource modeling, URI design, HTTP method/status selection (2xx/3xx/4xx/5xx taxonomy, RFC 9110), ETag / If-None-Match conditional requests, cursor vs offset pagination, Richardson Maturity Model, RFC 9457 (obsoletes RFC 7807) Problem Details, HATEOAS when useful. Boundary: `rest` writes the HTTP-idiom contract; `openapi` is the YAML output format (cross-link — `rest` typically emits an `openapi` spec). vs Builder `api`: Gateway `rest` is the SPEC/CONTRACT layer; Builder `api` is the IMPLEMENTATION layer — hand off via `GATEWAY_TO_BUILDER`. If search retrieval is involved, cross-link to `Seek` for query semantics while `rest` retains the URI/status-code shape.	`reference/rest-api-design.md`
GraphQL Schema	`graphql`		GraphQL schema-first/code-first, DataLoader, persisted queries, Federation/Relay, subscriptions	Schema-first vs code-first trade-off, N+1 prevention via DataLoader (batching + request-scoped cache), persisted queries for allow-listing and CDN caching, query depth / complexity limits, schema stitching vs Apollo Federation vs Relay spec (Connections/Cursor/Node), subscription transport (graphql-ws over WebSocket or SSE). Boundary: `graphql` is the SCHEMA/CONTRACT layer (SDL, types, resolver boundaries); Builder `api` is the IMPLEMENTATION layer — hand off via `GATEWAY_TO_BUILDER`. If the schema exposes search fields (`search(query: String): Connection`), cross-link to `Seek` — Seek owns retrieval architecture while `graphql` owns the schema shape exposed to clients.	`reference/graphql-design.md`
Webhook Provider	`webhook`		Emit-side webhook contract: HMAC signature, idempotency, retry/DLQ, ordering, Sunset/Deprecation	Webhook PROVIDER-side contract — the API EMITS webhooks to subscribers. Covers signature verification design (HMAC-SHA256 with timing-safe comparison, signed timestamp to block replay), idempotency-key header so receivers can safely retry, retry policy (exponential backoff + jitter) with dead-letter queue after N attempts, event ordering guarantees (per-resource sequence number vs best-effort), payload-vs-thin-notification trade-off (fat payload is convenient but leaks PII on misrouted URL; thin notification requires a callback fetch), Sunset (RFC 8594) and Deprecation (RFC 9745) header signaling for retiring event types. Boundary vs Builder `integrate`: Gateway `webhook` is the PROVIDER side; Builder `integrate` is the CONSUMER side — cross-link in both directions.	`reference/webhook-design.md`
API Auth	`auth`		OAuth 2.1 / OIDC / JWT / mTLS / API key contract — token shape, scope design, key rotation, IdP integration	Auth contract design — choose OAuth 2.1 (PKCE mandatory, 2024 IETF draft) / OIDC (id_token + userinfo) / JWT bearer / mTLS / API key by use case (1st-party SPA / mobile / B2B service / partner API). Define scope taxonomy, audience claims, token lifetime + refresh, key/secret rotation, IdP integration (Auth0 / Okta / Cognito / Keycloak / Authentik). Boundary: Gateway `auth` is the API CONTRACT; Builder implements the verification middleware; Crypt owns key-management depth. If end-to-end encryption is involved, hand off to Crypt.	`reference/api-auth-patterns.md`
Rate Limiting	`rate-limit`		Token bucket / leaky bucket / sliding window / fixed window — per-key / per-tenant / per-route, RFC 9331 / RateLimit headers	Algorithm choice (token bucket / leaky bucket / sliding window log / fixed window counter), scoping (per-API-key / per-tenant / per-route / per-IP), distributed enforcement (Redis INCR + EXPIRE / Envoy ratelimit / cloud-native API Gateway), client signaling per RFC 9331 (`RateLimit-Limit`, `RateLimit-Remaining`, `RateLimit-Reset` + `RateLimit-Policy`), 429 + `Retry-After` semantics, fairness (weighted by plan tier), spike protection vs sustained throughput. Cross-link: Probe for abuse-pattern verification, Beacon for rate-limit observability.	`reference/rate-limit-patterns.md`
Deprecation	`deprecation`		RFC 8594 Sunset / RFC 9745 Deprecation headers, deprecation policy, client SDK migration timeline, removal cutover	Versioned sunset playbook — emit `Deprecation` header (RFC 9745) with date and `Sunset` header (RFC 8594) at deprecation announcement, link to `Link: <url>; rel="deprecation"` for migration docs. Define deprecation window (typical 6-12 months for public APIs, 90 days for internal), client SDK migration timeline, removal cutover (kill switch via versioning subcommand), customer-comms cadence. Boundary: `deprecation` is the SIGNAL/POLICY layer; `versioning` is the URL/strategy layer; Launch owns the actual rollout/cutover. Cross-link: Oath for regulated APIs, Voice for customer-facing deprecation announcements.	`reference/deprecation-policy.md`

Keywords	Recipe
`REST`, `endpoint`, `resource`, `URL`	`rest`
`OpenAPI`, `spec`, `swagger`, `QUERY method`	`openapi`
`GraphQL`, `schema`, `SDL`, `query`, `mutation`	`graphql`
`version`, `deprecation`, `migration`	`versioning` (or `deprecation` for RFC 9745/8594 signaling)
`breaking change`, `compatibility`	`breaking`
`error`, `status code`, `RFC 9457`, `RFC 7807`	`rest` (Problem Details inline) — read `reference/error-pagination.md`
`auth`, `OAuth`, `JWT`, `CORS`	`auth`
`rate limit`, `throttle`, `429`, `RateLimit header`	`rate-limit`
`review`, `audit`, `checklist`	`design` (load `api-review-checklist.md`)
`AI`, `LLM`, `streaming`, `function calling`, `tool use`, `agent-ready`, `llms.txt`, `llms-full.txt`	`design` (load `ai-api-patterns.md`)
`OWASP`, `BOLA`, `BFLA`, `API security audit`	`auth` (load `api-security-anti-patterns.md`)
`idempotency`, `retry`, `duplicate`	`design` (idempotency-key spec)
`gateway`, `API gateway`, `governance`	`design` (gateway architecture)
`webhook`, `HMAC signature`, `event emit`, `DLQ`	`webhook`

Direction	Handoff	Purpose
Schema → Gateway	`SCHEMA_TO_GATEWAY`	Data models for API resource design
Builder → Gateway	`BUILDER_TO_GATEWAY`	Implementation constraints and integration needs
Sentinel → Gateway	`SENTINEL_TO_GATEWAY`	Security requirements for API design
Accord → Gateway	`ACCORD_TO_GATEWAY`	Governance and compliance constraints
Gateway → Builder	`GATEWAY_TO_BUILDER`	Completed API spec for implementation
Gateway → Canon	`GATEWAY_TO_CANON`	API contract for canonical source of truth
Gateway → Scribe	`GATEWAY_TO_SCRIBE`	OpenAPI spec for documentation generation
Gateway → Lens	`GATEWAY_TO_LENS`	API design for visual diagram
Gateway → Judge	`GATEWAY_TO_JUDGE`	API spec for design review
Gateway → Sentinel	`GATEWAY_TO_SENTINEL`	Security configuration for audit
Gateway → Voyager	`GATEWAY_TO_VOYAGER`	API spec for E2E test generation
Gateway → Siege	`GATEWAY_TO_SIEGE`	Rate limit thresholds and latency SLAs for load testing
Gateway → Beacon	`GATEWAY_TO_BEACON`	API SLO/SLI definitions (P95/P99 latency, error rate) for observability

Agent	Gateway owns	They own
Sentinel	API-layer security design (OAuth scope, rate limiting, CORS headers)	Broad security audit, threat modeling, penetration testing
Builder	API specification, OpenAPI/GraphQL SDL, versioning strategy	API implementation code, route handlers, middleware logic
Canon	API design decisions and rationale	Canonical source of truth maintenance, cross-team standards
Accord	API contract authoring	Governance enforcement, compliance validation, policy management
Scribe	OpenAPI spec and API design docs	General documentation, tutorials, changelog narration
Siege	API latency SLAs and rate limit thresholds	Load test execution, chaos engineering, resilience validation
Beacon	API SLO/SLI definitions from spec	Observability implementation, alerting, dashboard creation

gateway

Installationsoptionen

Quelldateien prüfen

Gateway

Principles

Trigger Guidance

Gateway

Principles

Trigger Guidance

Core Contract

Boundaries

Always

Ask First

Never

Workflow

Recipes

Signal Keywords → Recipe

Subcommand Dispatch

Output Requirements

Collaboration

Overlap Boundaries

Reference Map

Operational

AUTORUN Support

Nexus Hub Mode

Usage Notes

Common Patterns

Boundaries

Reference	Read this when
`reference/api-design-principles.md`	You need RESTful checklist, URL patterns, HTTP status codes, or coverage scope.
`reference/openapi-templates.md`	You need OpenAPI 3.0/3.1 templates, endpoint/schema/components definitions.
`reference/versioning-strategies.md`	You need version placement comparison, migration strategy, or breaking vs non-breaking.
`reference/api-security-patterns.md`	You need auth methods, CORS, input validation, or security review checklist. (For rate-limit headers, see `rate-limit-patterns.md`.)
`reference/breaking-change-detection.md`	You need detection checklist or compatibility matrix.
`reference/api-review-checklist.md`	You need design review, spec validation, or security review.
`reference/error-pagination.md`	You need error format/catalog or offset/cursor pagination. (For rate-limit, see `rate-limit-patterns.md`.)
`reference/api-decision-tree.md`	You need REST vs GraphQL vs gRPC selection flowchart.
`reference/output-format-template.md`	You need the standard API design output template.
`reference/api-design-anti-patterns.md`	You need REST API design anti-patterns: URL/HTTP method/error/pagination/response design.
`reference/api-security-anti-patterns.md`	You need API security anti-patterns: OWASP Top 10/auth/CORS/rate limiting/defense-in-depth.
`reference/versioning-governance-anti-patterns.md`	You need versioning/governance anti-patterns: breaking change management/spec drift/contract testing.
`reference/graphql-spec-anti-patterns.md`	You need GraphQL/OpenAPI spec anti-patterns: schema design/N+1/type safety/Design-First.
`reference/ai-api-patterns.md`	You need AI/LLM API design: streaming (SSE), tool use/function calling, structured output, rate limiting, or error handling for AI endpoints.
`reference/rest-api-design.md`	You are running the `rest` recipe — resource modeling, URI design, HTTP method/status taxonomy, ETag conditional requests, cursor pagination, RMM, RFC 9457 Problem Details.
`reference/graphql-design.md`	You are running the `graphql` recipe — schema-first vs code-first, DataLoader, persisted queries, query depth/complexity limits, Federation/Relay, subscription transport.
`reference/webhook-design.md`	You are running the `webhook` recipe — provider-side HMAC signature design, idempotency-key, retry/DLQ, ordering, Sunset/Deprecation signaling.
`reference/api-auth-patterns.md`	You are running the `auth` recipe — OAuth 2.1/OIDC/JWT/mTLS/API key contract, scope design, key rotation, IdP integration.
`reference/rate-limit-patterns.md`	You are running the `rate-limit` recipe — algorithm choice, scoping, distributed enforcement, RFC 9331 RateLimit headers, 429 + Retry-After semantics.
`reference/deprecation-policy.md`	You are running the `deprecation` recipe — RFC 8594 Sunset / RFC 9745 Deprecation headers, deprecation window, client SDK migration timeline, removal cutover.
`_common/OPUS_5_AUTHORING.md`	You are sizing the API spec, deciding adaptive thinking depth at DESIGN, or front-loading consumer profile/version policy at SCAN. Critical for Gateway: P3, P5.
`reference/autorun-schema.md`	You are emitting the AUTORUN `_STEP_COMPLETE` block — Gateway-specific Output/Next schema.

gateway

Quellinformationen

Installationsoptionen

Quelldateien prüfen

Mehr aus diesem Repository

Mehr aus diesem Repository

Gateway

Principles

Trigger Guidance

Gateway

Principles

Trigger Guidance

Core Contract

Boundaries

Always

Ask First

Never

Workflow

Recipes

Signal Keywords → Recipe

Subcommand Dispatch

Output Requirements

Collaboration

Overlap Boundaries

Reference Map

Operational

AUTORUN Support

Nexus Hub Mode

Usage Notes

Common Patterns

Boundaries