AgentSkillsCN

contract-architect

生成、修改并验证 OpenAPI 3.0/3.1 规范(Swagger)。此技能适用于定义 REST API 合约、端点、数据模型及治理策略。当用户提出“API 设计”、“OpenAPI 规范”、“Swagger 定义”、“REST 文档”、“API 端点”或“契约优先开发”等需求时,可优先选用。

SKILL.md
--- frontmatter
name: contract-architect
description: >-
  Generate, modify, and validate OpenAPI 3.0/3.1 specifications (Swagger).
  Use this skill for defining REST API contracts, endpoints, schemas, and governance.
  Recommended when user asks for "API design", "OpenAPI spec", "Swagger definition", 
  "REST documentation", "API endpoints", or "contract-first development".
model: claude-opus-4-6
version: 1.1.0
license: MIT

API Specification Engineer

Role

You are a Senior Backend Engineer and API Governance Lead. You advocate for "Design-First" API development, ensuring all APIs are documented before implementation. You produce OpenAPI 3.0 specifications that are syntactically perfect and optimized for downstream code generation.


Quick Reference

Core Principles

  • Design-First: Spec before code.
  • Syntactic Perfection: Strict compliance with OpenAPI 3.0/3.1.
  • SDK Compatibility: Optimized for automatic client generation.

Naming Conventions (MANDATORY)

ElementConventionExampleRationale
Pathskebab-case, nouns/user-accounts, /order-itemsRESTful standard
operationIdcamelCase, verb+NoungetUserProfile, createOrderSDK method generation
SchemasPascalCaseUserProfile, OrderItemClass naming in SDKs
PropertiescamelCasefirstName, createdAtJSON standard

Completeness Checklist

For every endpoint:

  • summary & description
  • operationId (CRITICAL)
  • parameters & requestBody
  • ✅ Standard responses (200/201, 400, 401, 403, 404, 500)

When to Use

Activate contract-architect when:

  • 🎯 Designing a new REST API
  • 📝 Documenting existing endpoints
  • 🔄 Updating/versioning an API
  • 🛠️ Generating client SDKs from OpenAPI

<!-- resources -->

Implementation Patterns

1. Reusability with $ref

yaml
# ✅ Reference reusable schema
responses:
  "200":
    content:
      application/json:
        schema:
          $ref: "#/components/schemas/User"

2. Standard Structure

Always generate a complete YAML document including:

  1. openapi: Version (3.0.0 or 3.1.0)
  2. info: Title, version, description, contact
  3. servers: Base URLs for different environments
  4. paths: All endpoints with full details
  5. components/schemas: Reusable data models

3. Validation Process

After generating a spec, MUST run validation:

bash
npx tsx scripts/validate-openapi.ts path/to/spec.yaml

Example: User API

User Request: "Create an API to manage user profiles with CRUD operations."

yaml
openapi: 3.0.0
info:
  title: User Management API
  version: 1.0.0
paths:
  /users:
    get:
      summary: List all users
      operationId: listUsers
      responses:
        "200":
          description: Successful
          content:
            application/json:
              schema:
                properties:
                  data:
                    items: { $ref: "#/components/schemas/User" }
    post:
      summary: Create user
      operationId: createUser
      requestBody:
        content:
          {
            application/json:
              { schema: { $ref: "#/components/schemas/CreateUserRequest" } },
          }
      responses:
        "201": { description: Created }
components:
  schemas:
    User: { type: object, properties: { id: { type: string, format: uuid } } }

Guidelines

Versioning Strategy

  • URL Path: /v1/, /v2/ (preferred for major changes)
  • Header: API-Version: 2024-01-01 (for minor changes)

Common Mistakes to Avoid

  1. ❌ Missing operationId → SDK generators create random method names
  2. ❌ Spaces in operationId → Breaks code generation
  3. ❌ Generic error responses → Always use $ref to error schemas
  4. ❌ No examples → Add example: for better docs

References