agentleFS
Sign inStart free
jtarorehjtaroreh/agystack/skills/principle-model-the-domain/SKILL.md

principle-model-the-domain

Skill128 starsChanged 2 days agoMITView on GitHub

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.

We split this skill into the rules it gives an agent

1 rule. 1 is common, 0 are distinctive, and 0 are very specific to this project.

  • 1

    Common

    Most of the 37 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Do not force an abstraction.

    line 24

“Common” is measured: kept by at least 6 in 10 of the 37 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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. The list above covers the common cases only. 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 tell 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 tell. Phase-named modules repeat the same domain rules across steps.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free