Contract-first REST API design with OpenAPI 3.1 specification
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
npx agent-skills-cli listSkill Instructions
name: openapi-design description: Contract-first REST API design with OpenAPI 3.1 specification allowed-tools: Read, Glob, Grep, Write, Edit, mcp__perplexity__search, mcp__context7__resolve-library-id, mcp__context7__query-docs
OpenAPI Design Skill
When to Use This Skill
Use this skill when:
- Designing REST APIs - OpenAPI 3.1 for contract-first API design
- Defining API contracts - Schemas, paths, parameters, responses
- API best practices - Naming conventions, status codes, versioning
MANDATORY: Documentation-First Approach
Before creating OpenAPI specifications:
- Invoke
docs-managementskill for API design patterns - Verify OpenAPI 3.1 syntax via MCP servers (context7 for latest spec)
- Base all guidance on OpenAPI 3.1 specification
Contract-First Approach
Why Contract-First?
- Design before implementation: Think through API before coding
- Parallel development: Frontend and backend can work simultaneously
- Clear contract: Unambiguous specification for all parties
- Auto-generation: Generate clients, servers, documentation
- Validation: Validate requests/responses against schema
Workflow
Requirements β OpenAPI Spec β Review β Generate β Implement β Test
β β
βββββββββββββ Iterate as needed ββββββββββββββββββββββ
OpenAPI 3.1 Structure Overview
openapi: 3.1.0
info:
title: API Title
version: 1.0.0
description: API description
servers:
- url: https://api.example.com/v1
description: Production
tags:
- name: Orders
description: Order management
paths:
# Define endpoints - see paths-definition.md
components:
schemas: { }
securitySchemes: { }
responses: { }
parameters: { }
For complete template: See paths-definition.md
Quick Reference
HTTP Methods
| Method | Purpose | Idempotent |
|---|---|---|
| GET | Retrieve resource(s) | Yes |
| POST | Create resource | No |
| PUT | Replace resource | Yes |
| PATCH | Partial update | No |
| DELETE | Remove resource | Yes |
Common Status Codes
| Code | Use For |
|---|---|
| 200 | Successful GET, PUT, PATCH |
| 201 | Resource created (POST) |
| 204 | Successful DELETE |
| 400 | Malformed request |
| 401 | Authentication required |
| 404 | Resource not found |
| 422 | Validation error |
For complete guidance: See design-best-practices.md
Design Workflow
- Understand requirements: What operations are needed?
- Design resources: Identify entities and relationships
- Define schemas: Create reusable component schemas
- Specify endpoints: Define paths and operations
- Add security: Configure authentication/authorization
- Document examples: Add request/response examples
- Validate: Use linting tools (Spectral, etc.)
- Review: Get team feedback before implementation
References
Load on-demand based on need:
| Reference | Load When |
|---|---|
| paths-definition.md | Defining REST endpoints, operations, parameters |
| components-definition.md | Creating schemas, responses, security schemes |
| design-best-practices.md | Reviewing naming, status codes, versioning |
Related Skills (Cross-Plugin)
| Phase | Skill | Plugin | Purpose |
|---|---|---|---|
| DESIGN | openapi-design (this skill) | formal-specification | Architecture research, pattern selection |
| AUTHORING | openapi-authoring | spec-driven-development | Concrete YAML file creation |
| GOVERNANCE | contract-first-design | spec-driven-development | API governance, code generation |
Workflow: Design (research patterns) β Author (create YAML) β Govern (enforce contracts)
External References
- OpenAPI 3.1 Specification - Official specification
- RFC 7231 - HTTP Semantics - HTTP methods and status codes
- RFC 7807 - Problem Details - Standard error response format
- Spectral - OpenAPI linting tool
MCP Research
For current OpenAPI patterns and tools:
perplexity: "OpenAPI 3.1 specification" "REST API design patterns"
context7: "openapi" (for official documentation)
ref: "OpenAPI spec examples" "JSON Schema patterns"
Version History
- v2.0.0 (2026-01-17): Refactored to progressive disclosure pattern
- Extracted 3 reference files (~500 lines)
- Hub reduced from 698 to ~130 lines
- v1.0.0 (2025-12-26): Initial release
Last Updated: 2026-01-17
More by melodic-software
View allThreat modeling methodologies (STRIDE, DREAD), attack trees, threat modeling as code, and integration with SDLC for proactive security design
Multi-identity Git configuration with directory-scoped isolation. Sets up per-directory user email, GPG signing keys, and SSH keys using includeIf conditional includes. Use when configuring work vs personal Git identities, fixing "Unverified" commits from email/GPG key mismatch, setting up multiple GitHub accounts on one machine, auditing identity isolation, or troubleshooting includeIf, GPG key selection, or SSH key routing issues.
Map relationships between bounded contexts using DDD context mapping patterns. Use when defining upstream/downstream relationships, integration strategies (ACL, OHS, PL), or generating Context Mapper DSL output. Follows event storming for bounded context discovery.
TLA+ formal specification language for distributed systems and concurrent algorithms
