design-an-api-contractlisted

# design-an-api-contract Write the boundary before filling in the implementation. The contract should let a consumer build against examples, let a provider change internals, and make failure behavior as clear as success behavior. ## When to use Use this skill for a new HTTP, event, RPC, or internal service interface with more than one consumer or an expected lifetime beyond one release. It also applies when an undocumented API has become a dependency. Do not create an external contract for a function that can remain local. Do not put credentials, private fields, or unrestricted internal errors into examples. Treat published field names and behavior as commitments unless the contract says otherwise. ## Preconditions - Identify provider and consumer owners, use cases, data classification, and expected lifetime. - Collect two real consumer workflows, including one retry or partial-failure case. - Record transport, authentication, authorization, latency, volume, and retention constraints. - Decide who approves breaking changes and how consumers will be notified. ## Procedure 1. Model domain resources and operations in consumer language. Avoid exposing internal tables. 2. Write one minimal successful request and response for each real workflow. 3. Define field types, formats, required and optional status, null behavior, defaults, limits, ordering, pagination, filtering, and time-zone rules in a versioned schema. 4. Specify the error model: stable code, human message, re