domain-modeling

Builds and maintains project glossaries and architecture decision records during design sessions.

Updated Sep 17, 2026
One-click install
npx skills add https://github.com/coseto6125/claude-setup --skill domain-modeling-coseto6125
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/coseto6125/claude-setup/tree/main/skills/domain-modeling
Command: npx skills add https://github.com/coseto6125/claude-setup --skill domain-modeling-coseto6125

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terminology drifts and architectural decisions get forgotten, leaving future readers guessing why the code looks the way it does. This Skill actively sharpens a project's ubiquitous language and records hard-to-reverse decisions as they happen. ## Core Features & Use Cases - Glossary maintenance: Challenges conflicting or fuzzy terms in conversation and updates CONTEXT.md inline the moment a term is resolved, with explicit _Avoid_ lists for rejected synonyms. - Architecture Decision Records: Offers ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Code cross-referencing: Verifies stated domain behavior against the actual implementation using ecp structural queries and surfaces contradictions. - Use Case: While designing a billing feature, the user says "account" loosely; the Skill pins down whether they mean Customer or User, writes the definition into CONTEXT.md, and records an ADR for the event-sourced write model decision. ## Quick Start Ask the assistant to help pin down the domain terminology for your project and record the key architectural decisions as ADRs.

Frequently Asked Questions about domain-modeling

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

FAQPage Schema
How do I create a ubiquitous language glossary for my project?▼

Create a CONTEXT.md file at the repo root listing each domain term with a one or two sentence definition and an _Avoid_ list of rejected synonyms. Update it inline whenever a term is resolved during design discussions rather than batching changes.

When should I write an architecture decision record?▼

Write an ADR only when three conditions hold: the decision is hard to reverse, it is surprising without context, and it resulted from a real trade-off between genuine alternatives. If any condition is missing, skip the ADR.

How do I handle multiple bounded contexts in one repository?▼

Place a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships, then give each context its own CONTEXT.md and docs/adr directory. Single-context repos just use one root CONTEXT.md.

What belongs in a domain glossary versus implementation docs?▼

Only terms specific to the project's domain belong in CONTEXT.md; general programming concepts like timeouts or error types do not. The glossary defines what terms mean, never how they are implemented.

Can the glossary contradict what the code actually does?▼

Yes, and that contradiction should be surfaced immediately. The Skill cross-references stated behavior against the implementation using structural code queries and asks the user which version is correct.