principle-model-the-domain

Guides encoding domain logic into data structures instead of scattered conditionals.

136|8|Updated May 9, 2026
One-click install
npx skills add https://github.com/Sma1lboy/rove --skill principle-model-the-domain-sma1lboy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-model-the-domain
Source: https://github.com/Sma1lboy/rove/tree/main/.agents/skills/pstack/skills/principle-model-the-domain
Command: npx skills add https://github.com/Sma1lboy/rove --skill principle-model-the-domain-sma1lboy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate accidental complexity when domain rules are scattered across booleans, if/else chains, and repeated shape assumptions in multiple files. This Skill helps you recognize that pattern at write time and replace it with a structure that makes invalid states unrepresentable. ## Core Features & Use Cases - Structure Selection Guidance: Recommends concrete structures such as state machines, typed models, registries, discriminated unions, reducers, and queues matched to the code's actual access patterns. - Tell Detection: Identifies warning signs like growing if/else chains, booleans that must stay in sync, and phase-named modules that repeat domain rules across steps. - Restraint Discipline: Advises against forcing abstractions when the current shape is already clear, local, and unlikely to grow. - Use Case: When adding a third lifecycle phase to a feature guarded by two booleans, apply this Skill to replace the flags with a state machine so invalid transitions become unrepresentable. ## Quick Start Ask the AI to review the stateful logic in your current file and model the domain as an explicit structure instead of scattered conditionals.

Frequently Asked Questions about principle-model-the-domain

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I replace scattered booleans with a state machine?▼

Identify the lifecycle phases the booleans represent, then define explicit states and legal transitions in one structure. This makes invalid combinations unrepresentable and deletes the branches that kept the booleans in sync.

When should I model the domain instead of adding another conditional?▼

Model the domain when a feature grows an existing if/else chain by one more branch, when a second boolean must stay in sync with the first, or when the same shape assumption repeats across files. These are tells that the domain is encoded implicitly.

What data structures reduce branching in code?▼

State machines replace lifecycle booleans, registries and lookup tables replace branching spread across files, discriminated unions replace repeated shape checks, and reducers replace ad hoc state mutations. Choose based on what the code must never allow and how data is read.

When should I avoid adding a domain abstraction?▼

Avoid it when the current shape is already clear, local, and unlikely to grow. Be skeptical of any abstraction that adds indirection without removing branches, duplicated rules, invalid states, or lifecycle risk.

Why is organizing modules by execution order a problem?▼

Phase-named modules like load, validate, transform, and save repeat the same domain rules across steps, scattering one body of knowledge. Organizing a module around the domain itself keeps ownership and invariants in one place.