What problem does it solve? Implementing the read side of CQRS in Go often drifts into restoring aggregates, opening transactions, or redefining contracts, which breaks layering and duplicates business rules. This Skill enforces a convention where read queries are built purely from SQL relational projection and aggregation, plus confirmed value objects or pure functions for calculations SQL cannot express. ## Core Features & Use Cases - Contract-driven read implementation: Uses the usecase-owned read port, read models, Page, and sentinels without redefining them, keeping dependencies pointing from implementation to contract. - SQL-first relational logic: Places JOINs, filtering, ordering, paging, and counts in sqlc-generated SQL, while SQL-unfriendly business calculations reuse existing value objects or pure functions. - Strict prohibitions: Never restores or mutates aggregates or entities, never writes, never starts transactions, and translates :one zero-row results into the contract's ErrNotFound sentinel. - Use Case: Given a reservation history read contract and a finalized data model, implement a paged query that joins parent reservations with history events and maps rows to querycontract.ReservationHistory. ## Quick Start Implement the availability list query for this read contract using the finalized data model, keeping all aggregation in SQL and mapping rows to the usecase-owned read model.
