api-contract-advanced
Advanced API contract patterns — AsyncAPI 3.0 for event-driven systems and Consumer-Driven Contract Testing with Pact. Use after the core Contract-First workflow in api-contract.
Best use case
api-contract-advanced is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Advanced API contract patterns — AsyncAPI 3.0 for event-driven systems and Consumer-Driven Contract Testing with Pact. Use after the core Contract-First workflow in api-contract.
Teams using api-contract-advanced should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/api-contract-advanced/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How api-contract-advanced Compares
| Feature / Agent | api-contract-advanced | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Advanced API contract patterns — AsyncAPI 3.0 for event-driven systems and Consumer-Driven Contract Testing with Pact. Use after the core Contract-First workflow in api-contract.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# API Contract — Advanced Patterns
For Kafka/NATS/SQS event interfaces and multi-consumer contract validation with Pact. For the core REST/OpenAPI workflow (steps 1-5), see `api-contract` first.
## When to Use
- Adding Kafka, NATS, SNS/SQS, or WebSocket interfaces (AsyncAPI)
- Multiple services consume the same API and need independent contract verification (Pact)
- Setting up `can-i-deploy` gates in CI
## Step 6: AsyncAPI for Event-Driven APIs
For Kafka, NATS, SNS/SQS, and WebSocket interfaces, use AsyncAPI 3.0 instead of OpenAPI.
```yaml
# api/v1/asyncapi.yaml
asyncapi: "3.0.0"
info:
title: Order Events
version: "1.0.0"
channels:
order/created:
address: "order.created"
messages:
OrderCreated:
$ref: "#/components/messages/OrderCreated"
order/cancelled:
address: "order.cancelled"
messages:
OrderCancelled:
$ref: "#/components/messages/OrderCancelled"
operations:
publishOrderCreated:
action: send
channel:
$ref: "#/channels/order~1created"
receiveOrderCreated:
action: receive
channel:
$ref: "#/channels/order~1created"
components:
messages:
OrderCreated:
payload:
type: object
required: [orderId, customerId, occurredAt]
properties:
orderId:
type: string
format: uuid
customerId:
type: string
format: uuid
totalAmount:
type: number
format: decimal
occurredAt:
type: string
format: date-time
```
Generate TypeScript types from AsyncAPI:
```bash
npx @asyncapi/generator \
api/v1/asyncapi.yaml \
@asyncapi/typescript-nats-template \
-o src/generated/events
```
---
## Step 7: Consumer-Driven Contract Testing (Pact)
When multiple consumers use the same API, each consumer defines what **they** need — and the provider verifies it can satisfy all of them.
```plantuml
@startuml
participant "Consumer A" as ca
participant "Consumer B" as cb
participant "Pact Broker" as broker
participant "Provider" as prov
group Consumer Tests
ca -> broker : publish Pact A\n(what A needs from Provider)
cb -> broker : publish Pact B\n(what B needs from Provider)
end
group Provider Verification
prov -> broker : fetch all Pacts
loop for each Pact
prov -> prov : run state handler\n(seed test data)
prov -> prov : replay requests\nagainst real server
prov -> broker : publish verification result
end
end
group Can-I-Deploy
ca -> broker : can-i-deploy\nConsumer A → prod?
broker --> ca : YES (all verifications passed)
cb -> broker : can-i-deploy\nConsumer B → prod?
broker --> cb : NO (verification failed)
end
@enduml
```
### Consumer Side (TypeScript)
```typescript
import { PactV3, MatchersV3 } from "@pact-foundation/pact"
const { like, eachLike } = MatchersV3
const provider = new PactV3({
consumer: "OrderService",
provider: "InventoryService",
})
describe("InventoryService contract", () => {
it("returns stock for a product", async () => {
await provider
.given("product abc-123 has 10 units in stock")
.uponReceiving("a request for product stock")
.withRequest({ method: "GET", path: "/products/abc-123/stock" })
.willRespondWith({
status: 200,
body: {
productId: like("abc-123"),
available: like(10),
},
})
.executeTest(async (mockServer) => {
const result = await getStock(mockServer.url, "abc-123")
expect(result.available).toBe(10)
})
})
})
```
### Provider Verification (TypeScript / Jest)
```typescript
import { Verifier } from "@pact-foundation/pact"
describe("InventoryService provider verification", () => {
it("satisfies all consumer pacts", () => {
return new Verifier({
providerBaseUrl: "http://localhost:3000",
pactBrokerUrl: process.env.PACT_BROKER_URL,
provider: "InventoryService",
stateHandlers: {
"product abc-123 has 10 units in stock": async () => {
await db.seed({ productId: "abc-123", stock: 10 })
},
},
}).verifyProvider()
})
})
```
---
## Related Skills
- `api-contract` — Core REST/OpenAPI contract-first workflow (Steps 1-5)
- `contract-testing` — Consumer-Driven Contract Testing patterns and Pact setup
- `event-driven-patterns` — Kafka, NATS, and message queue architectureRelated Skills
typescript-patterns-advanced
Advanced TypeScript — mapped types, template literal types, conditional types, infer, type guards, decorators, async patterns, testing with Vitest/Jest, and performance. Extends typescript-patterns.
tdd-workflow-advanced
TDD anti-patterns — writing code before tests, testing implementation details instead of behavior, using waitForTimeout as a sync strategy, chaining tests that share state, mocking the system under test instead of its dependencies.
swift-patterns-advanced
Advanced Swift patterns — property wrappers, result builders, Combine basics, opaque & existential types, macro system, advanced generics, and performance optimization. Extends swift-patterns.
serverless-patterns-advanced
Advanced Serverless patterns — Lambda idempotency (Lambda Powertools + DynamoDB persistence layer), Lambda cost model (pricing formula, break-even vs containers), and CloudWatch Insights observability queries for cold starts, duration, and errors.
security-review-advanced
Security anti-patterns — localStorage token storage (XSS risk), trusting client-side authorization checks, reflecting full error details to clients, blacklist vs whitelist input validation, using npm install instead of npm ci in CI pipelines.
rust-testing-advanced
Advanced Rust testing anti-patterns and corrections — cfg(test) placement, expect() over unwrap(), mockall expectation ordering, executor mixing (#[tokio::test] vs block_on), PgPool isolation with
rust-patterns-advanced
Advanced Rust patterns — zero-cost abstractions, proc macros, unsafe FFI, WASM, Axum web architecture, trait objects vs generics, and performance profiling.
python-testing-advanced
Advanced Python testing — async testing with pytest-asyncio, exception/side-effect testing, test organization, common patterns (API, database, class methods), pytest configuration, and CLI reference. Extends python-testing.
python-patterns-advanced
Advanced Python patterns — concurrency (threading, multiprocessing, async/await), hexagonal architecture with FastAPI, RFC 7807 error handling, memory optimization, pyproject.toml tooling, and anti-patterns. Extends python-patterns.
multi-agent-patterns-advanced
Advanced multi-agent patterns — capability registry, durable state (Redis/DynamoDB), task decomposition, testing multi-agent systems, pattern quick-selection guide, failure handling, cost management, and worktree isolation. Extends multi-agent-patterns.
microfrontend-patterns-advanced
Advanced Micro-Frontend patterns — testing strategy (unit per-remote, integration with mocked remotes, E2E full composition via Playwright), CI/CD independent deployments per remote, ErrorBoundary resilience, and monolith-to-MFE strangler-fig migration.
hexagonal-typescript-advanced
Advanced Hexagonal Architecture anti-patterns for TypeScript — domain importing framework dependencies, use cases depending on concrete adapters, HTTP handlers bypassing use cases, Zod validation inside the domain model. Each anti-pattern includes wrong/correct comparison with explanation.