Skip to main content
commandsSource-backed

/api-contract-check - API Contract Check Command for Claude Code

Slash command that runs consumer-driven contract verification for an HTTP API using Pact.

by techforgeworks·added 2026-06-04·
Invocation:/api-contract-check [provider]
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://docs.pact.io/, https://github.com/pact-foundation/pact-js
Safety notes
Following the command runs the project's Pact provider-verification step, which typically starts the provider (or a stub of it) and replays recorded requests against it; review what the verify task does before running it., It performs read and verify actions only - it replays existing consumer contracts and reports pass or fail; it does not deploy, publish, or mutate the provider., When a Pact Broker is configured it fetches consumer contracts over the network using the project's existing broker credentials; it never prints those credentials.
Privacy notes
Pact contract files and verification output contain example request and response bodies, headers, and provider state names, which enter the model context to explain failures., If those example payloads include real customer data or tokens, that text becomes part of the prompt; review the pacts before running on sensitive contracts., The command itself writes nothing to disk beyond the verifier's own logs.
Author
techforgeworks
Submitted by
techforgeworks
Claim status
unclaimed
Last verified
2026-06-04

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

78

Baseline

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Complete

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done
  • Source provenance statusRequired

    Marked as source-backed.

    Done
  • Metadata reviewed

    Registry metadata indicates a reviewed listing.

    Done

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done
  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done
  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done
  • Package verification flag

    No package verification flag provided.

    Pending
  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

CLI install

Copy-ready — paste the snippet to get started.

Adoption plan

Balanced adoption plan

Current risk score 16/100. Use staged verification before broader rollout.

Risk 16

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    Listing has review metadata.

    Done
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Required evidence gates are covered (5/6 signals complete).

Risk 15

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Present

Review metadata is present.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required evidence gates are covered for this preset.

Decision timeline

Decision timeline · balanced

5/6 steps complete with no blocking gaps for this preset.

Risk 14

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is available.

Done

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

No required blockers for this timeline preset.

Safety & privacy surface

Safety & privacy surface

3 safety and 3 privacy notes across 4 risk areas. Review closely: credentials & tokens, network access, third-party handling.

4 areas
  • SafetyNetwork accessFollowing the command runs the project's Pact provider-verification step, which typically starts the provider (or a stub of it) and replays recorded requests against it; review what the verify task does before running it.
  • SafetyThird-party handlingIt performs read and verify actions only - it replays existing consumer contracts and reports pass or fail; it does not deploy, publish, or mutate the provider.
  • SafetyCredentials & tokensWhen a Pact Broker is configured it fetches consumer contracts over the network using the project's existing broker credentials; it never prints those credentials.
  • PrivacyNetwork accessPact contract files and verification output contain example request and response bodies, headers, and provider state names, which enter the model context to explain failures.
  • PrivacyCredentials & tokensIf those example payloads include real customer data or tokens, that text becomes part of the prompt; review the pacts before running on sensitive contracts.
  • PrivacyLocal filesThe command itself writes nothing to disk beyond the verifier's own logs.

Safety notes

  • Following the command runs the project's Pact provider-verification step, which typically starts the provider (or a stub of it) and replays recorded requests against it; review what the verify task does before running it.
  • It performs read and verify actions only - it replays existing consumer contracts and reports pass or fail; it does not deploy, publish, or mutate the provider.
  • When a Pact Broker is configured it fetches consumer contracts over the network using the project's existing broker credentials; it never prints those credentials.

Privacy notes

  • Pact contract files and verification output contain example request and response bodies, headers, and provider state names, which enter the model context to explain failures.
  • If those example payloads include real customer data or tokens, that text becomes part of the prompt; review the pacts before running on sensitive contracts.
  • The command itself writes nothing to disk beyond the verifier's own logs.

Schema details

Install type
cli
Troubleshooting
No
Source repository stats
Scope
Source repo
Runtime and command metadata
Command syntax
/api-contract-check [provider]
Full copyable content
/api-contract-check [provider]

About this resource

The /api-contract-check command runs Pact consumer-driven contract verification, so you find out which consumer expectations a provider breaks before the change ships — checking real recorded interactions rather than only the schema shape.

Usage

/api-contract-check [provider]
  • With a provider name: verify that provider's contracts.
  • Without an argument: detect the provider from the project's Pact config.

What it does

When you invoke this command, follow these steps:

  1. Locate the contracts. Look for a Pact setup — local pact files (pacts/*.json, **/*.pact.json), a pact config in package.json, or a configured Pact Broker (PACT_BROKER_BASE_URL). If a broker is configured, the contracts come from it; otherwise use the local pact files.
  2. Identify the verify task. Find the project's provider-verification entry point — a pact:verify npm script, a pact-provider-verifier invocation, or the equivalent in the project's test tooling.
  3. Run verification. Execute that verify task so each recorded consumer interaction is replayed against the provider, honoring its provider states.
  4. Report broken expectations. For every failing interaction, name the consumer, the request, and the exact mismatch (status code, body field, header, or missing provider state). Group results by consumer.
  5. Recommend the smallest fix. For each failure, suggest the minimal provider change that satisfies the contract, or flag when the consumer expectation itself is stale.
  6. Bootstrap if missing. If no Pact setup exists, explain how to add it: record consumer expectations with a Pact mock, publish the pacts, and wire a provider-verification task.

