api-break-checklisted

# API Break Check Catch the API change that quietly breaks existing consumers — and turn it into a backward-compatible change or a clean versioned migration before it ships. A single innocent-looking edit (renaming a response field, adding a required parameter, tightening a validation rule, removing an enum value) can break every client already calling your API. It passes review because the diff looks like an improvement, tests pass because they use the *new* shape, and then a mobile app that can't be force-updated, a partner integration, or another team's service starts throwing errors in production. This skill reviews the change, explains exactly *who* breaks and *why*, and produces a compatible path. ## When to use this - You are **writing** a change to an API contract (spec, schema, proto, or the code behind it) and want it checked before commit. - You are **reviewing** an API diff in a PR. - You are about to **release** a new API version or deprecate a field. - Someone asks "is this a breaking change?", "will this break existing clients?", or "how do I change this without a new version?". If the API has a single internal caller you fully control and can deploy in lockstep, some of these rules relax — say so. The stakes scale with how many consumers you *can't* see or update. For a public API, assume someone depends on every observable behavior. ## Workflow 1. **Establish context.** Identify the **interface** (REST/OpenAPI, GraphQL, gRPC/protobuf) and the **