M05 Type Driven

Pushes you to encode invariants in the type system before reaching for runtime validation. When you're about to add an is_valid flag or validate in every function, this asks whether the compiler could catch it instead. Covers newtypes for primitive obsession, type state patterns for state machines, PhantomData for variance markers, and builder patterns for gradual construction. The "Error to Design Question" table is the real gem here, reframing common runtime checks as type design opportunities. Honestly most useful when you catch yourself writing the same validation logic in multiple places. Traces up to domain modeling when unclear what types to create, traces down to concrete patterns like sealed traits and zero-sized types.

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

View on GitHub

Install

$ npx -y skills add actionbook/rust-skills --skill m05-type-driven --agent claude-code

Installs into .claude/skills of the current project.

Files

Type-Driven Design

Layer 1: Language Mechanics

Core Question

How can the type system prevent invalid states?

Before reaching for runtime checks:

Can the compiler catch this error?
Can invalid states be unrepresentable?
Can the type encode the invariant?

Error → Design Question

Pattern	Don't Just Say	Ask Instead
Primitive obsession	"It's just a string"	What does this value represent?
Boolean flags	"Add an is_valid flag"	Can states be types?
Optional everywhere	"Check for None"	Is absence really possible?
Validation at runtime	"Return Err if invalid"	Can we validate at construction?

Thinking Prompt

Before adding runtime validation:

Can the type encode the constraint?
- Numeric range → bounded types or newtypes
- Valid states → type state pattern
- Semantic meaning → newtype
When is validation possible?
- At construction → validated newtype
- At state transition → type state
- Only at runtime → Result with clear error