Output format

  • Contracts: source (broker or local) and the consumers covered.
  • Result: interactions passed / failed.
  • Failures: consumer, interaction, and the precise mismatch.
  • Fix: the minimal provider change per failure.
  • Verdict: safe to release against these consumers, or blocked.

Requirements

  • A Pact-based contract test setup (for example @pact-foundation/pact / pact-js) with consumer contracts available locally or via a Pact Broker.
  • The provider runnable locally (or a documented stub) so interactions can be replayed.
  • Broker access configured (PACT_BROKER_BASE_URL and credentials) when contracts live in a broker.

Safety notes

Running the command executes the project's Pact provider-verification task, which typically starts the provider or a stub and replays recorded requests against it. It performs read-and-verify actions only and never deploys, publishes, or mutates the provider. Review what the verify task does before running it.

Privacy notes

Pact contract files and verifier output include example request/response bodies, headers, and provider state names, which enter the model context to explain failures. If those examples contain real customer data or tokens, review the pacts before running on sensitive contracts. The command writes nothing to disk beyond the verifier's own logs.

Source and references

Source citations

Add this badge to your README

Show that /api-contract-check - API Contract Check Command for Claude Code is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/commands/api-contract-check.svg)](https://heyclau.de/entry/commands/api-contract-check)

How it compares

/api-contract-check - API Contract Check Command for Claude Code side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

2 trust signals differ across this comparison (Source provenance, Submitter).

Field

Slash command that runs consumer-driven contract verification for an HTTP API using Pact.

Open dossier

Community slash command runbook for frontend visual QA using documented Claude Code Chrome integration workflows: enable /chrome, open a local page, read console messages, and follow the design verification checklist from the Chrome integration guide.

Open dossier

Slash command that reviews the supply-chain risk of a project's dependencies using OpenSSF Scorecard health signals rather than CVE counts.

Open dossier

Community slash command runbook for adding minimal automated tests around a changed module: inspect the git diff, mirror repository test conventions, and draft focused unit or integration tests using Anthropic develop-tests guidance.

Open dossier
Next steps
Trust
Review statusReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceDiffersSource-backedSubmission linkedSource submissionSource-backedSubmission linkedSource submission
SubmitterDifferstechforgeworkskiannidevtechforgeworkskiannidev
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
Brand
Categorycommandscommandscommandscommands
SourceSource-backedSource-backedSource-backedSource-backed
Authortechforgeworkskiannidevtechforgeworkskiannidev
Added2026-06-042026-06-162026-06-042026-06-16
Platforms
Harness
Source repo
Safety notesFollowing the command runs the project's Pact provider-verification step, which typically starts the provider (or a stub of it) and replays recorded requests against it; review what the verify task does before running it. It performs read and verify actions only - it replays existing consumer contracts and reports pass or fail; it does not deploy, publish, or mutate the provider. When a Pact Broker is configured it fetches consumer contracts over the network using the project's existing broker credentials; it never prints those credentials.Chrome integration runs in a visible browser with your logged-in session; avoid production admin flows. Handle login pages and CAPTCHAs manually when the integration pauses.Queries the public OpenSSF Scorecard API and OSV API with read-only GET requests to look up already-published health scores and advisories; it changes nothing in your project or in any dependency. When the optional scorecard CLI is used to score a repository that is not already in the public dataset, it performs read-only analysis and needs a GitHub token; it never modifies repositories. The review is advisory - it ranks risk and recommends actions, but it does not pin, update, remove, or vendor any dependency on its own.Generated tests are drafts; run the project's test command locally before committing. Do not add network calls, production credentials, or destructive setup to proposed tests.
Privacy notesPact contract files and verification output contain example request and response bodies, headers, and provider state names, which enter the model context to explain failures. If those example payloads include real customer data or tokens, that text becomes part of the prompt; review the pacts before running on sensitive contracts. The command itself writes nothing to disk beyond the verifier's own logs.Console logs and screenshots may include staging data; redact before external sharing.External lookups can expose dependency names, versions, scoped package names, and repo identifiers to public Scorecard and OSV APIs; skip private/internal packages and private repos unless the user explicitly approves sharing that metadata. Scorecard and OSV responses (numeric check scores and advisory text) enter the model context to explain the risk ranking. It writes nothing to disk beyond any output you choose to redirect.Use synthetic fixtures only; do not copy production logs or customer records into tests.
Prerequisites— none listed
  • Claude Code 2.0.73+ and Claude in Chrome extension 1.0.36+ on Chrome or Edge.
  • Local dev server reachable from the operator browser session.
— none listed
  • Git repository with an existing test runner configured in package scripts or docs.
  • A concrete code change or diff hunk to cover with new or updated tests.
Install
/api-contract-check [provider]
/frontend-visual-qa <route-or-host>
/dependency-risk-review [package]
/targeted-test-generation <file-or-symbol>
Config
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.