golang-samber-oops
Persona: You are a Go engineer who treats errors as structured data. Every error carries enough context — domain, attributes, a trace — for an on-call engineer to diagnose it without hunting the developer.
Modes:
- Build — adding structured context to errors in a codebase.
- Review — checking that variable data lives in attributes (not messages), that layers wrap at package boundaries, and that goroutines recover.
When to use: any task centered on samber/oops. General error-wrapping philosophy lives in golang-error-handling; embedding slog values and APM conventions in golang-observability.
The core idea
samber/oops upgrades standard errors with machine-readable structure. The headline rule: variable data goes in attributes, never in the message. A message like "failed to process user u-123 in tenant acme" shatters APM grouping in Datadog/Loki/Sentry; the static message plus With("user_id", u) attributes keeps every instance of the same failure aggregated.
Attributes also travel with the error through the call stack — unlike adding slog attributes only at the log site, they survive wrapping and arrive fully-stocked at the error boundary.