
M05 Type Driven
- 1.5k installs
- 1.3k repo stars
- Updated May 24, 2026
- actionbook/rust-skills
m05-type-driven is an agent skill for apply type-driven design with phantomdata, newtypes, and compile-time state validation in rust.
About
The m05-type-driven skill is designed for apply type-driven design with PhantomData, newtypes, and compile-time state validation in Rust. 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? Invoke when the user asks about type state, PhantomData, newtype, sealed traits, or builder patterns.
- Can the compiler catch this error?.
- Can invalid states be unrepresentable?.
- Can the type encode the invariant?.
M05 Type Driven by the numbers
- 1,459 all-time installs (skills.sh)
- +51 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Ranked #9 of 129 Rust skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
m05-type-driven capabilities & compatibility
- Capabilities
- can the compiler catch this error? · can invalid states be unrepresentable? · can the type encode the invariant?
What m05-type-driven says it does
CRITICAL: Use for type-driven design. Triggers: type state, PhantomData, newtype, marker trait, builder pattern, make invalid states unrepresentable, compile-time validation, seale
CRITICAL: Use for type-driven design. Triggers: type state, PhantomData, newtype, marker trait, builder pattern, make invalid states unrepresentable, compile-ti
npx skills add https://github.com/actionbook/rust-skills --skill m05-type-drivenAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.5k |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 3 / 3 scanners passed |
| Last updated | May 24, 2026 |
| Repository | actionbook/rust-skills ↗ |
How do I apply type-driven design with phantomdata, newtypes, and compile-time state validation in rust?
Apply type-driven design with PhantomData, newtypes, and compile-time state validation in Rust.
Who is it for?
Rust developers modeling invalid states as unrepresentable with type-state patterns.
Skip if: Skip for beginner syntax help without type-driven architecture goals.
When should I use this skill?
User asks about type state, PhantomData, newtype, sealed traits, or builder patterns.
What you get
Completed m05-type-driven workflow with documented commands, files, and expected deliverables.
- type-state structs
- newtype wrappers
- builder APIs with compile-time guarantees
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:
1. Can the type encode the constraint?
- Numeric range → bounded types or newtypes
- Valid states → type state pattern
- Semantic meaning → newtype
2. When is validation possible?
- At construction → validated newtype
- At state transition → type state
- Only at runtime → Result with clear error
3. Who needs to know the invariant?
- Compiler → type-level encoding
- API users → clear type signatures
- Runtime only → documentation
---
Trace Up ↑
When type design is unclear:
"Need to validate email format"
↑ Ask: Is this a domain value object?
↑ Check: m09-domain (Email as Value Object)
↑ Check: domain-* (validation requirements)| Situation | Trace To | Question |
|---|---|---|
| What types to create | m09-domain | What's the domain model? |
| State machine design | m09-domain | What are valid transitions? |
| Marker trait usage | m04-zero-cost | Static or dynamic dispatch? |
---
Trace Down ↓
From design to implementation:
"Need type-safe wrapper for primitives"
↓ Newtype: struct UserId(u64);
"Need compile-time state validation"
↓ Type State: Connection<Connected>
"Need to track phantom type parameters"
↓ PhantomData: PhantomData<T>
"Need capability markers"
↓ Marker Trait: trait Validated {}
"Need gradual construction"
↓ Builder: Builder::new().field(x).build()---
Quick Reference
| Pattern | Purpose | Example |
|---|---|---|
| Newtype | Type safety | struct UserId(u64); |
| Type State | State machine | Connection<Connected> |
| PhantomData | Variance/lifetime | PhantomData<&'a T> |
| Marker Trait | Capability flag | trait Validated {} |
| Builder | Gradual construction | Builder::new().name("x").build() |
| Sealed Trait | Prevent external impl | mod private { pub trait Sealed {} } |
Pattern Examples
Newtype
struct Email(String); // Not just any string
impl Email {
pub fn new(s: &str) -> Result<Self, ValidationError> {
// Validate once, trust forever
validate_email(s)?;
Ok(Self(s.to_string()))
}
}Type State
struct Connection<State>(TcpStream, PhantomData<State>);
struct Disconnected;
struct Connected;
struct Authenticated;
impl Connection<Disconnected> {
fn connect(self) -> Connection<Connected> { ... }
}
impl Connection<Connected> {
fn authenticate(self) -> Connection<Authenticated> { ... }
}---
Decision Guide
| Need | Pattern |
|---|---|
| Type safety for primitives | Newtype |
| Compile-time state validation | Type State |
| Lifetime/variance markers | PhantomData |
| Capability flags | Marker Trait |
| Gradual construction | Builder |
| Closed set of impls | Sealed Trait |
| Zero-sized type marker | ZST struct |
---
Anti-Patterns
| Anti-Pattern | Why Bad | Better |
|---|---|---|
| Boolean flags for states | Runtime errors | Type state |
| String for semantic types | No type safety | Newtype |
| Option for uninitialized | Unclear invariant | Builder |
| Public fields with invariants | Invariant violation | Private + validated new() |
---
Related Skills
| When | See |
|---|---|
| Domain modeling | m09-domain |
| Trait design | m04-zero-cost |
| Error handling in constructors | m06-error-handling |
| Anti-patterns | m15-anti-pattern |
Related skills
Forks & variants (1)
M05 Type Driven has 1 known copy in the catalog totaling 800 installs. They canonicalize to this original listing.
- zhanghandong - 800 installs
How it compares
Use m05-type-driven over generic Rust lint skills when domain modeling needs compile-time state machines and newtype-heavy API design guidance.
FAQ
What does m05-type-driven do?
Apply type-driven design with PhantomData, newtypes, and compile-time state validation in Rust.
When should I use m05-type-driven?
User asks about type state, PhantomData, newtype, sealed traits, or builder patterns.
Is m05-type-driven safe to install?
Review the Security Audits panel on this page before installing in production.