domain-modeling

Build and maintain project domain glossaries and architectural decision records.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology and forget why architectural decisions were made, leading to inconsistent language in code and repeated re-litigation of settled trade-offs. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary that pins down canonical domain terms, flags conflicting usage, and lists words to avoid. - Architectural Decision Records: Creates lightweight ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Multi-Context Support: Handles both single-context repos (one root CONTEXT.md) and multi-context repos via a CONTEXT-MAP.md linking per-context glossaries and ADRs. - Use Case: While designing a billing feature, the user says "account" ambiguously; the skill challenges the term, resolves it to "Customer", updates CONTEXT.md inline, and offers an ADR when the team picks event-based communication between Ordering and Billing. ## Quick Start Ask the assistant to use the domain-modeling skill to sharpen the domain language and record architectural decisions for your project.

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 canonical domain terms with one or two sentence definitions and words to avoid. Update it inline whenever a term is resolved during design discussions, keeping it free of implementation details.

When should I write an architectural decision record?▼

Write an ADR only when all 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 domain modeling across multiple bounded contexts?▼

Place a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships with other contexts. Each context keeps its own CONTEXT.md glossary and context-specific docs/adr directory for local decisions.

What belongs in a domain glossary versus a spec document?▼

A glossary contains only terms specific to the project's domain with tight definitions of what each term is. General programming concepts, implementation details, and design decisions do not belong in CONTEXT.md.

What is the format for a lightweight ADR?▼

An ADR is a sequentially numbered Markdown file in docs/adr containing a short title and one to three sentences covering context, decision, and rationale. Optional sections like Status, Considered Options, and Consequences are added only when they add genuine value.