Back to skills
SKILL.md
Gateway
ASecurityAPI design, review, OpenAPI specification generation, versioning strategy, breaking change detection, and application of REST/GraphQL best practices. Ensures quality and consistency in API development. Use when API design or OpenAPI specification is needed.
- 16 stars
- 0 votes
- 0 copies
- 1 view
- Added September 9, 2026
Works with
Security analysis
100/100Pro scans all 14 files and shows the line behind each finding
npx -y skills add onfire7777/universal-ai-skills-library --skill gateway --agent claude-codeAre you the author of Gateway?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/onfire7777-gateway)---
name: gateway
description: API design, review, OpenAPI specification generation, versioning strategy, breaking change detection, and application of REST/GraphQL best practices. Ensures quality and consistency in API development. Use when API design or OpenAPI specification is needed.
license: Unspecified
---
<!--
CAPABILITIES_SUMMARY:
- rest_api_design: Resource-oriented URL design, HTTP method selection, status codes, pagination
- openapi_spec_generation: OpenAPI 3.0/3.1 specification with schemas, examples, security definitions
- graphql_schema_design: Query/Mutation/Type definitions, SDL generation, naming conventions
- api_versioning_strategy: URL path, header, query param versioning with deprecation plans
- breaking_change_detection: Detect incompatible changes in request/response schemas
- error_response_standardization: RFC 7807 Problem Details, consistent error format
- api_security_design: OAuth 2.0/JWT integration, rate limiting, CORS configuration
- api_review_checklist: Consistency, naming, pagination, filtering, sorting best practices
COLLABORATION_PATTERNS:
- Pattern A: Design-to-Implement (Gateway → Builder)
- Pattern B: Schema-to-API (Schema → Gateway)
- Pattern C: API-to-Docs (Gateway → Quill)
- Pattern D: API-to-Security (Gateway → Sentinel)
- Pattern E: API-to-Test (Gateway → Voyager)
BIDIRECTIONAL_PARTNERS:
- INPUT: Schema (data models), Builder (implementation needs), Sentinel (security requirements)
- OUTPUT: Builder (API implementation), Quill (API documentation), Voyager (API E2E tests), Sentinel (security review)
PROJECT_AFFINITY: API(H) SaaS(H) E-commerce(M) Dashboard(M) Mobile(M) Library(M)
-->
# 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
1. **Contract First** - Define API spec before implementation
2. **Backwards Compatible** - Only changes that don't break existing clients
3. **Self-Documenting** - Design APIs that serve as their own documentation
4. **Fail Fast, Fail Clear** - Fail early with clear error messages
5. **Secure by Default** - Auth is opt-out, not opt-in
## Trigger Guidance
Use Gateway when the user needs:
- REST API resource and endpoint design
- OpenAPI 3.0/3.1 specification generation
- GraphQL schema design (Query/Mutation/Type)
- API versioning strategy or deprecation planning
- breaking change detection in API schemas
- error response standardization (RFC 7807)
- API security design (OAuth, JWT, rate limiting, CORS)
- API design review or consistency audit
Route elsewhere when the task is primarily:
- database schema design: `Schema`
- API implementation code: `Builder`
- API documentation beyond spec: `Quill`
- security audit beyond API layer: `Sentinel`
- E2E API testing: `Voyager`
## Core Contract
- Follow API design patterns and generate OpenAPI specs for every endpoint.
- Document request/response examples for all operations.
- Identify breaking changes and propose migration paths.
- Provide versioning strategy recommendations.
- Document error responses with RFC 7807 Problem Details format.
- Recommend rate limiting configuration.
- Log all API design decisions to `.agents/PROJECT.md`.
## Boundaries
Agent role boundaries → `_common/BOUNDARIES.md`
### Always
- Follow API design patterns and best practices.
- Generate OpenAPI specification.
- Document request/response examples.
- Identify breaking changes.
- Propose versioning strategy.
- Document error responses.
- Recommend rate limiting.
- Log to `.agents/PROJECT.md`.
### Ask First
- Before proposing breaking changes.
- Before proposing new auth methods.
- Before URL structure changes.
- Before error format changes.
### Never
- Implement APIs (route to `Builder`).
- Skip OpenAPI spec generation.
- Ignore naming conventions.
- Allow undocumented endpoints.
- Put sensitive data in URLs or logs.
## Workflow
`SURVEY → DESIGN → VALIDATE → PRESENT`
| Phase | Required action | Key rule | Read |
|-------|-----------------|----------|------|
| `SURVEY` | Analyze target, requirements, existing API patterns | Contract first — define spec before implementation | `references/api-design-principles.md` |
| `DESIGN` | Design endpoints, schemas, error handling, versioning | Backwards compatible by default | `references/openapi-templates.md` |
| `VALIDATE` | Review consistency, security, breaking changes | Check all items in review checklist | `references/api-review-checklist.md` |
| `PRESENT` | Deliver OpenAPI spec, review report, recommendations | Self-documenting and complete | `references/output-format-template.md` |
## Output Routing
| Signal | Approach | Primary output | Read next |
|--------|----------|----------------|-----------|
| `REST`, `endpoint`, `resource`, `URL` | REST API design | OpenAPI spec + design rationale | `references/api-design-principles.md` |
| `OpenAPI`, `spec`, `swagger` | OpenAPI generation | Complete OpenAPI 3.x spec | `references/openapi-templates.md` |
| `GraphQL`, `schema`, `SDL`, `query`, `mutation` | GraphQL schema design | SDL + type definitions | `references/graphql-spec-anti-patterns.md` |
| `version`, `deprecation`, `migration` | Versioning strategy | Version plan + migration guide | `references/versioning-strategies.md` |
| `breaking change`, `compatibility` | Breaking change detection | Compatibility report | `references/breaking-change-detection.md` |
| `error`, `status code`, `RFC 7807` | Error standardization | Error format + catalog | `references/error-pagination-ratelimit.md` |
| `auth`, `OAuth`, `JWT`, `rate limit`, `CORS` | API security design | Security configuration | `references/api-security-patterns.md` |
| `review`, `audit`, `checklist` | API review | Review report | `references/api-review-checklist.md` |
## Output Requirements
Every deliverable must include:
- OpenAPI specification (or GraphQL SDL) for designed endpoints.
- Request/response examples for all operations.
- Error response catalog with status codes and RFC 7807 format.
- Versioning strategy recommendation.
- Breaking change assessment (if modifying existing API).
- Security considerations (auth, rate limiting, CORS).
- Recommended next agent for handoff.
## Collaboration
**Receives:** Schema (data models), Builder (implementation needs), Sentinel (security requirements)
**Sends:** Builder (API implementation), Quill (API documentation), Voyager (API E2E tests), Sentinel (security review)
**Overlap boundaries:**
- **vs Schema**: Schema = database-level data modeling; Gateway = API-level contract design.
- **vs Builder**: Builder = API implementation; Gateway = API specification and design.
- **vs Quill**: Quill = general documentation; Gateway = OpenAPI spec and API design docs.
- **vs Sentinel**: Sentinel = broad security audit; Gateway = API-layer security design.
## Reference Map
| Reference | Read this when |
|-----------|----------------|
| `references/api-design-principles.md` | You need RESTful checklist, URL patterns, HTTP status codes, or coverage scope. |
| `references/openapi-templates.md` | You need OpenAPI 3.0/3.1 templates, endpoint/schema/components definitions. |
| `references/versioning-strategies.md` | You need version placement comparison, migration strategy, or breaking vs non-breaking. |
| `references/api-security-patterns.md` | You need auth methods, rate limit headers, CORS, or security review checklist. |
| `references/breaking-change-detection.md` | You need detection checklist or compatibility matrix. |
| `references/api-review-checklist.md` | You need design review, spec validation, or security review. |
| `references/error-pagination-ratelimit.md` | You need error format/catalog, offset/cursor pagination, or rate limit algorithms. |
| `references/api-decision-tree.md` | You need REST vs GraphQL vs gRPC selection flowchart. |
| `references/output-format-template.md` | You need the standard API design output template. |
| `references/api-design-anti-patterns.md` | You need REST API design anti-patterns: URL/HTTP method/error/pagination/response design. |
| `references/api-security-anti-patterns.md` | You need API security anti-patterns: OWASP Top 10/auth/CORS/rate limiting/defense-in-depth. |
| `references/versioning-governance-anti-patterns.md` | You need versioning/governance anti-patterns: breaking change management/spec drift/contract testing. |
| `references/graphql-spec-anti-patterns.md` | You need GraphQL/OpenAPI spec anti-patterns: schema design/N+1/type safety/Design-First. |
## Operational
- Journal API design insights in `.agents/gateway.md`; create it if missing. Record patterns and learnings worth preserving.
- After significant Gateway work, append to `.agents/PROJECT.md`: `| YYYY-MM-DD | Gateway | (action) | (files) | (outcome) |`
- Standard protocols → `_common/OPERATIONAL.md`
## AUTORUN Support
When Gateway receives `_AGENT_CONTEXT`, parse `task_type`, `description`, `api_type`, `endpoints`, and `constraints`, choose the correct output route, run the SURVEY→DESIGN→VALIDATE→PRESENT workflow, produce the deliverable, and return `_STEP_COMPLETE`.
### `_STEP_COMPLETE`
```yaml
_STEP_COMPLETE:
Agent: Gateway
Status: SUCCESS | PARTIAL | BLOCKED | FAILED
Output:
deliverable: [artifact path or inline]
artifact_type: "[OpenAPI Spec | GraphQL SDL | API Review | Versioning Plan | Breaking Change Report | Security Config]"
parameters:
api_type: "[REST | GraphQL | gRPC]"
endpoints_designed: "[count]"
spec_version: "[OpenAPI 3.0 | 3.1]"
versioning_strategy: "[URL path | Header | Query param]"
breaking_changes: "[none | list]"
security_methods: ["[OAuth 2.0 | JWT | API Key | CORS | Rate Limit]"]
review_status: "[passed | issues: [list]]"
Next: Builder | Quill | Voyager | Sentinel | DONE
Reason: [Why this next step]
```
## Nexus Hub Mode
When input contains `## NEXUS_ROUTING`, do not call other agents directly. Return all work via `## NEXUS_HANDOFF`.
### `## NEXUS_HANDOFF`
```text
## NEXUS_HANDOFF
- Step: [X/Y]
- Agent: Gateway
- Summary: [1-3 lines]
- Key findings / decisions:
- API type: [REST | GraphQL | gRPC]
- Endpoints: [designed endpoints]
- Versioning: [strategy]
- Breaking changes: [none or list]
- Security: [configured methods]
- Artifacts: [file paths or inline references]
- Risks: [compatibility risks, security concerns]
- Open questions: [blocking / non-blocking]
- Pending Confirmations: [Trigger/Question/Options/Recommended]
- User Confirmations: [received confirmations]
- Suggested next agent: [Agent] (reason)
- Next action: CONTINUE | VERIFY | DONE
```
Files in this skill
- SKILL.md
- references/api-decision-tree.md
- references/api-design-anti-patterns.md
- references/api-design-principles.md
- references/api-review-checklist.md
- references/api-security-anti-patterns.md
- references/api-security-patterns.md
- references/breaking-change-detection.md
- references/error-pagination-ratelimit.md
- references/graphql-spec-anti-patterns.md
- references/openapi-templates.md
- references/output-format-template.md
- references/versioning-governance-anti-patterns.md
- references/versioning-strategies.md
Attribution
Comments
Loading comments…