What problem does it solve? Teams need an independent acceptance gate that decides whether a finished API specification is complete enough for a client to call every operation and a server to implement it, without the author grading their own work. ## Core Features & Use Cases - Contract-completeness review: Judges an api-spec against a fixed 11-condition bar covering operations, typed request/response schemas, auth, error model, pagination, versioning, and examples. - Style-agnostic judging: Evaluates REST, GraphQL, and gRPC contracts in their own idiom, avoiding false rejections for missing HTTP status codes in non-REST styles. - Delta-scoped amend review: Reviews changes against an existing contract, checking additive/breaking classification, deprecation plans, and downstream ripple. - Use Case: After authoring an OpenAPI contract for a billing API, run this review to catch a happy-path-only operation missing its error cases before a client team integrates against it. ## Quick Start Use reviewing-api-spec on docs/specs/billing-api-spec.md and give me the verdict with actionable findings.