What problem does it solve? Implementing RPC handlers in Go often leads to bloated server code that mixes business logic, error translation, logging, and dependency wiring into one place. This Skill enforces a strict convention for writing thin Connect-RPC handlers where each RPC maps to exactly one usecase, conversions are pure functions, and cross-cutting concerns live in interceptors. ## Core Features & Use Cases - Thin server implementation: Each RPC method follows a fixed four-line shape (caller, convert, Execute, respond) with no branching, logging, or error translation inside the handler. - Pure conversion functions: Request-to-input and output-to-response mapping functions named {source}To{target} that reject missing required fields with public sentinels instead of defaulting nil timestamps to 1970. - Interceptor-based cross-cutting concerns: A Logging interceptor that recovers panics, logs once per RPC, and translates errors to connect.Code via a single translation table, plus an Auth interceptor that places the caller identity into request scope. - Composition root wiring: A NewMux(Deps) function assembling tx, repositories, usecases, server, and interceptors inside-out, with main calling run(ctx) error for graceful shutdown. - Use Case: Given a proto file defining a ReservationService and existing usecases, generate the server struct, mapping functions, error table entries, and wiring so the RPC compiles and passes pre-written red tests. ## Quick Start Implement the ConfirmReservation RPC handler from this proto file, connecting it to the existing usecase with conversion functions and interceptor wiring.
