m13-domain-error

Name: m13-domain-error
Availability: InStock
Author: simorgh3196

Design domain error hierarchies with categorization, retry policies, and circuit breakers.

1|Updated May 29, 2026

Search Tags:#debugging #error-handling #retry #backoff #circuit-breaker #domain-errors #error-categorization

Ready to run

npx skills add https://github.com/simorgh3196/tsuzulint --skill m13-domain-error

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: m13-domain-error
Source: https://github.com/simorgh3196/tsuzulint/tree/main/.agents/skills/m13-domain-error
Command: npx skills add https://github.com/simorgh3196/tsuzulint --skill m13-domain-error

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill provides a rigorous approach to defining and applying domain-level error handling, enabling consistent error categorization, recovery strategies, and resilience across services.

Core Features & Use Cases

Categorize errors by audience (user-facing, internal, system, transient, permanent) to drive user messages and debugging.
Define recovery and degradation strategies with clear backoffs, fallbacks, and circuit breakers to improve reliability.
Establish error contexts and propagation patterns to support traceability and post-mortem analysis.

Quick Start

Draft a domain-error strategy document for your service by outlining error categories, recovery options, and propagation rules. 3-step quick start: identify error categories; specify retry/backoff and circuit-breaker policies; implement a typed error hierarchy with contextual information.

Frequently Asked Questions about m13-domain-error

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I design robust domain error handling for microservices?▼

Designing robust domain error handling involves creating a structured error hierarchy that categorizes errors by audience and specifies recovery strategies. This approach improves system reliability and debuggability across service boundaries by defining clear propagation patterns.

What is the best way to categorize transient versus permanent domain errors?▼

Categorizing transient versus permanent domain errors requires classifying them by audience, such as user-facing, internal, or system. This categorization drives appropriate user messages and debugging contexts while dictating whether retry, backoff, or fallback strategies apply.

How do I implement retry and backoff policies with circuit breakers for error recovery?▼

Implementing retry and backoff policies with circuit breakers defines clear recovery and degradation strategies for your services. This establishes resilience boundaries by specifying when to retry failed operations, apply backoff delays, or trip circuit breakers to prevent cascading failures.

When do I need structured error categorization across service boundaries?▼

You need structured error categorization across service boundaries when systems require consistent error context, clear recovery strategies, and traceability for post-mortem analysis. This structured propagation ensures errors remain observable and debuggable as they cross different services.

How do I specify user-facing versus internal errors in a typed error hierarchy?▼

Specifying user-facing versus internal errors in a typed error hierarchy involves defining error types with contextual information that drives appropriate user messages. This typed hierarchy separates external communication from internal debugging details while maintaining clear categorization rules.

What are the limitations of applying circuit breaker patterns to permanent domain errors?▼

Applying circuit breaker patterns to permanent domain errors is limited because circuit breakers are designed for transient failures requiring retry and backoff. Permanent errors should bypass circuit breakers and instead trigger immediate fallbacks or explicit user-facing error messages without retry attempts.