Domain modeling

Skill helderberto/agent-skills/skills/domain-modeling

Actively build and sharpen a project's domain model — challenge terms, pin down a ubiquitous language, and write the glossary and decisions down as they crystallize. Use when the user wants to define domain terminology, resolve ambiguous terms, or when another skill needs the shared vocabulary. Don't use for recording a single architectural decision (use /create-adr) or explaining existing code (use /explain-code).From its SKILL.md

Install

npx -y skills add helderberto/agent-skills --skill domain-modeling

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

1.8 KB, 291 tokens by cl100k_base, as published. Nobody here has run it

Domain Modeling

The active discipline of shaping the model — challenging terms, inventing edge-case scenarios, and writing vocabulary down the moment it crystallizes. Merely reading a glossary for vocabulary is a one-line habit any skill does; this skill is for when you're changing the model, not consuming it.

Artifact

Maintain the project's glossary in its existing convention. If there is none, create CONTEXT.md at the repo root. Record decisions that settle a term via /create-adr so the why is preserved separately from the what.

Ubiquitous language

One term, one meaning, used everywhere — prose, code, docs, and the glossary agree. For each term write:

A crisp definition.
An Avoid list of the rejected synonyms, so the same concept never travels under two names.

When the same word means two things, that ambiguity is the work — split it into two named terms and retire the overloaded one.

Sharpen by stress

Invent edge-case scenarios that a term must survive. A definition that can't classify the edge case is still fuzzy — refine it until it can, then write it down immediately. Flag ambiguities you can't yet resolve; record the resolution once decided.

Completion: every term touched has a definition and an Avoid list, and every flagged ambiguity is either resolved or explicitly parked.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most docs writing skills give in 291 tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

Use third-person for skill descriptionsin 54 of 1951, across 35 files
Start descriptions with Use whenin 43 of 1951, across 29 files
Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
Use active voicein 40 of 1951, across 36 files
Map file responsibilities before defining tasksin 36 of 1951, across 29 files
Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
Ask one question at a timein 35 of 1951
Offer execution options after saving the planin 33 of 1951, across 24 files
Include complete code in every stepin 33 of 1951, across 27 files
Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
Announce the skill usage at the startin 30 of 1951
Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

Maintain project glossary
Create CONTEXT.md if none exists
Ensure one term has one meaning
Write crisp definitions for terms
List rejected synonyms for each term
Split ambiguous terms into distinct concepts

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.