principle-model-the-domain
cursor/plugins
Encode domain logic in structures instead of scattered conditionals and repeated assumptions.
What is principle-model-the-domain?
Apply this principle when writing stateful logic, handling complex branching, or repeating shape assumptions across files. Instead of scattered booleans and conditional branches, model the domain as a data structure—state machines, typed objects, registries, reducers, or other patterns that make invalid states unrepresentable and eliminate branches.
- Replace scattered booleans and phase checks with state machines that encode valid transitions
- Use typed objects or discriminated unions instead of loose parameters and repeated shape assumptions
- Consolidate branching logic spread across files into maps, registries, or lookup tables
- Apply reducer or command/event patterns to replace ad hoc state mutations
- Organize modules around domain knowledge rather than execution order (load, validate, transform, save)
- Identify and encode data access patterns with appropriate structures: queues, caches, indexes, graphs, or normalized collections
How to install principle-model-the-domain
npx skills add https://github.com/cursor/plugins --skill principle-model-the-domainHow to use principle-model-the-domain
- 1.Identify where booleans, phases, or shape assumptions are scattered or repeated across your codebase
- 2.Determine what invalid states the code must never allow and how data is accessed
- 3.Choose an appropriate structure: state machine, typed object, registry, reducer, queue, cache, graph, or other pattern that fits
- 4.Encode the domain rules and valid transitions in that structure
- 5.Replace scattered conditionals and branches with lookups or transitions through the structure
- 6.Verify that invalid states are now unrepresentable and branches are eliminated
Use cases
- Refactoring code with growing if/else chains that add new branches for each feature
- Eliminating multiple booleans that must stay synchronized across a codebase
- Consolidating repeated shape assumptions and validation logic scattered across files
- Simplifying stateful logic by encoding valid states and transitions explicitly
- Replacing temporal decomposition where phase-named modules repeat the same domain rules
- Backend engineers managing complex state and business logic
- Full-stack developers building feature-rich applications with intricate branching
- Architects refactoring codebases with scattered conditionals and repeated patterns
- Teams maintaining systems where invalid states can currently occur
principle-model-the-domain FAQ
Apply it when writing stateful logic, when code branches a lot, or when you notice the same shape assumption repeated across files. Avoid it if the current shape is already clear, local, and unlikely to grow.
A new feature that grows an existing if/else chain by one more branch, or a second boolean that must stay in sync with the first. Temporal decomposition (phase-named modules repeating domain rules) is another sign.
No. Prefer boring code if the current shape is already clear and local. Only reach for a structure if it removes branches, eliminates duplicated rules, prevents invalid states, or reduces lifecycle risk.
State machines for lifecycle logic, typed objects for shape assumptions, maps/registries for branching, reducers for mutations, and queues/caches/graphs for specific data access patterns. Choose based on what the code must never allow and how data is read.
Loose parameters and repeated shape assumptions scatter domain knowledge. A structure encodes invariants and valid transitions explicitly, making invalid states unrepresentable and reducing the surface area for bugs.
Full instructions (SKILL.md)
Source of truth, from cursor/plugins.
name: principle-model-the-domain description: "Apply when writing stateful logic, or when code branches a lot or repeats a shape assumption across files. Encode the domain in a structure instead of scattered conditionals." disable-model-invocation: true
Model the Domain
Encode the real domain in a data structure instead of scattering it across conditionals.
Why: Scattered booleans, repeated shape assumptions, and branching spread across files are accidental complexity. A structure that matches the domain makes invalid states unrepresentable and deletes branches. Choosing it at write time is cheap. Recovering it later reads as a refactor and gets deferred.
Reach for structures like these:
- A state machine instead of scattered booleans, phases, or lifecycle checks.
- A typed object/model instead of loose parameters or repeated shape assumptions.
- A map, registry, lookup table, or discriminated union instead of branching spread across files.
- A reducer or command/event model instead of ad hoc state mutations.
- A module organized around one body of domain knowledge instead of a sequence such as load, validate, transform, and save. Execution order is not ownership.
- A small module boundary that gathers repeated behavior, ownership, or invariants.
- A queue, cache, index, graph/tree, or normalized collection where the data access pattern calls for it.
- Any other structure that fits. When none fits, work out what the code must never allow and how the data gets read, then find the structure that encodes exactly that.
Do not force an abstraction. Prefer boring code if the current shape is already clear, local, and unlikely to grow. Be skeptical of an abstraction that adds indirection without removing branches, duplicated rules, invalid states, or lifecycle risk.
The sign that you skipped this is a new feature that grows an existing if/else chain by one more branch, or a second boolean that must stay in sync with the first. Temporal decomposition is another sign. Phase-named modules repeat the same domain rules across steps.
Related skills
More from cursor/plugins and the wider catalog.
principle-never-block-on-the-human
Proceed with reversible work without asking permission; reserve confirmation for irreversible actions only.
principle-outcome-oriented-execution
Prioritize end-state correctness over intermediate stability during planned rewrites and migrations.
principle-prove-it-works
Verify task completion by checking real artifacts, not proxies or self-reports.
principle-redesign-from-first-principles
Redesign existing systems as if new requirements were foundational, not bolted-on.
principle-separate-before-serializing-shared-state
Eliminate concurrent write conflicts by separating mutable state before applying serialization.
principle-sequence-verifiable-units
Break multi-step work into small verifiable units, sequence commits to prove the logic to reviewers.