golang-samber-oops

Implements structured error handling in Go using the samber/oops builder pattern.

1|Updated Feb 2, 2026
One-click install
npx skills add https://github.com/rockcookies/skills --skill golang-samber-oops-rockcookies
Or copy as Structured Prompt for Agentâ–¼
Please help me install this Agent Skill.
Skill: golang-samber-oops
Source: https://github.com/rockcookies/skills/tree/main/skills/samber-golang/golang-samber-oops
Command: npx skills add https://github.com/rockcookies/skills --skill golang-samber-oops-rockcookies

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires github.com/samber/oops, and includes references (resource) components.

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 you to build structured errors with samber/oops that carry domain, attributes, trace IDs, and stack traces so on-call engineers can diagnose failures without asking the developer. ## Core Features & Use Cases - Fluent Error Builder: Chain methods like .In(), .Tags(), .Code(), .With(), .User(), and .Tenant() to attach structured context, then terminate with .Errorf(), .Wrap(), or .Wrapf(). - Low-Cardinality Messages: Keep variable data in .With() attributes instead of interpolating into message strings, so APM tools like Datadog, Loki, and Sentry group errors correctly. - Panic Recovery & Context Propagation: Convert panics to structured errors with .Recover() at goroutine boundaries, and propagate pre-configured builders through Go contexts using oops.WithBuilder and oops.FromContext. - Use Case: In a multi-tenant SaaS API, wrap errors at each layer (repository, service, HTTP handler) with layer-specific context, set a .Public() user-safe message, and retrieve it with oops.GetPublic(err, fallback) for the response. ## Quick Start Ask the AI to refactor your Go service's error handling to use samber/oops with structured attributes, error codes, and layered wrapping.

Frequently Asked Questions about golang-samber-oops

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add structured context to Go errors with samber/oops?â–¼

Use the fluent builder pattern: chain methods like .In("domain"), .Tags("database"), .With("key", value), and .Code("error_code"), then terminate with .Errorf() to create an error or .Wrapf(err, msg) to wrap an existing one.

How do I wrap errors in Go without a nil check using oops?â–¼

Call oops.Wrapf(err, "message") directly — it returns nil when err is nil, so the if err != nil guard and separate return nil are unnecessary. This simplifies error returns at every layer.

samber/oops vs standard Go errors: what is the difference?â–¼

Standard Go errors carry only a message string, while samber/oops adds structured attributes, stack traces, machine-readable codes, public user-safe messages, and trace IDs. Attributes travel with the error through the call stack instead of being added at the log site.

How do I separate user-facing messages from technical error details in Go?â–¼

Set the user-safe message with .Public("Not enough items in stock.") and keep technical details in .Errorf() or .Wrapf(). Retrieve the public message in handlers with oops.GetPublic(err, "fallback message").

How do I recover from panics in Go goroutines with samber/oops?â–¼

Use the builder's .Recover(fn) method with a named error return value instead of raw defer/recover. It converts the panic into a structured error carrying .In(), .Code(), .With() context and a stack trace.

Why do my error messages break grouping in Datadog or Sentry?â–¼

Interpolating variable data like user IDs into Errorf format strings creates high-cardinality messages that APM tools cannot group. Put variable data in .With() attributes and keep the message string static.