api-designer（API 设计）

API Designer

Contract-first API design across REST, GraphQL, and gRPC. Produces OpenAPI 3.1 specs, reviews existing APIs, analyzes backward compatibility, and scaffolds client code.

Canonical Vocabulary

Dispatch

Mode Menu (empty args)

Pick a number or describe what you need.

Protocol Detection

Detect the API protocol from input before entering any mode. Classification determines which conventions and patterns apply.

Detection signals:

Routing:

• Clear signal for one protocol: proceed with that protocol's conventions
• Mixed signals or ambiguous: ask user — "Which protocol? [REST / GraphQL / gRPC]"
• No protocol context (pure requirements): default to REST, note assumption

Load references/rest-conventions.md, references/graphql-patterns.md, or references/grpc-patterns.md based on detected protocol.

Mode A: Design

New API from requirements. Read references/rest-conventions.md (or protocol-specific reference).

Design Steps

1. Parse requirements — Extract resources, relationships, operations, auth needs, constraints
2. Resource modeling — Define resources with attributes, relationships, cardinality
3. Endpoint design — Map CRUD + custom operations to endpoints following protocol conventions
4. Request/response schemas — Define payloads with types, validation rules, examples
5. Auth strategy — Recommend auth approach (API key, OAuth2, JWT) based on use case
6. Error contract — Define error response format with codes, messages, detail objects
7. Pagination & filtering — Apply cursor or offset pagination, filter query patterns
8. Rate limiting — Recommend limits based on endpoint sensitivity and expected load
9. Generate spec — Output complete OpenAPI 3.1 YAML
10. Validate — Run scripts/api-spec-validator.py on generated spec

Mode B: Spec

Generate OpenAPI 3.1 from existing code.

Spec Steps

1. Scan codebase — Read route definitions, controllers, handlers, decorators
2. Extract endpoints — Map code to path + method + parameters + response types
3. Infer schemas — Build request/response schemas from type annotations or runtime types
4. Generate spec — Output OpenAPI 3.1 YAML with all discovered endpoints
5. Validate — Run scripts/api-spec-validator.py
6. Gap report — List endpoints missing descriptions, examples, or error responses

Mode C: Review

Audit existing API design. Read-only analysis.

Review Steps

1. Parse spec — Load and validate the OpenAPI document
2. Run validator — scripts/api-spec-validator.py for structural issues
3. Run endpoint matrix — scripts/api-endpoint-matrix.py for surface overview
4. Convention check — Verify naming, HTTP method usage, status codes against references/rest-conventions.md
5. Security audit — Check auth coverage, HTTPS enforcement, sensitive data exposure
6. Consistency check — Verify naming patterns, response envelope consistency, error format uniformity
7. Report — Present findings by severity (critical, warning, info) with specific fix recommendations

Mode D: Version

Versioning and deprecation strategy.

Version Steps

1. Analyze current state — Parse spec, identify version indicators
2. Recommend strategy — Compare URL path vs header vs query param versioning (load references/versioning-strategies.md)
3. Deprecation plan — Timeline, sunset headers, migration guides for deprecated endpoints
4. Version matrix — Table showing which endpoints exist in which versions
5. Migration guide template — Skeleton for consumer migration documentation

Mode E: Compat

Backward compatibility diff between two spec versions.

Compat Steps

1. Load both specs — Parse old and new OpenAPI documents
2. Run compat checker — scripts/compat-checker.py <old> <new>
3. Classify changes — Breaking vs non-breaking with change type and location
4. Impact assessment — Which consumers are affected, estimated migration effort
5. Remediation — For each breaking change, suggest backward-compatible alternatives

Mode F: SDK

Scaffold client code structure from a spec. NOT a publishable SDK package — a structural starting point.

SDK Steps

1. Parse spec — Extract endpoints, schemas, auth requirements
2. Group by resource — Organize endpoints into logical client modules
3. Generate client skeleton — Method stubs with typed parameters and return types
4. Auth integration — Wire auth mechanism into client constructor
5. Error handling — Map API error codes to client exceptions
6. Usage examples — One example per resource showing common operations

Scripts

Script Invocation

uv run python skills/api-designer/scripts/api-spec-validator.py <spec-path>
uv run python skills/api-designer/scripts/api-endpoint-matrix.py <spec-path>
uv run python skills/api-designer/scripts/compat-checker.py <old-spec> <new-spec>

All scripts output JSON to stdout, warnings to stderr.

Reference File Index

Do not load all references at once. Load only what the detected protocol and active mode require.

Critical Rules

1. Always detect protocol before entering any mode — never assume REST without evidence
2. If protocol is ambiguous, ask the user — do not guess
3. Generated specs must pass api-spec-validator.py before presenting to user
4. Every endpoint must have at least one error response defined (4xx or 5xx)
5. Never design APIs without pagination for list endpoints returning collections
6. Breaking changes in compat mode must include remediation suggestions
7. SDK mode produces structural scaffolds only — never claim the output is production-ready
8. Use the canonical vocabulary consistently — "spec" not "swagger", "endpoint" not "route"
9. All specs target OpenAPI 3.1 — do not generate Swagger 2.0 or OpenAPI 3.0
10. NOT for MCP servers (use mcp-creator) or frontend API client code

Scope Boundaries

IS for:

• Designing new REST, GraphQL, or gRPC APIs from requirements
• Generating OpenAPI specs from existing code
• Reviewing and auditing API designs
• Versioning strategy and deprecation planning
• Breaking change analysis between spec versions
• Scaffolding client code structure

NOT for:

• MCP server APIs (use /mcp-creator)
• Frontend API client implementations
• API gateway configuration
• Runtime API testing or load testing
• Database schema design (use /database-architect)