sd-rust-design

Designs Rust type surfaces and domain models that make illegal states unrepresentable.

Updated Jun 26, 2026
One-click install
npx skills add https://github.com/platypeeps/sd-ai-command-pack --skill sd-rust-design-platypeeps
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sd-rust-design
Source: https://github.com/platypeeps/sd-ai-command-pack/tree/main/contrib/sd-rust-design
Command: npx skills add https://github.com/platypeeps/sd-ai-command-pack --skill sd-rust-design-platypeeps

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Rust developers often encode domain rules as runtime checks, optional fields, and boolean flags, which lets invalid states compile and fail only in production. This Skill guides the design of structs, enums, newtypes, and typestate machines so the compiler itself rejects illegal states before any behavior is written. ## Core Features & Use Cases - Type-driven domain modeling: Replace state-dependent Option<T> fields and boolean flags with enum variants that each carry exactly the data their state needs. - Typestate and constrained types: Encode state machines as consuming transitions between distinct types, and choose between newtype wrappers and validating constructors per value. - Parse-don't-validate error design: Build fallible constructors returning Result<Self, Error> with railway-style error composition using ?, .map_err(), and #[from]. - Use Case: When adding a Connection type to a network service, model it as an enum with Idle, Connected { socket }, and Failed { error } variants instead of a struct with two optional fields, so callers can never observe a half-initialized connection. ## Quick Start Ask the AI to design the Rust types for your domain model or state machine so that illegal states are unrepresentable, before writing any implementation logic.

Frequently Asked Questions about sd-rust-design

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

FAQPage Schema
How do I make illegal states unrepresentable in Rust?▼

Replace state-dependent Option fields and boolean flags with enum variants that each carry exactly the data their state needs. For example, model a connection as enum variants Idle, Connected { socket }, and Failed { error } instead of a struct with optional socket and error fields.

How to model a state machine in Rust with types?▼

Use the typestate pattern: each state is its own type, and a transition consumes the current state and returns the next one. The compiler then enforces the transition graph, so invalid sequences like using an unverified value fail to compile.

When should I use a newtype versus a validating constructor in Rust?▼

Use a newtype with a public field when every inner value is valid and only identity confusion is at stake, such as user id versus team id. Use a private field with a single validating constructor when only some values are valid, like email formats or non-zero ports.

Should Rust constructors return Result or panic on invalid input?▼

Fallible constructors should return Result<Self, Error> with the error enum written up front, following the parse-don't-validate principle. Downstream code then accepts only already-valid types, so no check is repeated and no validate-then-use gap opens.

What are the limitations of relying on Rust types for correctness?▼

Types cannot prove derive behavior, serialization semantics, or runtime logic. For example, an untagged serde enum with overlapping variant shapes deserializes by declaration order at runtime, and the compiler never flags it, so such behavior needs inspection and review.