What problem does it solve? Deciding whether to wrap primitive types (String, int, float) in domain-specific types is a recurring design dilemma. Wrapping everything leads to Value Object Obsession with boilerplate-heavy wrapper classes, while wrapping nothing causes Primitive Obsession where domain constraints are invisible in code. This Skill provides a rational, cost-benefit-based decision framework to avoid both extremes. ## Core Features & Use Cases - Five-Criteria Decision Framework: Evaluates domain invariants, mix-up risk, domain operations, inseparable value pairs, and usage frequency to determine if wrapping is justified. - Three Wrapping Levels: Guides selection between lightweight type aliases (newtype/Branded Types), constructor-validated types (Smart Constructor), and full behavioral domain types. - Terminology Clarification: Disambiguates Value Object definitions across PofEAA (Fowler), DDD (Evans), and general usage to prevent team confusion during reviews. - Use Case: During a code review, you notice fn transfer(from: String, to: String, amount: f64) where arguments can be swapped silently. Use this Skill to determine that UserId/OrderId-style newtypes and a Money type are warranted, while a simple display name string should stay primitive. ## Quick Start Ask the AI whether a specific primitive value in your code should be wrapped in a domain type, for example by requesting an evaluation of whether an email address string field should become a dedicated type.
