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.
npx agentmods add agents/vibeeval/vibecosystem/contract-testing-expertgit clone --depth 1 https://github.com/vibeeval/vibecosystemWhat 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 | $0.00023 | $0.01547 |
| Opus 5 | $0.00012 | $0.00773 |
| Sonnet 5 | $0.00005 | $0.00309 |
| Haiku 4.5 | $0.00002 | $0.00155 |
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.
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')
})
})
})
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 · 201 lines · 23 tokens per session scan A 7db88fccec1f
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.
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.
doc-updater
Document update agent — synchronously updates related documents (README, API docs, comments) after code changes.
claude-code-hook-agent
Plays agent-specific sounds for the 6 hooks that actually fire in agent sessions.
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…
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…
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.