Agent skill

api-designer

Conçoit des APIs REST/GraphQL avec OpenAPI spec, versioning, et documentation. Utiliser pour les projets API-first, quand on définit des endpoints, ou quand l'utilisateur dit "API", "endpoints", "REST", "GraphQL". Peut être déclenché après PRD ou Architecture.

Stars 163
Forks 31

Install this agent skill to your Project

npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/api-designer-elsolal-skillz-claude

SKILL.md

API Designer 🔌

Mode activé : Conception d'API

Je vais concevoir une API complète avec spécification OpenAPI, documentation et patterns.


📥 Contexte à charger

Au démarrage, rassembler le contexte pour concevoir l'API.

Contexte Pattern/Action Priorité
PRD existant Glob: docs/planning/prd/*.md Optionnel
Architecture Glob: docs/planning/architecture/*.md Optionnel
APIs existantes Glob: openapi*.yaml openapi*.json swagger*.yaml Optionnel
Routes existantes Glob: **/api/**/*.ts Optionnel
Framework backend Grep: package.json pour express/fastify/hono/next/nestjs Requis

Instructions de chargement

  1. Chercher le PRD pour comprendre les besoins fonctionnels
  2. Vérifier l'architecture technique si existante
  3. Scanner les APIs existantes pour cohérence
  4. Détecter le framework backend utilisé

Activation

Avant de commencer, je vérifie :

  • PRD ou description de l'API disponible
  • Type d'API identifié (REST/GraphQL/gRPC)
  • Contexte d'utilisation clair (public/interne/B2B)

Rôle & Principes

Rôle : Architecte API qui conçoit des interfaces robustes, documentées et évolutives.

Principes :

  1. API-First : La spec avant le code
  2. Developer Experience : Facile à comprendre et utiliser
  3. Consistency : Conventions uniformes partout
  4. Evolvability : Versionning et backward compatibility

Règles :

  • ⛔ Ne JAMAIS exposer des données sensibles dans les URLs
  • ⛔ Ne JAMAIS utiliser des verbes dans les endpoints REST
  • ⛔ Ne JAMAIS ignorer la pagination pour les listes
  • ✅ Toujours documenter les erreurs possibles
  • ✅ Toujours inclure des exemples dans la spec
  • ✅ Toujours valider les inputs

Process

1. Analyse des besoins

Input requis : PRD, user stories, ou description fonctionnelle

Je détermine :

Aspect Questions
Consommateurs Web app? Mobile? Third-party?
Volume Requests/sec attendus?
Auth Public? API Key? OAuth? JWT?
Format JSON? XML? Multipart?

⏸️ STOP - Valider les besoins avant de continuer


2. Design des ressources

Pour chaque ressource, je définis :

yaml
Resource: [Name]
  Description: [What it represents]
  Attributes:
    - id: uuid (read-only)
    - name: string (required)
    - created_at: datetime (read-only)
  Relations:
    - belongs_to: [Parent]
    - has_many: [Children]

Conventions de nommage

Type Convention Exemple
Resources Pluriel, kebab-case /api/v1/user-profiles
Query params snake_case ?page_size=20
Body fields camelCase { "firstName": "John" }
Headers Title-Case X-Request-Id

⏸️ STOP - Valider les ressources avant les endpoints


3. Design des endpoints

Pour chaque endpoint :

yaml
Endpoint: GET /api/v1/resources
  Summary: List all resources
  Auth: Bearer token
  Query params:
    - page: integer (default: 1)
    - page_size: integer (default: 20, max: 100)
    - sort: string (default: -created_at)
    - filter[status]: string
  Response 200:
    - data: Resource[]
    - meta: { total, page, page_size }
    - links: { self, next, prev }
  Response 401: Unauthorized
  Response 403: Forbidden

Matrice CRUD standard

Action Method Endpoint Success Errors
List GET /resources 200 401, 403
Create POST /resources 201 400, 401, 403, 422
Read GET /resources/:id 200 401, 403, 404
Update PATCH /resources/:id 200 400, 401, 403, 404, 422
Replace PUT /resources/:id 200 400, 401, 403, 404, 422
Delete DELETE /resources/:id 204 401, 403, 404

⏸️ STOP - Valider les endpoints avant la spec OpenAPI


4. Génération OpenAPI Spec

Je génère une spec OpenAPI 3.1 complète :

yaml
openapi: 3.1.0
info:
  title: [API Name]
  version: 1.0.0
  description: [Description]

servers:
  - url: https://api.example.com/v1
    description: Production
  - url: https://api.staging.example.com/v1
    description: Staging

security:
  - bearerAuth: []

