Writes consumer-driven contract tests at service and API boundaries - Pact consumer tests, provider verification, broker publishing, and can-i-deploy gates - so an incompatible change fails a build instead of breaking integrations in production. Use when someone asks "how do I stop the backend breaking my client", "set up Pact between these services", "a renamed field broke a consumer that unit tests passed", or two separately deployed services must stay in sync. Do NOT use for designing a new API contract from scratch or reviewing its design - use api-design instead; do NOT use for end-to-end user-journey tests - use e2e-scenario-author instead; do NOT use for calls inside a single deployable - write a unit test.
Click to play with sound.
---
name: Contract Test Writer
description: Writes consumer-driven contract tests at service and API boundaries - Pact consumer tests, provider verification, broker publishing, and can-i-deploy gates - so an incompatible change fails a build instead of breaking integrations in production. Use when someone asks "how do I stop the backend breaking my client", "set up Pact between these services", "a renamed field broke a consumer that unit tests passed", or two separately deployed services must stay in sync. Do NOT use for designing a new API contract from scratch or reviewing its design - use api-design instead; do NOT use for end-to-end user-journey tests - use e2e-scenario-author instead; do NOT use for calls inside a single deployable - write a unit test.
---
# Contract Test Writer
Pin the shape of a network boundary from the consumer's side so a provider change that breaks any deployed consumer fails the provider's build, not production. The costly failure this prevents is the silent break: both teams' unit tests pass, both deploys go green, and the integration dies at runtime because a field was renamed or a status code changed and nothing in either pipeline knew the other side existed.
## Operating procedure
The consumer-driven order is the point: the consumer declares what it needs first, and the provider verifies against that declaration. Reversing it (provider publishes a schema, consumers hope) is how unread fields calcify and real dependencies go untracked.
### Step 1: Gather inputs
1. The boundary: consumer name, provider name, and the calls in play. Confirm it is a real network boundary you do not control end-to-end (cross-service call, client-to-API). For an internal function call inside one deployable, stop - write a unit test instead.
2. The fields the consumer actually reads from each response - from the consumer's code, not the provider's docs.
3. Broker availability: Pact Broker or PactFlow URL and write credentials (default: recommend standing one up; pacts committed to a repo go stale silently).
4. The environments where consumer versions run (prod, staging), for can-i-deploy.
Label as a guess any field list not confirmed against consumer source.
### Step 2: Write the consumer test against a mock provider
Declare only the request shape and the exact response fields the consumer reads - never the provider's full schema. Over-specifying makes the provider brittle to harmless additions. The consumer-driven rule: a field enters the contract only when a consumer consumes it.