principle-model-the-domain

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

4|1|Updated Dec 16, 2023
One-click install
npx skills add https://github.com/Shtian/AuthentiClash --skill principle-model-the-domain-shtian
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-model-the-domain
Source: https://github.com/Shtian/AuthentiClash/tree/main/.claude/skills/principle-model-the-domain
Command: npx skills add https://github.com/Shtian/AuthentiClash --skill principle-model-the-domain-shtian

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 that makes invalid states possible and refactors expensive. ## Core Features & Use Cases - Structure Selection Guidance: Recommends state machines, typed models, registries, discriminated unions, reducers, and other structures matched to the domain. - Anti-Pattern Detection: Identifies warning signs like growing if/else chains, booleans that must stay in sync, and phase-named modules repeating domain rules. - Restraint Criteria: Advises against forcing abstractions when the current shape is already clear, local, and unlikely to grow. - Use Case: When adding a feature that extends an existing conditional chain, apply this principle to replace the branches with a lookup table or state machine before writing new code. ## Quick Start Ask the AI to apply the model-the-domain principle when reviewing or writing stateful logic that branches heavily across files.

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 enforced them manually.

When should I model the domain instead of using simple conditionals?▼

Apply domain modeling when code branches a lot, repeats shape assumptions across files, or when a new feature grows an existing if/else chain. Prefer boring code if the current shape is already clear, local, and unlikely to grow.

What data structures reduce branching in code?▼

State machines replace scattered booleans, maps and registries replace branching across files, discriminated unions replace shape checks, and reducers replace ad hoc state mutations. Choose the structure that matches how the data gets read.

What are the signs of poor domain modeling in code?▼

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

When should I avoid adding abstractions to code?▼

Avoid abstractions that add indirection without removing branches, duplicated rules, invalid states, or lifecycle risk. If the current shape is clear, local, and unlikely to grow, simpler code is the better choice.