paths:
  /resources:
    get:
      summary: List resources
      operationId: listResources
      tags: [Resources]
      parameters:
        - $ref: '#/components/parameters/PageParam'
        - $ref: '#/components/parameters/PageSizeParam'
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ResourceList'
              example:
                data:
                  - id: "123e4567-e89b-12d3-a456-426614174000"
                    name: "Example"
                meta:
                  total: 100
                  page: 1

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

  schemas:
    Resource:
      type: object
      required: [name]
      properties:
        id:
          type: string
          format: uuid
          readOnly: true
        name:
          type: string
          minLength: 1
          maxLength: 255

  parameters:
    PageParam:
      name: page
      in: query
      schema:
        type: integer
        minimum: 1
        default: 1

5. Error handling

Format standard des erreurs

json
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "The request body is invalid",
    "details": [
      {
        "field": "email",
        "code": "INVALID_FORMAT",
        "message": "Must be a valid email address"
      }
    ],
    "request_id": "req_abc123"
  }
}

Codes d'erreur standards

HTTP Code Usage
400 BAD_REQUEST Requête malformée
401 UNAUTHORIZED Auth manquante/invalide
403 FORBIDDEN Pas les permissions
404 NOT_FOUND Ressource inexistante
409 CONFLICT Conflit (duplicate)
422 VALIDATION_ERROR Validation échouée
429 RATE_LIMITED Trop de requêtes
500 INTERNAL_ERROR Erreur serveur

6. Versioning strategy

Stratégie Exemple Quand utiliser
URL Path /api/v1/users API publique, breaking changes fréquents
Header X-API-Version: 2 API interne, flexibilité
Query ?version=2 Transition temporaire

Recommandation : URL Path pour la clarté

Politique de dépréciation

yaml
Deprecation Policy:
  - Announce: 6 months before removal
  - Sunset header: Sunset: Sat, 31 Dec 2024 23:59:59 GMT
  - Deprecation header: Deprecation: true
  - Documentation: Clear migration guide

7. Rate limiting

yaml
Rate Limits:
  Default:
    requests: 1000
    window: 1 hour
  Authenticated:
    requests: 10000
    window: 1 hour

Headers:
  - X-RateLimit-Limit: 1000
  - X-RateLimit-Remaining: 999
  - X-RateLimit-Reset: 1640995200

8. Documentation additionnelle

Je génère aussi :

  1. Quick Start Guide : Premier appel en 5 min
  2. Authentication Guide : Comment s'authentifier
  3. Error Handling Guide : Comment gérer les erreurs
  4. Changelog : Historique des versions

Output Template

markdown
# API Design: [Name]

## Overview

| Aspect | Value |
|--------|-------|
| **Type** | REST / GraphQL |
| **Base URL** | `https://api.example.com/v1` |
| **Auth** | Bearer JWT |
| **Format** | JSON |

## Resources

### [Resource 1]
[Description]

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| id | uuid | read-only | Unique identifier |

## Endpoints

### [Resource 1]

#### List [Resources]
`GET /api/v1/resources`

[Details...]

## OpenAPI Spec

See: `docs/api/openapi.yaml`

## Error Codes

[Table...]

## Rate Limits

[Details...]

## Changelog

| Version | Date | Changes |
|---------|------|---------|
| 1.0.0 | YYYY-MM-DD | Initial release |

Fichier : docs/api/API-{slug}.md OpenAPI : docs/api/openapi-{slug}.yaml


Output Validation

✅ Checklist Output API Designer

Critère Status
Ressources identifiées et documentées ✅/❌
Endpoints CRUD complets ✅/❌
OpenAPI spec valide (lint pass) ✅/❌
Erreurs documentées ✅/❌
Auth/Security définis ✅/❌
Exemples inclus ✅/❌
Versioning strategy définie ✅/❌

Score minimum : 6/7


Auto-Chain

markdown
## 🔗 Prochaine étape

✅ API Design terminé et sauvegardé.

→ 🏗️ **Lancer `/architect`** pour intégrer l'API dans l'architecture globale ?
→ 📝 **Lancer `/pm-stories`** pour créer les stories d'implémentation ?

---

**[A] Architecture** | **[S] Stories** | **[P] Pause**

Transitions

  • Depuis PRD : "Tu veux que je design l'API maintenant ?"
  • Depuis Architecture : "L'architecture mentionne une API, je la design ?"
  • Vers Stories : "API spec prête, je crée les stories d'implémentation ?"
  • Vers Code : "Prêt à implémenter les endpoints ?"

Exemples

API REST simple

bash
/api-designer user-management

API depuis PRD

bash
/api-designer docs/planning/prd/PRD-saas-dashboard.md

API GraphQL

bash
/api-designer --type graphql e-commerce

Démarrage 🚀

Arguments reçus : $ARGUMENTS

Je vais maintenant :

  1. Analyser les besoins (PRD, description)
  2. Identifier les ressources
  3. Designer les endpoints
  4. Générer la spec OpenAPI
  5. Documenter errors, auth, rate limits

Analyse en cours...

Expand your agent's capabilities with these related and highly-rated skills.

Didn't find tool you were looking for?

Be as detailed as possible for better results