domain-modeling

Build and maintain a project domain model with CONTEXT.md glossaries and ADRs.

1|Updated Jul 4, 2026
One-click install
npx skills add https://github.com/trungenglish/SHOPWISE --skill domain-modeling-trungenglish
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/trungenglish/SHOPWISE/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/trungenglish/SHOPWISE --skill domain-modeling-trungenglish

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terminology drifts and architectural decisions get forgotten as a project grows, leaving future readers guessing why the code looks the way it does. This Skill actively sharpens a project's domain model by challenging vague terms, stress-testing concepts with concrete scenarios, and recording glossary entries and architectural decisions the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains an opinionated CONTEXT.md glossary that picks canonical terms and lists words to avoid, with support for multi-context repos via CONTEXT-MAP.md. - Architectural Decision Records: Creates lightweight, sequentially numbered ADRs in docs/adr/, but only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Active Model Sharpening: Challenges conflicting terminology, proposes precise terms for fuzzy language, invents edge-case scenarios, and cross-references user statements against the actual code. - Use Case: While designing an ordering system, a user says "cancel the account." The Skill flags that the glossary defines Customer and User separately, asks which is meant, updates CONTEXT.md with the resolved term, and offers an ADR when the team decides partial cancellation is supported. ## Quick Start Ask the assistant to help define the domain terminology for your project and record any significant 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 domain terms with one or two sentence definitions. Pick one canonical term per concept and list rejected synonyms under an Avoid line, keeping the file free of implementation details.

When should I write an architectural decision record?▼

Write an ADR only when a decision is hard to reverse, surprising without context, and the result of a genuine trade-off between alternatives. Skip ADRs for easily reversed or obvious decisions, since they add noise without value.

What format should an ADR use?▼

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md. A title plus one to three sentences covering context, decision, and rationale is enough; optional sections like Status or Considered Options are added only when they add real value.

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

Create a CONTEXT-MAP.md at the repo root listing each context, where its CONTEXT.md lives, and how contexts relate to each other. Each context keeps its own glossary and can have its own docs/adr directory for context-specific decisions.

What should not go into a domain glossary?▼

General programming concepts like timeouts, error types, or utility patterns do not belong in CONTEXT.md, even if the project uses them heavily. Only include terms specific to the project's domain, and never use the glossary as a spec or scratch pad.