What problem does it solve? When a feature spans multiple deployable sides, teams risk drifting API contracts, duplicated schemas, and diverging names between consumer and producer. This Skill reconciles the operations implied by a building-block manifest into one executable OpenAPI YAML per boundary, keeping names aligned with the project's ubiquitous language. ## Core Features & Use Cases - Contract reconciliation: Derives the operation skeleton from the manifest's cross-deploy boundaries (commands become writes, views become reads) and fills in request/response schemas. - Re-entrant extension: Scans existing *.openapi.yaml files and extends the boundary's existing contract additively instead of forking a second source of truth, classifying every change as additive or breaking. - Canonical naming and error contracts: Names components/schemas with the canonical domain vocabulary and always models the consumer-driven 422 ValidationError shape. - Use Case: After running the model movement on a feature whose backend and frontend deploy separately, invoke this Skill to produce or extend the boundary's OpenAPI file, emit ADRs for versioning decisions, and hand stable operationIds to both sides' contract tests. ## Quick Start Ask the agent to reconcile the cross-deploy OpenAPI contract for the current feature from building-blocks.yaml, extending any existing contract for that boundary.
