Consumer-Driven Contract Test Prompt

This prompt is designed for backend engineers and QA teams who are implementing consumer-driven contract testing with Pact or a compatible framework. The core job-to-be-done is translating a consumer's actual API usage—captured from client code, integration test logs, or request/response examples—into a structured Pact consumer expectation file. The prompt then validates those generated expectations against the provider's OpenAPI or JSON Schema specification to catch mismatches before they reach the CI pipeline or production. You should use this prompt when you have concrete consumer usage evidence and a formal provider schema to validate against, and you need accurate, version-controllable expectation definitions that reflect real-world consumption patterns rather than assumed API behavior.

To use this prompt effectively, you must supply three critical inputs: [CONSUMER_USAGE_EXAMPLES] containing the actual HTTP requests, responses, headers, and status codes the consumer depends on; [PROVIDER_SCHEMA] as a valid OpenAPI 3.x or JSON Schema document that defines the provider's contract; and [PACT_CONFIGURATION] specifying the consumer name, provider name, and any Pact framework version constraints. The prompt works best when the consumer usage examples include edge cases—unusual status codes, optional fields the consumer actually reads, and specific header dependencies—rather than only happy-path interactions. Without a provider schema to validate against, the prompt cannot perform its core safety check, and you should instead use a simpler expectation generation workflow. This prompt also assumes Pact or a Pact-compatible framework is already integrated into your CI pipeline; it does not generate provider verification tests, pact broker configuration, or CI pipeline scripts.

Do not use this prompt when you lack a formal provider schema, when the consumer's usage patterns are undocumented or purely speculative, or when you need to generate provider-side verification tests. The prompt is also unsuitable for teams that have not yet adopted contract testing and need architectural guidance on whether to use Pact, Spring Cloud Contract, or another framework. For high-risk API changes—such as those involving payment processing, authentication, or personally identifiable information—always include a human review step after expectation generation, even if the schema validation passes. The generated expectations should be treated as a starting point that requires manual verification of interaction completeness, especially for consumers that use undocumented API behaviors or rely on implementation-specific quirks not captured in the provider schema.

This prompt template generates consumer expectation definitions for contract testing frameworks like Pact. It takes API usage patterns, provider schemas, and consumer requirements as inputs, then produces structured contract definitions that can be directly integrated into test suites. The template is designed for teams implementing consumer-driven contract testing in CI/CD pipelines where expectation accuracy and schema compliance are critical.

codeCopy
You are a contract testing engineer specializing in consumer-driven contract testing with Pact and similar frameworks.

Your task is to generate consumer expectation definitions from the provided API usage patterns and validate them against the provider schema.

## INPUTS

### Consumer API Usage Patterns
[CONSUMER_USAGE_PATTERNS]

### Provider API Schema (OpenAPI/JSON Schema)
[PROVIDER_SCHEMA]

### Consumer Name
[CONSUMER_NAME]

### Provider Name
[PROVIDER_NAME]

### Interaction Type
[INTERACTION_TYPE]

### Additional Constraints
[CONSTRAINTS]

## OUTPUT SCHEMA

Return a JSON object with this structure:
{
  "consumer": {
    "name": "string",
    "version": "string"
  },
  "provider": {
    "name": "string"
  },
  "interactions": [
    {
      "description": "string",
      "providerState": "string",
      "request": {
        "method": "string",
        "path": "string",
        "headers": {},
        "query": {},
        "body": {},
        "matchingRules": {}
      },
      "response": {
        "status": 0,
        "headers": {},
        "body": {},
        "matchingRules": {}
      },
      "metadata": {
        "usagePattern": "string",
        "schemaFieldMappings": [],
        "confidenceLevel": "high|medium|low",
        "warnings": []
      }
    }
  ],
  "validationSummary": {
    "totalInteractions": 0,
    "schemaCompliant": 0,
    "schemaViolations": [],
    "unmatchedUsagePatterns": [],
    "recommendations": []
  }
}

## INSTRUCTIONS

