principle-model-the-domain

Encodes domain logic in data structures instead of scattered conditionals across codebases.

3|2|Updated Aug 28, 2026
One-click install
npx skills add https://github.com/adjohn/pstack --skill principle-model-the-domain-adjohn
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-model-the-domain
Source: https://github.com/adjohn/pstack/tree/main/skills/principle-model-the-domain
Command: npx skills add https://github.com/adjohn/pstack --skill principle-model-the-domain-adjohn

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Stateful code often accumulates scattered booleans, repeated shape assumptions, and branching spread across files, creating accidental complexity and invalid states. This Skill guides you to encode the domain in a proper structure at write time, making invalid states unrepresentable and deleting unnecessary branches. ## Core Features & Use Cases - Structure Selection Guidance: Recommends state machines, typed models, lookup tables, discriminated unions, reducers, and other structures matched to your domain problem. - Anti-Pattern Detection: Identifies tells like growing if/else chains, booleans that must stay in sync, and temporal decomposition across phase-named modules. - Restraint Against Over-Abstraction: Advises preferring boring code when the current shape is already clear, local, and unlikely to grow. - Use Case: When adding a feature that would extend an existing conditional chain or introduce a second lifecycle boolean, apply this Skill to replace the branching with a state machine or discriminated union. ## Quick Start Apply the model-the-domain principle to refactor this module's scattered conditionals into a structure that encodes the domain rules.

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 conditionals with a state machine?▼

Identify the lifecycle checks and booleans spread across your code, then define explicit states and transitions in one structure. This makes invalid states unrepresentable and deletes the branches that previously enforced the rules manually.

When should I use a discriminated union instead of if/else chains?▼

Use a discriminated union when branching on a type or kind field repeats across files. It centralizes the shape assumptions so the compiler enforces exhaustive handling instead of relying on scattered conditionals.

What are the signs that code needs domain modeling?▼

Common tells include a new feature growing an existing if/else chain by one branch, a second boolean that must stay in sync with the first, and phase-named modules that repeat the same domain rules across steps.

When should I avoid adding a domain abstraction?▼

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

How do I choose the right data structure for my domain?▼

Work out what the code must never allow and how the data gets read, then find the structure that encodes exactly that. Common options include state machines, registries, reducers, queues, caches, and normalized collections.