model-domain-language

Resolve conflicting domain terms into one canonical glossary shared across client, design, and code.

1|Updated Jul 13, 2026
One-click install
npx skills add https://github.com/dineshrevunuru/SuperSkills --skill model-domain-language-dineshrevunuru
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: model-domain-language
Source: https://github.com/dineshrevunuru/SuperSkills/tree/main/model-domain-language
Command: npx skills add https://github.com/dineshrevunuru/SuperSkills --skill model-domain-language-dineshrevunuru

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terms drift silently across a project: the client says "appointment," the code says "session," and the UI says "booking" — three names for one concept, or one name smeared across three concepts. This Skill catches overloaded or conflicting terminology, resolves each concept to a single canonical name, and captures the result in a GLOSSARY.md so every surface (client conversations, design system, codebase) uses the same word for the same thing. ## Core Features & Use Cases - Challenge and sharpen terms: Call out words that conflict with the existing glossary and propose one precise canonical term with retired synonyms listed under "Avoid." - Scenario-test boundaries: Invent edge cases (e.g., "a customer buys a 5-pack and books 2 dates — how many rows exist?") to force precision where two concepts touch. - Cross-surface reconciliation: Check each resolved name against what the client says, what the UI shows, and what the code names, then fix contradictions on all three. - Use Case: A salon booking app uses "booking" for both a prepaid package and a calendar slot. The Skill disambiguates them into Package, Booking, and Session, updates the UI copy and table names, and writes the resolution to GLOSSARY.md before any further code is written. ## Quick Start Ask the AI to build a glossary that resolves the conflicting domain terms in this project, reconciling how the client, the UI, and the code each name the same concepts.

Frequently Asked Questions about model-domain-language

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a domain glossary for a software project?

Scan the client's language, UI copy, and code for conflicting terms, resolve each concept to one canonical name, and write it to a GLOSSARY.md at the repo root. Define what each term is in one or two sentences and list retired synonyms under Avoid.

What is ubiquitous language in domain modeling?

Ubiquitous language is the practice of using one shared name per concept across conversations, design, and code. This Skill applies it to solo and freelance work by reconciling terms across three surfaces: what the client says, what the UI shows, and what the code names.

When should I split one term into two separate concepts?

Split a term only when the distinction changes what gets built or said — for example, Package versus Booking because they behave differently in the system. If splitting changes nothing, the distinction is noise and should be avoided.

Should I use the code's naming or the client's wording for domain terms?

Prefer the word the client says out loud, since the domain expert's language should win over the schema's existing names. The code and UI are then updated to match the resolved canonical term.

What is the difference between a domain glossary and design token naming?

A domain glossary names business concepts like Booking or Customer, while token naming covers visual values like --text-secondary. This Skill owns domain nouns only; token values belong to a separate token-system skill.