principle-model-the-domain

Encodes domain rules in data structures instead of scattered conditionals across code.

1|Updated Jul 5, 2026
One-click install
npx skills add https://github.com/yersonargotev/packy --skill principle-model-the-domain-yersonargotev
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-model-the-domain
Source: https://github.com/yersonargotev/packy/tree/main/bundle/skills/principle-model-the-domain
Command: npx skills add https://github.com/yersonargotev/packy --skill principle-model-the-domain-yersonargotev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Stateful logic often degrades into scattered booleans, growing if/else chains, and repeated shape assumptions spread across files, making invalid states possible and refactors expensive. This Skill guides you to encode the domain directly in a structure so invalid states become unrepresentable. ## Core Features & Use Cases - Structure Selection Guidance: Recommends state machines, typed models, lookup tables, discriminated unions, reducers, and domain-organized modules matched to the problem shape. - Anti-Pattern Detection: Identifies tells like growing if/else chains, booleans that must stay in sync, and phase-named modules that repeat domain rules. - Restraint Check: Advises against forcing abstractions when the current code is already clear, local, and unlikely to grow. - Use Case: When adding a new lifecycle phase to a feature, apply this Skill to replace scattered status booleans with a state machine that makes illegal transitions impossible. ## Quick Start Ask the AI to apply the model-the-domain principle to refactor a module with branching state logic into an explicit domain structure.

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 allowed transitions in one structure. This makes invalid combinations unrepresentable and deletes the conditional checks spread across files.

When should I model the domain instead of adding another if/else branch?▼

Model the domain when a new feature grows an existing if/else chain, when two booleans must stay in sync, or when the same shape assumption repeats across files. These tells signal accidental complexity that a structure would eliminate.

What structures work for domain modeling in code?▼

Common options include state machines for lifecycles, typed models for repeated shapes, lookup tables or discriminated unions for branching, reducers for state mutations, and modules organized around one body of domain knowledge.

When should I avoid adding a domain abstraction?▼

Avoid it when the current code 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. Execution order is not ownership; a module organized around one body of domain knowledge keeps rules in one place.