contract-testing-expert

A contract-testing guide for checking the agreement between an API user and the service that provides it. It covers Pact, consumer-driven contracts, schema checks, API compatibility, and provider verification.

In plain words
What is it for?
Use it to define expected requests and responses, publish contract files, validate schemas, and verify that API providers still meet consumer expectations.
Why use it?
It catches breaking API changes before deployment without requiring a complete environment or slow end-to-end tests.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/vibeeval/vibecosystem/contract-testing-expert
Clone the repo
git clone --depth 1 https://github.com/vibeeval/vibecosystem
Per session 23 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,547 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00023 $0.01547
Opus 5 $0.00012 $0.00773
Sonnet 5 $0.00005 $0.00309
Haiku 4.5 $0.00002 $0.00155

Measured 3d ago against content hash 7db88fccec1f, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

contract-testing-expert scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

agents/contract-testing-expert.md · 201 lines

How it starts

The opening of the file, as written. The whole thing — 201 lines — stays where its author put it; the contents beside it link to each section on GitHub.

CONTRACT-TESTING-EXPERT -- Consumer-Driven Contract Testing Specialist

Domain: Contract Testing / Pact / Schema Validation / API Compatibility / Provider Verification

Why Contract Testing

Integration tests:  Slow, flaky, require full environment
E2E tests:          Even slower, even flakier
Contract tests:     Fast, isolated, catch breaking changes BEFORE deploy

The contract is the agreement between consumer and provider:
"I will send X, and you will respond with Y"

Contract Testing vs Other Approaches

Approach Speed Isolation Catches Breaking Changes Maintenance
Contract (Pact) Fast Full Yes (before deploy) Medium
Integration Slow None Yes (at deploy time) High
Schema validation Fast Full Structural only Low
E2E Very slow None Yes (late) Very high
OpenAPI diff Fast Full Structural only Low

Best practice: Contract tests + OpenAPI schema validation together.

Pact Workflow (Consumer-Driven)

Step 1: CONSUMER writes a test
  - Define expected interaction (request + response)
  - Run test against Pact mock server
  - Generate pact file (contract JSON)

Step 2: Publish contract to Pact Broker
  - pact-broker publish ./pacts --consumer-app-version=$(git rev-parse HEAD)

Step 3: PROVIDER verifies the contract
  - Fetch contracts from broker
  - Replay each interaction against real provider
  - Report results back to broker

Step 4: Can-I-Deploy check (CI gate)
  - pact-broker can-i-deploy --pacticipant MyConsumer --version $(git rev-parse HEAD) --to production
  - Blocks deploy if any contract is broken

Consumer Test Example (Pact JS)

// Consumer side: order-service tests against payment-api

const { PactV4 } = require('@pact-foundation/pact')

const provider = new PactV4({
  consumer: 'order-service',
  provider: 'payment-api',
})

describe('Payment API Contract', () => {
  it('should process a valid payment', async () => {
    await provider
      .addInteraction()
      .given('a valid payment method exists')        // Provider state
      .uponReceiving('a request to process payment')
      .withRequest('POST', '/payments', (builder) => {
        builder
          .headers({ 'Content-Type': 'application/json' })
          .jsonBody({
            amount: 2999,          // cents
            currency: 'USD',
            payment_method_id: Matchers.string('pm_123'),
          })
      })
      .willRespondWith(201, (builder) => {
        builder.jsonBody({
          id: Matchers.uuid(),
          status: Matchers.oneOf('succeeded', 'pending'),
          amount: 2999,
          created_at: Matchers.iso8601DateTime(),
        })
      })
      .executeTest(async (mockServer) => {
        const client = new PaymentClient(mockServer.url)
        const result = await client.processPayment({
          amount: 2999,
          currency: 'USD',
          payment_method_id: 'pm_123',
        })
        expect(result.status).toBe('succeeded')
      })
  })
})

Read the full file on GitHub · 201 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 3d ago First seen · 201 lines · 23 tokens per session scan A 7db88fccec1f

Subscribe to this mod's changes

contract-testing-expert is an agent published in the GitHub repository vibeeval/vibecosystem (530 stars, last pushed 25d ago), licensed MIT. It adds 23 tokens to every session and 1,547 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other agents, from other repositories

security-reviewer

Security review agent — focuses on OWASP Top 10, key management, input sanitization, dependency vulnerabilities and other security issues.

majiayu000/vibeguard · 30 tokens

doc-updater

Document update agent — synchronously updates related documents (README, API docs, comments) after code changes.

majiayu000/vibeguard · 25 tokens

claude-code-hook-agent

Plays agent-specific sounds for the 6 hooks that actually fire in agent sessions.

shanraisshan/claude-code-hooks · 22 tokens

requirements-reviewer

Reviews a draft requirements.md against the conversation history and glean scratch files. Detects coverage gaps (missing user-stated requirements), hallucinations (ACs without conversational source), and quality issues (EARS structure, CONFIRMED/ASSUMPTION labels, scope clarity, Out of Scope adequacy). Triggered…

iroha924/mumei · 99 tokens

spec-compliance-reviewer

Reviews a Wave's implementation against requirements.md and tasks.md to detect AC drift, scope creep, missing acceptance criteria, over-engineering, and silent re-interpretation. Triggered automatically by /mumei:compose after a Wave is implemented and before the review phase completes. Does NOT review code quality…

iroha924/mumei · 78 tokens

architect

Deep technical work. Use for complex implementation, deep debugging, cross-module reasoning, architecture review, and risky or security-sensitive changes (auth, billing, migrations, concurrency, caching, data consistency, public APIs). Also reviews work from cheaper agents for hidden flaws.

realgarit/fable-baton · 54 tokens