What this prompt does
This prompt sets up consumer-driven contract testing across [service_count] microservices ([services]) using [contract_tool]. It defines consumer expectations as pacts for each interaction, generates provider verification tests from those pacts, configures a [pact_broker] for sharing and versioning contracts, implements can-i-deploy checks, handles authentication in contract tests, sets up webhook triggers so providers re-verify when a consumer publishes a new pact, covers [interaction_types] interactions, and blocks deployment in CI when a contract breaks. Examples are written in [language].
The structure works because it keeps integrations honest without slow, brittle end-to-end environments. Each consumer declares exactly what it expects, and the provider verifies it can meet those expectations — so services ship independently while still catching breaking changes. The can-i-deploy gate plus webhook re-verification mean a contract break is caught before release, not after a neighbour service falls over. The [services] and [interaction_types] variables map it to your architecture.
When to use it
- You split a system into services and full E2E test environments became slow and flaky.
- You want each service to deploy independently without breaking neighbours.
- You need consumer expectations captured as versioned pacts.
- You want a can-i-deploy gate before any release.
- You need both REST and async message-queue
[interaction_types]covered. - You want provider re-verification triggered automatically on new pacts.
Example output
You get [contract_tool] setup for [services]: consumer-side pact definitions, generated provider verification tests, a [pact_broker] configuration for versioning, can-i-deploy checks, auth handling, webhook triggers, and CI integration that blocks deploys on broken contracts — with example consumer and provider tests in [language].
Pro tips
- Name your real
[services]and their relationships so the generated pacts reflect actual consumer-provider pairs. - Cover every relevant
[interaction_types]— if you use async messaging, do not leave it to REST-only pacts. - Set up the
[pact_broker]early; without shared, versioned contracts the whole workflow falls apart. - Treat can-i-deploy as a hard gate, not advisory — that gate is the entire point.
- Keep pacts consumer-driven: providers should verify against what consumers actually need, not the full API surface.
- Wire the webhook triggers so a new consumer pact re-verifies its provider automatically.
