domain-modeling

Build and maintain project domain glossaries and architecture decision records.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/kashman001/ai-workspace-template --skill domain-modeling-kashman001
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/kashman001/ai-workspace-template/tree/main/skills/domain-modeling
Command: npx skills add https://github.com/kashman001/ai-workspace-template --skill domain-modeling-kashman001

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology and the reasoning behind architectural decisions, leading to inconsistent language in code and repeated debates about settled choices. This Skill actively sharpens a project's domain model during design discussions and records it in CONTEXT.md glossaries and ADR files. ## Core Features & Use Cases - Glossary Management: Creates and updates CONTEXT.md files with canonical terms, tight definitions, and explicitly avoided synonyms, supporting both single-context and multi-context repos via CONTEXT-MAP.md. - Terminology Challenges: Detects when usage conflicts with the existing glossary, sharpens vague terms, and cross-references stated behavior against actual code. - Architecture Decision Records: Offers ADRs only when decisions are hard to reverse, surprising without context, and the result of real trade-offs, using a minimal numbered format in docs/adr/. - Use Case: While designing an ordering system, a user says "account" loosely; the Skill asks whether they mean Customer or User, updates CONTEXT.md with the resolved term, and offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Ask the assistant to use the domain-modeling skill to review the terminology in your design discussion and record the resolved terms in CONTEXT.md.

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 CONTEXT.md glossary for my project?▼

Create a CONTEXT.md at the repo root listing canonical domain terms with one or two sentence definitions and avoided synonyms under each term. The file is created lazily when the first term is resolved, and it should contain only glossary entries, never implementation details.

When should I write an architecture 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 entirely.

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

Create a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships, with a separate CONTEXT.md inside each context directory. System-wide ADRs live in the root docs/adr/ while context-specific decisions live in each context's own docs/adr/.

What belongs in a domain glossary versus a spec?▼

A CONTEXT.md 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 there; decisions belong in ADRs instead.

What ADR format does this approach use?▼

ADRs use sequential numbered files like 0001-slug.md in docs/adr/, containing a short title and one to three sentences covering context, decision, and rationale. Optional sections for status, considered options, and consequences are added only when they add genuine value.