pactflow/swagger-contract-testing

Generates an AsyncAPI 3.x YAML spec from a service codebase using ripwire when no spec exists. Invoke this skill whenever the user needs an AsyncAPI spec for an event-driven service that doesn't have one published — phrases like "generate an asyncapi spec from the code", "there's no asyncapi for this service", "document our Kafka topics as a spec", "create a spec from the producers and consumers", "reverse-engineer the event contract", or any time a Drift/AsyncAPI testing workflow (asyncapi-parser, drift-testing) is blocked because the spec is missing. Uses ripwire to find message producers and consumers and extract topics/queues and payload shapes across Kafka, SNS/SQS, RabbitMQ/AMQP, NATS, Google Pub/Sub, MQTT, Redis and WebSocket clients in Node.js, Python, Java/Kotlin, Go, Ruby and other ripwire-supported languages. Always ask for the codebase path if not provided. Requires ripwire on PATH.

Parses AsyncAPI 3.x specs and generates Drift test cases from them. Use whenever the user wants to generate, write, or scaffold Drift tests from an AsyncAPI spec — especially when the spec contains complex message schemas: oneOf/anyOf/allOf, discriminators, polymorphism, $ref chains, or multiple message variants. Use when the user wants to test async event-driven services (Kafka, SNS, SQS), when they ask to "create tests for a channel", "cover all message variants", "generate test cases from the AsyncAPI spec", or says anything like "each viable combination of messages". Use when the user is trying to understand what payload variants a message schema produces, or when they paste an AsyncAPI operation and ask what tests to write.

Verifies API implementations against OpenAPI specifications using the Drift CLI, catching spec drift and supporting Bi-Directional Contract Testing (BDCT). Use when the user mentions Drift, API contract testing, provider contract testing, provider verification, spec drift, API conformance testing, OpenAPI verification, BDCT, drift expressions, drift datasets, drift lifecycle hooks, or Lua scripting in a testing context. Use when the user asks to write, run, or debug Drift test cases. Use when the user wants to test their API against an OpenAPI spec, generate tests from an OpenAPI spec, or check whether their API has drifted from its spec. Use when the user wants full endpoint coverage, wants all tests to pass, or asks to "keep running until everything passes". Also use when the user mentions AsyncAPI, event-driven API testing, Kafka contract testing, SNS or SQS testing, async message contracts, or wants to verify that a service publishes or consumes messages matching an AsyncAPI spec.

Generates an OpenAPI 3.x YAML spec from a provider codebase using ripwire when no spec exists. Invoke this skill whenever the user needs an OpenAPI spec for a service that doesn't have one published — phrases like "generate an openapi spec from the code", "there's no oas for this service", "create a spec from the codebase", "the provider doesn't have a spec", or any time a pact-coverage or contract testing workflow is blocked because the provider spec is missing. Uses ripwire to extract HTTP route definitions and handler schemas across Ruby (Rails/Sinatra), Node.js (Express/Fastify), Python (Flask/FastAPI), and other ripwire-supported languages. Always ask for the codebase path if not provided. Requires ripwire on PATH.

Parses complex OpenAPI specs and generates Drift test cases from them. Use whenever the user wants to generate, write, or scaffold Drift tests from an OpenAPI spec — especially when the spec contains complex schemas: anyOf/oneOf/allOf, discriminators, polymorphism, inheritance, $ref chains, regex patterns, enums, or optional fields. Use when the user asks to "create tests for an endpoint", "cover all response variants", "generate test cases from the spec", or says anything like "each viable combination of responses". Use when the user is trying to understand what values are valid for a complex schema field, or when they paste a spec path and ask what tests to write.

Runs a coverage check to find which API operations, status codes, request body required fields, and response body required fields are NOT exercised by existing Pact consumer tests. Invoke this skill whenever the user asks "what's not covered by my pacts?", "which endpoints are missing pact tests?", "do my pact files cover the full spec?", "how complete is my pact coverage?", "which required fields aren't tested?", or any time they have Pact v2/v3/v4 JSON files and want to measure contract test coverage against an OpenAPI spec. Also supports AsyncAPI 3.x specs with Pact message pacts (Kafka, SNS/SQS, RabbitMQ events): invoke when the user asks which channels, message variants or required payload fields are not covered by their message pacts. Also invoke when they say they want to improve pact coverage or find coverage gaps — even if they don't say "pact-coverage" explicitly. Do NOT invoke for running provider verification, publishing pacts to a broker, or checking can-i-deploy; use the pactflow skill for those.

Expert assistant for PactFlow and Pact contract testing. Use this skill whenever the user mentions PactFlow, Pact, contract testing, consumer-driven contracts, provider verification, can-i-deploy, pact broker, pacticipants, bi-directional contract testing (BDCT), publishing pacts, recording deployments, provider states, the contract matrix, or managing environments and versions in a PactFlow workspace. Also trigger when the user wants to generate or review Pact tests using AI, check deployment safety, investigate why a consumer-provider verification failed, or integrate contract testing into CI/CD. Trigger even if the user doesn't say "PactFlow" explicitly — phrases like "safe to deploy?", "check compatibility between services", "consumer test", "OpenAPI contract", "AsyncAPI contract", or "service compatibility matrix" are strong signals.