M13 Domain Error

This is a design-level guide for thinking through error handling strategy before you write code. It pushes you to answer "who needs to handle this error and how should they recover?" before choosing error types. The categorization tables break down user-facing versus internal errors, transient versus permanent, and map each to recovery patterns like retry with backoff or circuit breakers. What I like here is the trace up/trace down structure: it connects error design to domain constraints above (like SLA requirements) and implementation patterns below (thiserror, tokio-retry). The quick reference on retry, fallback, and bulkhead patterns is practical. Sits at Layer 2, so it's about design choices rather than code mechanics.

skills.sh installs: 3.5K
GitHub stars: 1.6K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add actionbook/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