api-contract-testing · secondsky — Claude Code skill: what it does, how to install
Verifies API contracts between microservices with consumer-driven tests and OpenAPI schemas, skipping full end-to-end setups.
npx skills add secondsky/claude-skills --skill api-contract-testing -a claude-codeWhat api-contract-testing does
The skill outlines workflows for verifying interactions between API consumers and providers without full integration environments. It provides TypeScript snippets using @pact-foundation/pact, middleware patterns for express-openapi-validator, and references for Python JSON Schema or Java REST Assured.
Contracts test structural shape instead of rigid hard-coded values through matchers. Provider verification depends on a running target instance and the PACT_BROKER_URL environment variable.
What it helps with
- catch breaking API schema changes across microservices
- write consumer tests without provisioning end-to-end integration testbeds
- validate incoming HTTP payloads against OpenAPI files in Express
- verify provider compliance against contracts published to Pact Broker
Example prompts for the agent
- Write a Pact consumer test for the GET
/users/123route - Add OpenAPI schema validation to an Express app using
openapi.yaml - Set up provider contract verification for UserService with Pact Broker integration
How to install api-contract-testing
1Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill api-contract-testing -a claude-code2Manually: put the files in place
~/.claude/skills/api-contract-testing/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/api-contract-testing/
1Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill api-contract-testing -a codex2Manually: put the files in place
.agents/skills/api-contract-testing/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill api-contract-testing -a cursor2Manually: put the files in place
.cursor/skills/api-contract-testing/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install secondsky/claude-skills api-contract-testing2Manually: put the files in place
.github/skills/api-contract-testing/SKILL.md1Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill api-contract-testing -a gemini-cli2Platform CLI
gemini skills install https://github.com/secondsky/claude-skills --path plugins/api-contract-testing/skills/api-contract-testingManually: put the files in place
.devin/skills/api-contract-testing/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill api-contract-testing -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about api-contract-testing
How do I install api-contract-testing in Claude Code?
Run npx skills add secondsky/claude-skills --skill api-contract-testing -a claude-code. The file will be placed in ~/.claude/skills/api-contract-testing/SKILL.md.
What does api-contract-testing do?
It guides the agent through verifying request and response contracts between microservices. The skill relies on consumer-driven tests with Pact and schema validation via OpenAPI.
Which tools are covered in this skill?
The instructions reference Pact, Spring Cloud Contract, OpenAPI, Dredd, and Spectral, alongside examples for Express, Python, and Java.
Source text
SKILL.md · MIT
---
name: api-contract-testing
description: Verifies API contracts between services using consumer-driven contracts, schema validation, and tools like Pact. Use when testing microservices communication, preventing breaking changes, or validating OpenAPI specifications.
license: MIT
---
# API Contract Testing
Verify that APIs honor their contracts between consumers and providers without requiring full integration tests.
## Key Concepts
| Term | Definition |
|------|------------|
| Consumer | Service that calls an API |
| Provider | Service that exposes an API |
| Contract | Agreed request/response format |
| Pact | Consumer-driven contract testing tool |
| Schema | Structure definition (OpenAPI, JSON Schema) |
| Broker | Central repository for contracts |
## Pact Consumer Test (TypeScript)
```typescript
import { PactV3, MatchersV3 } from '@pact-foundation/pact';
const provider = new PactV3({
consumer: 'OrderService',
provider: 'UserService'
});
describe('User API Contract', () => {
it('returns user by ID', async () => {
await provider
.given('user 123 exists')
.uponReceiving('a request for user 123')
.withRequest({ method: 'GET', path: '/users/123' })
.willRespondWith({
status: 200,
body: MatchersV3.like({
id: '123',
name: MatchersV3.string('John'),
email: MatchersV3.email('[email protected]')
})
})
.executeTest(async (mockServer) => {
const response = await fetch(`${mockServer.url}/users/123`);
expect(response.status).toBe(200);
});
});
it('returns 404 for non-existent user', async () => {
await provider
.given('user does not exist')
.uponReceiving('a request for non-existent user')
.withRequest({ method: 'GET', path: '/users/999' })
.willRespondWith({
status: 404,
body: MatchersV3.like({
error: { code: 'NOT_FOUND', message: MatchersV3.string() }
})
})
.executeTest(async (mockServer) => {
const response = await fetch(`${mockServer.url}/users/999`);
expect(response.status).toBe(404);
});
});
});
```
## Provider Verification
```typescript
import { Verifier } from '@pact-foundation/pact';
new Verifier({
provider: 'UserService',
providerBaseUrl: 'http://localhost:3000',
pactBrokerUrl: process.env.PACT_BROKER_URL,
publishVerificationResult: true,
providerVersion: process.env.GIT_SHA,
stateHandlers: {
'user 123 exists': async () => {
await db.users.create({ id: '123', name: 'John' });
},
'user does not exist': async () => {
await db.users.deleteAll();
}
}
}).verifyProvider();
```
## OpenAPI Validation (Express)
```javascript
const OpenApiValidator = require('express-openapi-validator');
app.use(OpenApiValidator.middleware({
apiSpec: './openapi.yaml',
validateRequests: true,
validateResponses: true,
validateSecurity: true
}));
```
## Additional Implementations
- **Python JSON Schema**: See [references/python-json-schema.md](references/python-json-schema.md)
- **Java REST Assured**: See [references/java-rest-assured.md](references/java-rest-assured.md)
- **Pact Broker CI/CD**: See [references/pact-broker-cicd.md](references/pact-broker-cicd.md)
## Best Practices
**Do:**
- Test from consumer perspective
- Use matchers for flexible matching
- Validate structure, not specific values
- Version contracts explicitly
- Test error responses
- Run tests in CI pipeline
- Test backward compatibility
**Don't:**
- Test business logic in contracts
- Hard-code specific values
- Skip error scenarios
- Ignore versioning
- Deploy without verification
## Tools
- **Pact** - Multi-language consumer-driven contracts
- **Spring Cloud Contract** - JVM ecosystem
- **OpenAPI/Swagger** - Schema-first validation
- **Dredd** - API blueprint testing
- **Spectral** - OpenAPI linting
© secondsky · MIT · secondsky/claude-skills
Similar skills
All skills for Backend and APIs →api-contract-testing by other authors comes first.