What problem does it solve? Standard Go errors lack context: you see "connection failed" but not which user triggered it, what query was running, or the full call stack. This Skill guides AI coding agents to write structured, diagnosable error handling with samber/oops so on-call engineers can diagnose failures without asking the developer. ## Core Features & Use Cases - Fluent error builders: Chain .In(), .Tags(), .Code(), .With(), .User(), and .Tenant() to attach domain, categorization, machine-readable codes, and structured attributes to every error. - Low-cardinality messages: Keeps variable data in .With() attributes instead of interpolating it into message strings, so APM tools like Datadog, Loki, and Sentry can group errors correctly. - Panic recovery and context propagation: Converts panics to structured errors with oops.Recover() at goroutine boundaries and propagates pre-configured builders through Go contexts via oops.WithBuilder/oops.FromContext. - Use Case: In a three-layer Go service (handler, service, repository), wrap errors at each layer boundary with layer-specific context so a single error reaching the top carries the query, user ID, trace ID, and full stack trace. ## Quick Start Ask the agent to refactor the error handling in your Go service to use samber/oops with structured attributes, error codes, and public user-facing messages.
