| name | domain-modeling |
| description | Use this skill for semantic types, primitive obsession, parse-don't-validate, invalid-state prevention, and domain-focused review. It is also the domain review lens for the TDD cycle. |
Domain Modeling
Use this skill when the code should express the business domain more precisely.
Core principles
- Replace domain-significant primitives with semantic types.
- Parse at the boundary, then trust the type inside the system.
- Make invalid states unrepresentable where the type system can do the work.
- Treat stateful booleans as a smell when an enum is the real model.
What to look for
String, int, number, or bool carrying domain meaning- identifiers without newtype wrappers
- contradictory field combinations that should be encoded as variants
- validation logic buried inside business logic instead of constructors or parsers
- swappable parameters that should be distinct semantic types
Review workflow
- Identify the domain concepts hidden inside primitives.
- Propose the smallest semantic type that captures the business meaning.
- Move validation to the type construction boundary.
- Re-check the model for impossible combinations and leaked validation.
Codex-specific guidance
- Use this skill during review and during TDD domain checkpoints.
- Push back on weak domain types even if the code "works."
- If the user deliberately accepts a weaker model for speed, say so explicitly and record the tradeoff.
Done when
- domain concepts are named in the type system
- invalid combinations are harder or impossible to construct
- business logic stops repeating low-level validation
