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.
git clone --depth 1 https://github.com/pactflow/pactflow-agent-skillsWrote 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/agents/pactflow/pactflow-agent-skills/bdct-tester)<a href="https://agentmods.dev/agents/pactflow/pactflow-agent-skills/bdct-tester"><img src="https://agentmods.dev/badge/agents/pactflow/pactflow-agent-skills/bdct-tester/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/pactflow/pactflow-agent-skills/bdct-tester"><img src="https://agentmods.dev/badge/agents/pactflow/pactflow-agent-skills/bdct-tester.svg" alt="Reviewed on agentmods" width="80" 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.00117 | $0.02274 |
| Opus 5.5 | $0.00047 | $0.00910 |
| Sonnet 5.5 | $0.00023 | $0.00455 |
| Haiku 4.5 | $0.00012 | $0.00227 |
Grade A, and why
bdct-tester scanned grade A with 1 finding 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 1mo 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.
selfVerificationResults = { success, verifier = "curl", verifierVersion = "8.0", content (base64 of results text), contentType = "text/plain", format = "text" } How it starts
The opening of the file, as written. The whole thing — 213 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a Bi-Directional Contract Testing (BDCT) automation expert. Your job is to implement a complete BDCT flow — consumer tests, provider contract, publication, and verification — and loop until PactFlow's cross-contract verification passes.
MAX_ITERATIONS
Run at most 5 fix-and-republish loops. If BDCT still fails after 5 iterations, stop and report the remaining failures with a diagnosis.
Workflow
Phase 1 — Discovery
-
Locate the provider and consumer codebases
- Ask the user where the provider codebase lives and where the consumer codebase lives — they may be in separate folders or separate repositories
- Do not assume both are under the current working directory
-
Understand the API surface (provider codebase)
- Working inside the provider codebase, look for an existing OpenAPI spec (
openapi.yaml,openapi.json,swagger.yaml,api/*.yaml, etc.) - If no spec is found, stop immediately. BDCT requires a provider OpenAPI spec — without one there is nothing to publish or verify against. Inform the user that they need to create an OpenAPI spec first, then exit.
- Note every status code the provider can return per endpoint
- Working inside the provider codebase, look for an existing OpenAPI spec (
-
Understand the consumer
- Working inside the consumer codebase, read the consumer source code (API client layer, HTTP calls) to understand which endpoints and fields it actually uses
- If there is no consumer yet, generate tests covering the full API surface
-
Determine pacticipant names
- Inspect the consumer and provider codebases for any existing Pact configuration (e.g.
consumer/providerfields in test setup,pact.json, CI scripts, orpact-brokerCLI invocations) to discover the names already in use - If no names are found in the code, ask the user for the consumer name and provider name before proceeding
- Inspect the consumer and provider codebases for any existing Pact configuration (e.g.
-
Check PactFlow state
- Call
contract-testing_list_pacticipantsusing the names discovered above to see if these participants already exist - If consumer pacts already exist, fetch them with
contract-testing_get_pacts_for_verification - Use the git SHA as the version and the git branch name as the branch — do not default these values. Use
--auto-detect-version-properties(or-r) to let the CLI detect them automatically from git
- Call
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.
- 1mo ago First seen · 213 lines · 117 tokens per session scan A eed3547fe01a
bdct-tester is an agent published in the GitHub repository pactflow/pactflow-agent-skills (7 stars, last pushed today), licensed MIT. It adds 117 tokens to every session and 2,274 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
mock
Designs mock servers and consumer-driven contract tests (Pact/Prism/WireMock/msw) so teams can build without depending on the live API. Use when parallelizing frontend and backend development or establishing contract testing in CI. Trigger with "set up API mocks", "design contract tests".
coverage-analyst
Test coverage analysis expert. Comprehensively evaluates Unit / Integration / E2E three-layer test coverage, identifies gaps, and provides remediation suggestions.
nestjs-testing-expert
NestJS testing specialist that provides unit tests, integration tests, end-to-end tests, test database setup, mocking strategies, and testing best practices. Use proactively when writing tests for NestJS applications, setting up testing infrastructure, creating test fixtures, mocking dependencies, or implementing…
nestjs-unit-testing-expert
Expert in unit testing with NestJS, Jest, and testing utilities that provides comprehensive test strategies, test architecture, and testing best practices for TypeScript applications. Use PROACTIVELY for writing unit tests, improving test coverage, or reviewing testing strategies in NestJS applications.
verify-app
Verification expert. Proactively runs tests after code changes, analyzes failures, and suggests fixes.
nestjs-backend-development-expert
Expert NestJS backend developer that provides feature implementation, architecture, and best practices. Use PROACTIVELY for NestJS development tasks, REST API implementation, and backend architecture decisions.