contract-first

Topics in the source

• Contract-First Collaboration
• When to Activate
• The Boundary Artifact
• Consumer-First Workflow
• 1. Identify Consumers and Owners
• 2. Describe Consumer Jobs
• 3. Define the Smallest Useful Contract
• 4. Generate or Derive Consumer Types

Coordinate frontend/backend or service-to-service work through one authoritative, machine-checkable contract. Consumers state what they need, providers implement that shape, and both sides verify against the same artifact before integration. This skill governs how teams change a boundary. It complements api-design, which governs what a good API looks like, and ai-regression-testing, which guards fixed bugs from returning. Frontend and backend work will proceed in parallel. Two or more services exchange API payloads, events, or commands. Field names, nullability, enums, or error shapes regularly drift. One consumer needs several calls because the provider exposed storage models instead of a task-oriented response. A provider change can break consumers maintained by another person or agent. Mock responses and production responses no longer have the same shape. Do not add contract machinery to a single-module boundary that changes in one atomic commit and has no independent consumer. A shared type may be enough. Choose one canonical, version-controlled artifact for each boundary: OpenAPI for HTTP APIs AsyncAPI for event-driven APIs Protocol Buffers for RPC or message schemas JSON Sche

This is an excerpt. Refer to the complete source and its current requirements.