openapi-parser skill
Parses complex OpenAPI specifications to generate Drift test cases covering polymorphic schemas and various response variants.
- GitHub stars
- 7
- Files
- 7
- Last commit
- Nov 11, 2026
- License
- MIT
- Allowed tools
- —
What does the openapi-parser skill do?
openapi-parser parses complex OpenAPI specifications to generate Drift test cases covering polymorphic schemas and various response variants.
Summary generated from the skill's SKILL.md.
About the openapi-parser skill
Generating Drift test cases from complex OpenAPI specifications is the primary function of this skill. It is designed for developers who need to scaffold tests that cover polymorphic schemas, inheritance, and various response variants. When an agent loads this skill, it can parse OpenAPI 3.x files to identify path, query, and header parameters, as well as request bodies and response status codes.
The process involves recursively resolving $ref chains and interpreting complex patterns like anyOf, oneOf, allOf, and discriminators. It uses reference files such as schema-patterns.md and drift-mapping.md to ensure correct interpretation of schema logic and mapping to Drift YAML. The output includes a detailed analysis of the schema, the complete operations block for Drift, necessary datasets, and a list of intentionally excluded schema combinations. This allows for high coverage of structurally distinct schema variants without creating an unnecessary combinatorial explosion of tests.
What an agent can do with it
- 1Scaffold Drift tests from a specA developer can provide an OpenAPI file path to automatically generate a complete set of Drift operations and datasets.
- 2Test polymorphic schema branchesYou can use this to ensure every branch of a oneOf or anyOf schema is covered by a unique test case.
- 3Validate complex field valuesAn agent can help determine which specific values are valid for a field defined by complex regex patterns or enums.
- 4Handle inheritance and compositionThe skill can merge base fields with local properties to create a single payload for allOf composition tests.
Written from the skill's SKILL.md. Every use case is checked against a quote from it.
How to install the openapi-parser skill
Each command copies the skill folder into the client's skills directory. Restart the client or start a new session to load it.Install the openapi-parser skill in Plugin
/plugin marketplace add pactflow/pactflow-agent-skills /plugin install swagger-contract-testing@swagger-contract-testing-agent-extensions
Install the openapi-parser skill in Claude Code
~/.claude/skills/openapi-parser/SKILL.md
$ npx degit pactflow/pactflow-agent-skills/plugins/swagger-contract-testing/skills/openapi-parser ~/.claude/skills/openapi-parserInstall the openapi-parser skill in 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-parserInstall the openapi-parser skill in Codex
~/.agents/skills/openapi-parser/SKILL.md
$ npx degit pactflow/pactflow-agent-skills/plugins/swagger-contract-testing/skills/openapi-parser ~/.agents/skills/openapi-parserInstall the openapi-parser skill in Gemini CLI
~/.gemini/skills/openapi-parser/SKILL.md
$ npx degit pactflow/pactflow-agent-skills/plugins/swagger-contract-testing/skills/openapi-parser ~/.gemini/skills/openapi-parserInstall the openapi-parser skill in 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
View on 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
Files in this skill
7openapi-parser skill questions
How do I install the openapi-parser skill in Claude Code?
Run npx degit pactflow/pactflow-agent-skills/plugins/swagger-contract-testing/skills/openapi-parser ~/.claude/skills/openapi-parser. Claude Code loads skills from ~/.claude/skills (all projects) or .claude/skills (one project) and uses a skill when its description matches the task.
Which clients can use the openapi-parser skill?
Any client that reads the Agent Skills format: Claude Code, Codex, Gemini CLI and claude.ai (upload as a ZIP). Scripts in the skill run only where the client allows code execution.
What types of complex OpenAPI schemas can this skill handle?
The skill handles anyOf, oneOf, allOf, discriminators, polymorphism, inheritance, $ref chains, regex patterns, enums, and optional fields.
Which OpenAPI versions are supported?
This skill specifically targets OpenAPI 3.x, though Swagger 2.0 specs can be used by manually adapting field names.
How does the skill handle oneOf or anyOf patterns when generating tests?
For oneOf or anyOf patterns with N branches, it generates N tests, providing one test per branch.