api-designer

Design REST and GraphQL API contracts as OpenAPI 3.1 specifications.

2|Updated Apr 18, 2021
One-click install
npx skills add https://github.com/rabbicse/go-projects --skill api-designer-rabbicse
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-designer
Source: https://github.com/rabbicse/go-projects/tree/main/projects/movie-ticket-booking/.claude/skills/api-designer
Command: npx skills add https://github.com/rabbicse/go-projects --skill api-designer-rabbicse

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you turn business requirements into clear API contracts, preventing vague endpoint design, inconsistent responses, and missing standards that slow down implementation.

Core Features & Use Cases

  • Resource Modeling: Define resources, relationships, URIs, methods, and response shapes for REST or GraphQL APIs.
  • OpenAPI Planning: Create versioned API specifications with schemas, security, pagination, and error handling.
  • Architecture Guidance: Establish reusable patterns for deprecation, backward compatibility, validation, and documentation.
  • Use Case: When building a backend for a movie ticket booking system, it can help design endpoints for movies, showtimes, seats, bookings, authentication, and rate-limited collection queries.

Quick Start

Use the api-designer skill to design a REST API for my product and return a complete OpenAPI 3.1 specification with versioning, pagination, authentication, and RFC 7807 error responses.

Frequently Asked Questions about api-designer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a REST API contract from business requirements?

Design a REST API contract by translating business requirements into clear resource models, URIs, and HTTP methods. This produces implementation-ready OpenAPI 3.1 specifications with defined schemas, security, pagination, and standardized RFC 7807 error responses.

What is the best way to structure OpenAPI 3.1 specifications for production APIs?

Structure OpenAPI 3.1 specifications by defining versioned schemas, security schemes, pagination patterns, and standardized error handling. This ensures production APIs have consistent HTTP semantics, documented authentication, and contract validation support.

How does pagination design work for REST and GraphQL APIs?

Pagination design for REST and GraphQL APIs involves establishing reusable patterns for querying large collections. It defines consistent response shapes and parameters to control data retrieval, preventing unbounded queries and improving client performance.

Can I use this to plan versioning and backward compatibility for my API?

Yes, you can plan API versioning and backward compatibility by establishing reusable architecture patterns. This includes defining deprecation strategies and versioned specifications to ensure smooth transitions without breaking existing client integrations.

Why do I need standardized error handling in API design?

Standardized error handling is needed in API design to prevent inconsistent responses that slow down implementation. Applying RFC 7807 error responses ensures clients receive clear, predictable problem details across all endpoints.

How do I model resources and relationships for a GraphQL API?

Model resources and relationships for a GraphQL API by defining types, queries, and response shapes that align with business requirements. This creates a clear contract that guides implementation and ensures consistent data retrieval.