Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/PramodDutta/qaskillsnpx agentmods add skills/pramoddutta/qaskills/contract-test-generatorWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/pramoddutta/qaskills/contract-test-generator)<a href="https://agentmods.dev/skills/pramoddutta/qaskills/contract-test-generator"><img src="https://agentmods.dev/badge/skills/pramoddutta/qaskills/contract-test-generator.svg" alt="Measured on agentmods" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00024 | $0.07728 |
| Opus 5 | $0.00012 | $0.03864 |
| Sonnet 5 | $0.00005 | $0.01546 |
| Haiku 4.5 | $0.00002 | $0.00773 |
Grade A, and why
Contract Test Generator scanned grade A with 2 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
await axios.post( Runs shell commandslowCapability
Expected in a hook, worth knowing in a rule or an instructions file.
import { execSync } from 'child_process'; How it starts
The opening of the file, as written. The whole thing — 922 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Contract Test Generator
Contract testing bridges the gap between unit tests and full integration tests by verifying that services can communicate correctly without requiring all services to be running simultaneously. Consumer-driven contract testing, pioneered by the Pact framework, inverts the traditional approach: consumers define what they expect from providers, and providers verify they can satisfy those expectations. This skill guides AI coding agents through generating robust contract tests that catch integration breaking changes before they reach production.
Core Principles
-
Consumer-Driven Design: Consumers define the contract based on what they actually use, not what the provider offers. This ensures contracts are minimal, focused, and reflect real usage patterns rather than hypothetical API surfaces.
-
Provider Verification Independence: Provider tests verify contracts independently without needing the consumer running. This decouples deployment schedules and enables teams to work autonomously while maintaining integration guarantees.
-
Contract as Shared Artifact: The contract (pact file) serves as a living specification between consumer and provider. It is versioned, stored centrally, and referenced by both sides during their respective CI pipelines.
-
Minimal Assertion Surface: Contracts should assert only what the consumer needs, not the full provider response. Testing for specific fields rather than entire response bodies prevents brittle contracts that break on harmless provider changes.
-
Versioning Alignment with Deployability: Every contract must be associated with a specific consumer version and verified against a specific provider version. The combination of these versions determines whether a deployment is safe.
-
Fail-Fast in CI: Contract verification failures must block deployments. The can-i-deploy tool provides a definitive answer about deployment safety based on the latest verification matrix.
-
Incremental Adoption: Contract tests can be introduced for the most critical interactions first, then expanded. There is no requirement to cover every endpoint immediately; focus on high-risk integration points.
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.
- 3d ago First seen · 922 lines · 24 tokens per session scan A b5753d339812
Contract Test Generator is a skill published in the GitHub repository PramodDutta/qaskills (217 stars, last pushed 7d ago), licensed MIT. It adds 24 tokens to every session and 7,728 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 2 findings (makes network calls, runs shell commands). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
backend-contract-testing
Use this skill when the user says 'contract testing', 'Pact', 'consumer-driven contracts', 'CDC', 'provider verification', 'pact test', 'pactflow', 'contract test', 'consumer test', 'provider test'. This skill implements consumer-driven contract testing using Pact to ensure microservices communicate correctly without…
api-testing-patterns
Comprehensive API testing patterns including contract testing, REST/GraphQL testing, and integration testing. Use when testing APIs or designing API test strategies.
contract-testing
Consumer-driven contract testing for microservices using Pact, schema validation, API versioning, and backward compatibility testing. Use when testing API contracts or coordinating distributed teams.
api-contract-tester
Implement consumer-driven contract testing with Pact to ensure API compatibility.
api-tester
Test and document API endpoints - validate responses, check status, generate examples.
backend/testing-guide
A guide for writing backend tests: small unit tests, tests that check connected parts such as an API and database, and end-to-end tests that follow a complete user flow.