Skill openapi-parser
Analiza especificaciones complejas de OpenAPI para generar casos de prueba de Drift que cubren esquemas polimórficos y diversas variantes de respuesta.
- Estrellas en GitHub
- 7
- Archivos
- 7
- Último commit
- 11 nov 2026
- Licencia
- MIT
- Herramientas permitidas
- —
¿Qué hace la skill openapi-parser?
openapi-parser es una agent skill. Analiza especificaciones complejas de OpenAPI para generar casos de prueba de Drift que cubren esquemas polimórficos y diversas variantes de respuesta.
Resumen generado a partir del SKILL.md de la skill.
Sobre la skill openapi-parser
La función principal de este SKILL es generar casos de prueba de Drift a partir de especificaciones complejas de OpenAPI. Está diseñado para desarrolladores que necesitan estructurar pruebas que cubran esquemas polimórficos, herencia y diversas variantes de respuesta. Cuando un agente carga este SKILL, puede analizar archivos OpenAPI 3.x para identificar parámetros de path, query y header, así como cuerpos de solicitud y códigos de estado de respuesta.
El proceso implica la resolución recursiva de cadenas de $ref y la interpretación de patrones complejos como anyOf, oneOf, allOf y discriminators. Utiliza archivos de referencia como schema-patterns.md y drift-mapping.md para asegurar la interpretación correcta de la lógica del esquema y su mapeo a Drift YAML. El resultado incluye un análisis detallado del esquema, el bloque de operaciones completo para Drift, los datasets necesarios y una lista de combinaciones de esquemas excluidas intencionalmente. Esto permite una alta cobertura de variantes de esquemas estructuralmente distintos sin crear una explosión combinatoria innecesaria de pruebas.
Lo que un agente puede hacer con ella
- 1Estructurar pruebas de Drift desde una especificaciónUn desarrollador puede proporcionar la ruta de un archivo OpenAPI para generar automáticamente un conjunto completo de operaciones y datasets de Drift.
- 2Probar ramas de esquemas polimórficosPuedes usar esto para asegurar que cada rama de un esquema oneOf o anyOf esté cubierta por un caso de prueba único.
- 3Validar valores de campos complejosUn agente puede ayudar a determinar qué valores específicos son válidos para un campo definido por enums o patrones regex complejos.
- 4Manejar herencia y composiciónEl SKILL puede fusionar campos base con propiedades locales para crear un único payload para las pruebas de composición allOf.
Escrito a partir del SKILL.md de la skill. Cada caso de uso se verifica con una cita del mismo.
Cómo instalar la skill openapi-parser
Cada comando copia la carpeta de la skill al directorio de skills del cliente. Reinicia el cliente o inicia una nueva sesión para cargarla.Instalar la skill openapi-parser en Plugin
/plugin marketplace add pactflow/pactflow-agent-skills /plugin install swagger-contract-testing@swagger-contract-testing-agent-extensions
Instalar la skill openapi-parser en Claude Code
~/.claude/skills/openapi-parser/SKILL.md
$ npx degit pactflow/pactflow-agent-skills/plugins/swagger-contract-testing/skills/openapi-parser ~/.claude/skills/openapi-parserInstalar la skill openapi-parser en Claude Code (project)
.claude/skills/openapi-parser/SKILL.md
$ npx degit pactflow/pactflow-agent-skills/plugins/swagger-contract-testing/skills/openapi-parser .claude/skills/openapi-parserInstalar la skill openapi-parser en Codex
~/.agents/skills/openapi-parser/SKILL.md
$ npx degit pactflow/pactflow-agent-skills/plugins/swagger-contract-testing/skills/openapi-parser ~/.agents/skills/openapi-parserInstalar la skill openapi-parser en Gemini CLI
~/.gemini/skills/openapi-parser/SKILL.md
$ npx degit pactflow/pactflow-agent-skills/plugins/swagger-contract-testing/skills/openapi-parser ~/.gemini/skills/openapi-parserInstalar la skill openapi-parser en Claude.ai
npx degit pactflow/pactflow-agent-skills/plugins/swagger-contract-testing/skills/openapi-parser openapi-parser && zip -r openapi-parser.zip openapi-parser # claude.ai → Customize → Skills → + → Create skill → Upload a skill → openapi-parser.zip
SKILL.md
Ver en GitHubOpenAPI Parser Skill
Reference files
references/schema-patterns.md— how to interpret and enumerate every complex pattern (anyOf / oneOf / allOf / discriminator / $ref / enum / pattern / nullable / optional), with real examples from snyk, digitalocean, posthog, and front/core specsreferences/drift-mapping.md— how to map enumerated schema variants to Drift YAML, including datasets, expressions, lifecycle hooks for stateful cases, and expected response matchers for each pattern type
Workflow
OpenAPI version: This skill targets OpenAPI 3.x. Swagger 2.0 specs use the same structural patterns (
$ref,allOf,oneOf) but different envelope syntax — you may need to adapt field names manually. If working from thekonfig-sdks/openapi-examplescollection, seereferences/example-repos.mdfor navigation commands.
1. Locate the endpoint
Extract only what's needed:
# Find the line number of the endpoint (macOS/Linux/Git Bash/WSL)
grep -n "^ /path/to/endpoint" spec.yaml
# Read just that block (adjust line range as needed)
# Then follow each $ref to components/schemas
grep -n "SchemaName:" spec.yaml
# PowerShell equivalents (Windows)
Select-String -Path spec.yaml -Pattern "^ /path/to/endpoint" | Select-Object LineNumber, Line
Select-String -Path spec.yaml -Pattern "SchemaName:" | Select-Object LineNumber, Line
Extract: path/query/header parameters, request body schema, and each response status code's schema.
2. Resolve $refs recursively
- Grep for
Foo:in the spec to find its definition block - If Foo itself contains refs, resolve those too
- Stop at primitive types (
string,integer,boolean,array,object)
allOf: [$ref: Base, properties: {...}] is inheritance — merge Base fields with local
properties to get the full schema. See references/schema-patterns.md for all patterns.
3. Enumerate viable combinations
For each response status code, enumerate structurally distinct schema variants. Aim for minimum tests that maximise schema coverage — not a combinatorial explosion of optional field permutations.
| Pattern | Tests to generate |
|---|---|
oneOf / anyOf with N branches |
N tests — one per branch |
discriminator with N mapping values |
N tests — one per discriminator value |
allOf (composition / inheritance) |
1 test — merge all schemas into one payload |
enum |
1 test covers it; add boundary variants only if the value drives behaviour |
| Optional field cluster | 2 tests: one with all optional fields, one without |
nullable field |
Covered by happy path; add null variant only if it changes behaviour |
pattern (regex) |
1 valid example matching the pattern; 1 invalid for negative testing |
4. Generate Drift test cases
For each combination produce a Drift operation block. See references/drift-mapping.md
for full patterns. Key conventions:
- Name operations as
{operationId}_{variant}— e.g.getImage_byId,getImage_bySlug - For discriminated unions, set the discriminator property explicitly in the request body
- For
anyOfpath parameters, write one test per type variant - Use
datasetfor test data; use inlineparametersonly for static, non-variant values (e.g. a fixed enum query param liketype: user) - For 401 tests, strip global auth with
exclude: [auth]and pass an invalid bearer token explicitly - Add
ignore: { schema: true }to any operation that sends an intentionally invalid request body - Tag each test to indicate which schema branch it covers
- Omitting
bodyfromexpectedlets Drift validate the response against the OpenAPI schema automatically; add explicitbodymatchers only when asserting a specific field value (e.g. the discriminator property came back correctly)
5. Output format
Always produce:
- Analysis — number of status codes, which schemas are polymorphic, how many tests will be generated and why
- Drift operations YAML — the complete
operations:block, ready to paste - Dataset YAML (if needed) — the
datasets:block for any referenced test data - Gaps — schema combinations intentionally excluded, with the reason
Example
Given GET /v2/images/{image_id} where image_id: anyOf: [integer, string]:
operations:
getImage_byId:
target: source-oas:getImage
tags: [images, param-integer]
parameters:
path:
image_id: ${image-data:images.existing.id}
expected:
response:
statusCode: 200
getImage_bySlug:
target: source-oas:getImage
tags: [images, param-string]
parameters:
path:
image_id: ${image-data:images.existing.slug}
expected:
response:
statusCode: 200
getImage_notFound:
target: source-oas:getImage
parameters:
path:
image_id: ${image-data:notIn(images.*.id)}
expected:
response:
statusCode: 404
Archivos de esta skill
7Preguntas sobre la skill openapi-parser
¿Cómo instalo la skill openapi-parser en Claude Code?
Ejecuta npx degit pactflow/pactflow-agent-skills/plugins/swagger-contract-testing/skills/openapi-parser ~/.claude/skills/openapi-parser. Claude Code carga las skills desde ~/.claude/skills (todos los proyectos) o .claude/skills (un proyecto) y usa una skill cuando su descripción coincide con la tarea.
¿Qué clientes pueden usar la skill openapi-parser?
Cualquier cliente que lea el formato Agent Skills: Claude Code, Codex, Gemini CLI y claude.ai (subir como ZIP). Los scripts de la skill se ejecutan solo donde el cliente permite la ejecución de código.
¿Qué tipos de esquemas complejos de OpenAPI puede manejar este SKILL?
El SKILL maneja anyOf, oneOf, allOf, discriminators, polimorfismo, herencia, cadenas de $ref, patrones regex, enums y campos opcionales.
¿Qué versiones de OpenAPI son compatibles?
Este SKILL está diseñado específicamente para OpenAPI 3.x, aunque se pueden usar especificaciones de Swagger 2.0 adaptando manualmente los nombres de los campos.
¿Cómo maneja el SKILL los patrones oneOf o anyOf al generar las pruebas?
Para patrones oneOf o anyOf con N ramas, genera N pruebas, proporcionando una prueba por cada rama.