M13 Domain Error

Domain error handling strategy resource for Rust developers designing error types and recovery mechanisms. It addresses who needs to handle errors (end users, developers, or operations) and how to categorize them (transient vs. permanent, user-facing vs. internal) to determine appropriate recovery strategies like retries, fallbacks, and circuit breakers. The skill solves the problem of inconsistent error handling across application layers by providing a framework that connects domain requirements to implementation patterns.

skills.sh installs: 738
GitHub stars: 1.3K
last updated: Jul 14, 2026

View on GitHub

Install

$ npx -y skills add zhanghandong/rust-skills --skill m13-domain-error --agent claude-code

Installs into .claude/skills of the current project.

Files

Domain Error Strategy

Layer 2: Design Choices

Core Question

Who needs to handle this error, and how should they recover?

Before designing error types:

Is this user-facing or internal?
Is recovery possible?
What context is needed for debugging?

Error Categorization

Error Type	Audience	Recovery	Example
User-facing	End users	Guide action	`InvalidEmail`, `NotFound`
Internal	Developers	Debug info	`DatabaseError`, `ParseError`
System	Ops/SRE	Monitor/alert	`ConnectionTimeout`, `RateLimited`
Transient	Automation	Retry	`NetworkError`, `ServiceUnavailable`
Permanent	Human	Investigate	`ConfigInvalid`, `DataCorrupted`

Thinking Prompt

Before designing error types:

Who sees this error?
- End user → friendly message, actionable
- Developer → detailed, debuggable
- Ops → structured, alertable
Can we recover?
- Transient → retry with backoff
- Degradable → fallback value
- Permanent → fail fast, alert