error-handling

What problem does it solve? Software failures are often handled inconsistently: errors get swallowed, logged and ignored, or leaked across boundaries without context. This Skill enforces explicit failure contracts so every error is typed, translated at boundaries, and either recovered, retried, translated, or re-raised with its cause preserved. ## Core Features & Use Cases - Typed Failure Contracts: Ensures expected failures use named exception classes, discriminated unions, or structured Result variants instead of bare strings or generic errors. - Boundary Translation: Prevents domain, infrastructure, API, CLI, and UI errors from leaking across layers unchanged while preserving the original cause for diagnostics. - Remote Call Resilience: Requires timeout, retry budget, idempotency, and dependency-failure behavior (circuit breaker, bulkhead, fail fast) to be declared before callers are written. - Use Case: When reviewing a service that calls a payment API, use this Skill to verify the call declares a timeout, retries only idempotent transient failures with jittered backoff in one layer, and returns an actionable user-facing error without exposing internals. ## Quick Start Use the error-handling skill to review the error propagation and user-facing failure shape in this module.