domain-modeling

Build and maintain project domain glossaries and architectural decision records in Markdown.

Updated May 11, 2026
One-click install
npx skills add https://github.com/cloudofgeorge/AI-hands-Engineer --skill domain-modeling-cloudofgeorge
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/cloudofgeorge/AI-hands-Engineer/tree/main/skills/engineering/domain-modeling
Command: npx skills add https://github.com/cloudofgeorge/AI-hands-Engineer --skill domain-modeling-cloudofgeorge

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 domain model during design sessions by challenging fuzzy terms, stress-testing concepts with concrete scenarios, and recording glossary entries and decisions the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary with canonical terms, tight definitions, and explicitly avoided synonyms, supporting both single-context and multi-context repos via CONTEXT-MAP.md. - Architectural Decision Records: Creates numbered ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Live Model Sharpening: Challenges conflicting terminology, proposes precise canonical terms, invents edge-case scenarios, and cross-references user statements against actual code behavior. - Use Case: While designing a billing feature, the user says "cancel the account." The Skill flags that the glossary defines cancellation at the Order level, forces a precise resolution, updates CONTEXT.md inline, and offers an ADR recording why partial cancellation is supported. ## Quick Start Help me pin down the domain terminology for our ordering system and record any architectural decisions we make along the way.

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-to-two sentence definitions and avoided synonyms. 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 genuine trade-off between 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. Each context then keeps its own CONTEXT.md glossary and context-specific docs/adr/ directory for local decisions.

What is the difference between a glossary and an ADR?

A glossary (CONTEXT.md) defines what domain terms mean and which synonyms to avoid, while an ADR records why a specific hard-to-reverse decision was made. Glossaries contain no implementation details; ADRs capture trade-offs and rejected alternatives.

When should I not use domain modeling documentation?

Skip it for easily reversed decisions, obvious choices with no real alternatives, and general programming concepts like timeouts or error types. Documenting these adds noise without helping future readers understand the domain.