What this prompt does
This prompt frames the model as a senior test automation engineer setting up consumer-driven contract tests between [consumer_service] and [provider_service] using Pact, returning real config and code rather than pseudocode. Three placeholders shape it: [consumer_service], [provider_service], and [broker] (the Pact broker, with CI assumed to be GitHub Actions).
The structure works because the scariest microservice failures are silent API drift — the consumer assumes a field the provider quietly renamed. By asking for a consumer-side test that defines interactions and generates a pact file, publishing it with version and git-branch tags to [broker], provider-side verification with provider states, can-i-deploy gating, webhook or pending-pacts setup, and the GitHub Actions steps wiring it all together, the prompt makes the contract the source of truth. Gating deploys on can-i-deploy is what blocks a breaking change before release. Naming [consumer_service] and [provider_service] keeps the interactions and provider states concrete, so the generated test describes a real expectation between two specific services rather than an abstract example.
When to use it
- You split a system into services and worry about silent API drift between teams.
- You want a consumer-side Pact test that generates a pact file from expected interactions.
- You need provider-side verification replaying the pact against
[provider_service]with provider states. - You want
can-i-deploygating so a breaking change is blocked before release. - You need pact publishing to
[broker]tagged with version and git branch. - You want pending-pacts so new contracts do not immediately break the provider build.
Example output
Expect separate code blocks: the Pact config, the consumer test (defining expected interactions and generating a pact file), the provider verification (replaying the pact against [provider_service] with provider states), and the GitHub Actions steps. The CI wiring covers publishing the pact to [broker] with version and git-branch tags, can-i-deploy gating to block breaking changes, and webhook or pending-pacts setup so new contracts from [consumer_service] do not fail the provider build immediately.
Pro tips
- Gate deploys on
can-i-deploy— a green unit suite means nothing if the contract between[consumer_service]and[provider_service]broke. - Tag published pacts with version and git branch so the broker can reason about which environments are compatible.
- Use pending pacts so a brand-new contract does not immediately fail the provider build before the provider implements it.
- Define provider states carefully; verification replays interactions against
[provider_service], and missing states cause false failures. - Keep the consumer test focused on the interactions you actually depend on, not the provider's entire surface area.
- Run can-i-deploy in both directions so a provider change is also checked against existing consumers, not just the consumer against the provider.
- Wire the webhook so a provider verification result triggers re-checks, keeping the broker's compatibility picture current as either side ships.
