What this prompt does
This prompt designs a complete, idiomatic Go error-handling system for an application rather than scattered ad-hoc checks. You set [app_type] and the AI builds custom error types across your [error_categories], error wrapping with fmt.Errorf and the %w verb for context propagation, sentinel errors for [sentinel_cases], and proper errors.Is() and errors.As() inspection patterns. Getting sentinel errors, %w wrapping, and errors.As mapping right is the difference between a debuggable Go service and an opaque one that swallows the information you need at 3 a.m.
The variables shape the system to your specific app. [error_categories] defines the taxonomy of validation, not found, unauthorized, conflict, internal, and timeout, which directly drives the HTTP status-code mapping, while [sentinel_cases] names the exact sentinel errors your domain needs callers to branch on. [logger] sets structured error logging with request ID, user ID, and operation. The prompt also covers stack-trace capture without leaking it to clients, error aggregation for batch operations, a fluent error-builder pattern, and explicit anti-patterns like error-string matching and swallowed errors.
When to use it
- Designing error handling for a new Go API or microservice from the ground up
- Mapping error categories cleanly to HTTP status codes and safe client messages
- Standardizing sentinel errors and %w wrapping consistently across a codebase
- Adding structured error logging that carries request and user context for debugging
- Aggregating multiple errors cleanly from batch or bulk operations
- Auditing existing code against well-known Go error-handling anti-patterns
Example output
You get a set of custom error types organized by your [error_categories], wrapping helpers using %w, declared sentinel errors for [sentinel_cases], and clear errors.Is/errors.As inspection examples. It includes an error-to-HTTP mapping, stack-trace capture kept strictly internal, structured logging with context fields via [logger], batch-error aggregation, a fluent error-builder API, unit tests for the error types and wrapping, and a list of anti-patterns to avoid with corrected examples drawn from real scenarios. The HTTP mapping translates each category in [error_categories] to the right status code, so clients get a consistent and predictable error contract.
Pro tips
- Set
[error_categories]to match how your API really responds; the HTTP status mapping depends entirely on it - Name
[sentinel_cases]after real domain conditions so callers can branch on them cleanly with errors.Is - Keep
[logger]consistent with the rest of your stack; slog is a solid, dependency-free structured default - Use %w wrapping to add context, but avoid over-wrapping; each layer should add genuinely new information
- Never expose captured stack traces to clients; log them internally and return clean, category-appropriate messages
- Use the error-aggregation pattern for batch operations so one failed item does not silently mask the others in the run
- Apply errors.As for typed inspection rather than string matching, which the prompt rightly flags as an anti-pattern
