/api-contract-test

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select api-contract-test from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv api-contract-test, /just-vibe api-contract-test and /jv:api-contract-test in Claude. See shortcut setup and context examples.

What the agent does

1. Derive assertions from actual consumer assumptions, and control fixture identity and provenance.
2. Verify valid and invalid exchanges, including the real provider boundary when a safe environment exists, and integrate the cases with the relevant checks.

Inputs

• provider/consumer expectations, versions, fixtures, and test environment.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Observable cross-boundary contracts; no reliance on live production state.

Writes

Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.

Mode

Apply; provider/consumer expectations, versions, fixtures, and test environment.

Prerequisites

Interface definitions, producer/consumer source, authentication model, versioning constraints, and isolated test endpoints. External API calls must respect environment, credentials, rate limits, and side-effect scope.

Expected output

• Contract cases with schema and semantic assertions, fixture provenance, provider verification coverage and execution results.

How the work is checked

• Removing a required response field fails; implementation changes preserving the contract remain valid.

When to stop or clarify

• Do not make mocks the sole evidence that the real provider conforms. Missing provider execution is a stated coverage gap.

Handling missing context

Infer

Read producer/consumer schemas, error contracts, auth conventions and known supported client versions.

Assume

Keep compatible response and pagination semantics where the brief does not request a breaking change.

Ask

Ask when contract sources disagree or an unknown consumer changes compatibility; do not require live credentials to write or test an isolated client.

Technical guidance

Evidence

Identify independently owned provider/consumer expectations and representative boundary fixtures.

Method

Exercise real serialization and decoding with valid, absent, null, unknown-field and error cases; keep mocks scoped to what they establish.

Pitfall

A provider-generated mock validating itself is circular evidence of compatibility.

Check

Run a known incompatible response through the consumer and a valid control; record which real boundary and version were exercised.

Situational decisions

When only mocks can run: Report consumer behavior and mocked assumptions separately from provider conformance.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring