Golang Error Handling
Install this skill so your coding agent applies consistent Go error-handling, structured logging, and oops-style context instead of ad-hoc log.Printf and stringly-typed errors.
Overview
golang-error-handling is an agent skill for the Build phase that teaches your agent production-style Go errors, slog logging, and structured context patterns aligned with eval scenarios.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-error-handlingWhat is this skill?
- Eval-driven rules for slog instead of log.Printf with structured key-value fields
- Low-cardinality error messages with context in oops.With, not interpolated IPs or limits in the string
- Middleware and multi-step chains that propagate errors up the stack with traceable logging
- Batch validation patterns that return or aggregate all failures, not only the first error
- Lowercase, operator-friendly error strings for production debugging
- Eval scenarios include middleware-log-chain and order-processor with multiple assertion ids per eval
Adoption & trust: 4.3k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps emitting log.Printf, vague errors, or interpolated request details instead of slog, oops context, and debuggable low-cardinality messages.
Who is it for?
Solo builders writing Go HTTP middleware, workers, or batch processors who want agent output to match slog and structured-error norms from day one.
Skip if: Teams that only need generic language-agnostic debugging advice or projects not written in Go.
When should I use this skill?
Generating or reviewing Go code where errors, slog, and operator-debuggable messages must follow team production conventions.
What do I get? / Deliverables
Generated Go code follows structured logging and error-wrapping conventions you can hand to code review or tests with fewer style fixes.
- Go functions and middleware with slog and structured error context
- Validation flows that surface all failures where the skill pattern applies
Recommended Skills
Journey fit
Error and logging conventions are enforced while you implement Go services and CLIs, before those patterns reach production under ship and operate. Backend is the canonical shelf because the evals target HTTP middleware, batch processors, and API-style failure propagation—not frontend or infra-only work.
How it compares
Use as a Go-focused procedural skill, not a runtime MCP server or generic debugger prompt.
Common Questions / FAQ
Who is golang-error-handling for?
Indie and solo developers building Go backends, CLIs, or services who want Claude Code, Cursor, or Codex to default to slog and structured errors instead of legacy logging habits.
When should I use golang-error-handling?
During Build backend work when drafting middleware, request handlers, or batch validators; also when refactoring error returns before Ship review or Operate incident debugging on Go services.
Is golang-error-handling safe to install?
It is instructional skill content without built-in network or shell requirements in the package itself; review the Security Audits panel on this Prism page before enabling it in your agent.
SKILL.md
READMESKILL.md - Golang Error Handling
{ "skill_name": "golang-error-handling", "evals": [ { "id": 1, "name": "middleware-log-chain", "prompt": "Write a Go HTTP middleware chain with 3 middlewares: LoggingMiddleware, AuthMiddleware, RateLimitMiddleware. Each wraps the next handler. Each middleware should log what it's doing at each step and propagate errors properly up the chain. The final handler processes a request. Include detailed logging at each layer so we can trace the request flow.", "trap": "\"log at each step\" tempts log+return violations and high-cardinality error messages with interpolated IPs/limits", "assertions": [ { "id": "1.1", "text": "Uses slog (not log.Printf)" }, { "id": "1.2", "text": "Low-cardinality error messages (no IPs/limits interpolated)" }, { "id": "1.3", "text": "Structured error context (oops.With, not in error string)" }, { "id": "1.4", "text": "Structured slog key-value log entries" }, { "id": "1.5", "text": "Error strings lowercase" } ] }, { "id": 2, "name": "order-processor", "prompt": "Write a Go function ProcessOrders(ctx context.Context, orders []Order) error that validates and processes each order. Order has ID, UserID, Amount, Currency fields. When validation fails (amount <= 0, empty currency, empty user ID), the error message should clearly indicate which order failed and why, so operators can debug issues in production. Return all errors, not just the first.", "trap": "\"indicate which order failed\" tempts interpolating order IDs into error strings", "assertions": [ { "id": "2.1", "text": "Log/APM grouping messages are low-cardinality; IDs and paths are attached as structured attributes rather than baked into the stable log message" }, { "id": "2.2", "text": "Variable data as structured attributes (oops/slog)" }, { "id": "2.3", "text": "Uses errors.Join to collect all order errors" }, { "id": "2.4", "text": "Error strings lowercase" }, { "id": "2.5", "text": "Validates ALL fields per order (no short-circuit)" } ] }, { "id": 3, "name": "batch-csv-importer", "prompt": "Write a Go function ImportCSV(r io.Reader) (int, error) that reads a CSV with columns: name, email, phone. It validates each row (name not empty, email contains '@', phone is digits only). It should return the count of successfully imported rows and a detailed failure report showing every invalid row with its row number and which column failed, so operators can fix the CSV and retry. Process ALL rows even if early ones fail.", "trap": "\"detailed failure report with row numbers\" tempts interpolating row/col into error strings", "assertions": [ { "id": "3.1", "text": "Error messages static (no row numbers in error string)" }, { "id": "3.2", "text": "Row/column data as structured attributes (oops/slog)" }, { "id": "3.3", "text": "Collects all row errors (doesn't stop on first)" }, { "id": "3.4", "text": "Error strings lowercase" }, { "id": "3.5", "text": "Uses errors.Join for combining errors" } ] }, { "id": 4, "name": "wrapped-error-compare", "prompt": "Fix the error handling in this Go code. All errors may be wrapped by middleware before reaching these handlers:\n\n```go\npackage storage\n\nimport (\n \"database/sql\"\n \"fmt\"\n \"net\"\n)\n\nvar ErrNotFound = fmt.Errorf(\"Not Found.\")\nvar ErrConflict = fmt.Errorf(\"Conflict: resource already exists.\")\n\ntype TimeoutError struct {\n Operation string\n Duration int\n}\nfunc (e *TimeoutError) Error() string {\n return fmt.Sprintf(\"Timeout after %ds on %s.\", e.Duration, e.Operation)\n}\n\nfunc HandleDBError(err error) string {\n if err == sql.ErrNoRows { return \"not found\" }\n if err == sql.ErrTxDone { return \"transaction completed\" }\n if te, ok := err.(*TimeoutError); ok { return fmt.Sprintf(\"ti