1. Analyze each consumer usage pattern to identify required request/response shapes, status codes, headers, and body fields.
2. Map consumer expectations to the provider schema, flagging any mismatches between what the consumer expects and what the provider schema defines.
3. Generate Pact-compatible matching rules for each field, preferring flexible matchers (type, regex, min/max) over exact value matching where appropriate.
4. For each interaction, include provider state descriptions that the provider test suite will need to set up.
5. Flag any usage patterns that cannot be validated against the provider schema as schema violations.
6. Assign confidence levels based on how well the usage pattern maps to the schema:
   - high: exact field match with clear types
   - medium: partial match or inferred types
   - low: significant gaps or ambiguous mapping
7. Include warnings for deprecated fields, unstable endpoints, or schema features marked as experimental.

## MATCHING RULES

Generate Pact matching rules following these conventions:
- Use `type` matcher for fields where only type matters
- Use `regex` matcher for fields with known patterns (IDs, dates, emails)
- Use `min`/`max` for numeric ranges
- Use `eachLike` for arrays with consistent structure
- Use `atLeastOne` for non-empty arrays
- Avoid exact value matching unless the consumer explicitly requires it

## CONSTRAINTS

- Do not invent usage patterns not present in the input
- Do not generate expectations for endpoints not referenced in usage patterns
- Flag but do not silently correct schema mismatches
- Preserve the original usage pattern reference in metadata for traceability
- If the provider schema is incomplete or missing required fields, note this in validationSummary.recommendations

Adapt this template by replacing each square-bracket placeholder with concrete values. For [CONSUMER_USAGE_PATTERNS], provide structured descriptions of how the consumer calls the API, including typical request payloads, expected response shapes, status codes, and any timing or ordering dependencies. For [PROVIDER_SCHEMA], supply the full OpenAPI specification or JSON Schema that defines the provider's contract. Set [INTERACTION_TYPE] to one of request-response, async-message, or mixed depending on the API style. The [CONSTRAINTS] placeholder accepts additional rules like field exclusion lists, custom matcher preferences, or environment-specific overrides. After generating the output, validate it against your Pact framework's expectation format before committing to the test suite.

Integrating this prompt into a CI/CD pipeline requires treating the generated consumer expectation definitions as test artifacts that must pass validation before merging. The prompt output should be a structured JSON or YAML document conforming to your Pact framework's expectation format. Wire the prompt into a GitHub Action, GitLab CI job, or Jenkins stage that runs on pull requests touching API consumer code or recorded traffic patterns. The job should call your LLM endpoint with the prompt template, capture the raw output, and immediately validate it against a Pact expectation schema using a tool like pact-verifier or a custom JSON Schema validator. If validation fails, the pipeline should fail fast and surface the specific schema errors to the developer.

For production-grade reliability, implement a retry loop with exponential backoff when the model returns malformed JSON or fails to produce valid expectation definitions. Use a maximum of three retry attempts, each time appending the previous validation errors to the prompt as [PREVIOUS_ERRORS] so the model can self-correct. Log every attempt—including the raw prompt, model response, validation result, and retry count—to your observability platform for debugging prompt drift over time. Choose a model with strong structured output capabilities (such as GPT-4o or Claude 3.5 Sonnet) and set response_format to json_object or use function calling to enforce the expectation schema directly. For teams using Pact Broker, the validated expectations should be published to the broker as part of the CI job, tagged with the consumer version and branch name for traceability.

Before enabling auto-merge on generated contracts, introduce a human review gate for any expectation that introduces a new provider state or modifies an existing interaction's request matching rules. These changes carry higher risk of false positives in provider verification and can mask real breaking changes. Configure your CI pipeline to add a needs-review label to the PR when the diff includes new provider states or modified matching logic, and require approval from a designated API platform team member. Avoid running this prompt on every commit to feature branches—instead, trigger it only when consumer test recordings or traffic capture files change, reducing LLM API costs and preventing noisy PR comments. For teams without existing Pact infrastructure, start by generating the expectations as JSON files committed alongside the consumer tests, and add provider-side verification as a separate pipeline stage that fetches the latest expectations from the repository.