refactor-state-errors

Refactor Rust service errors into thiserror enums with centralized messages.

15|Updated Feb 24, 2026
One-click install
npx skills add https://github.com/moriyoshi/winterbaume --skill refactor-state-errors
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: refactor-state-errors
Source: https://github.com/moriyoshi/winterbaume/tree/main/.agents/skills/refactor-state-errors
Command: npx skills add https://github.com/moriyoshi/winterbaume --skill refactor-state-errors

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Refactor a service crate's state module to use domain-specific error enums instead of constructing end-user-facing error structs (error_type/message/status) and move error shaping into the handler layer.

Core Features & Use Cases

  • Introduces a domain-focused error enum using thiserror to represent service errors without HTTP/wire knowledge.
  • Replaces all {Service}Error { error_type: ..., message: ..., status: ... } constructions in state.rs with explicit enum variants.
  • Updates the handler error-shaping function to exhaustively map enum variants to wire responses, while using err.to_string() for the message to keep a single source of truth.

Quick Start

Replace end-user error structs in state.rs with a domain-specific error enum and move domain-to-wire error mapping into handlers.rs.

Frequently Asked Questions about refactor-state-errors

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

FAQPage Schema
How do I refactor Rust service errors into domain-specific enums?

Refactoring Rust service errors into domain-specific enums involves replacing plain end-user error structs in state.rs with a domain error enum using thiserror, keeping message text centralized within the enum variants themselves.

Why use thiserror for domain error handling in Rust?

Using thiserror for domain error handling in Rust allows you to define domain-specific error enums that represent service errors without HTTP or wire knowledge, enforcing a clean separation between domain logic and handler error shaping.

What is the best way to separate domain errors from wire format responses in Rust?

The best way to separate domain errors from wire format responses is to move domain-to-wire error mapping into handlers.rs, exhaustively matching enum variants to wire responses while using err.to_string() to maintain a single source of truth for messages.

Do I need to update Cargo.toml dependencies to use thiserror for error refactoring?

Yes, you need to add thiserror to your Cargo.toml dependencies to use thiserror for error refactoring, replacing state.rs error struct constructions with explicit enum variants and updating handlers.rs accordingly.

How does exhaustive matching work when mapping Rust error enums to wire responses?

Exhaustive matching when mapping Rust error enums to wire responses requires the handler error-shaping function to explicitly cover every domain enum variant, ensuring all possible service errors are translated into appropriate wire formats without missing cases.

When should I move error shaping out of state.rs in a Rust service crate?

You should move error shaping out of state.rs in a Rust service crate when your service logic needs to represent errors without HTTP or wire knowledge, centralizing message text in domain enums and handling wire formatting exclusively in the handler layer.