domain-modeling

Build and maintain project domain glossaries and architecture decision records.

1|Updated Aug 24, 2026
One-click install
npx skills add https://github.com/yamcodes/the-hat --skill domain-modeling-yamcodes
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/yamcodes/the-hat/tree/main/skills/domain-modeling
Command: npx skills add https://github.com/yamcodes/the-hat --skill domain-modeling-yamcodes

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology and the reasoning behind architectural decisions, causing inconsistent language in code and repeated re-litigation of settled trade-offs. ## Core Features & Use Cases - Glossary Management: Create and update CONTEXT.md files with canonical domain terms, tight definitions, and explicitly avoided synonyms, supporting both single-context and multi-context repositories via CONTEXT-MAP.md. - Language Sharpening: Challenge vague or conflicting terminology during design discussions, stress-test domain relationships with concrete edge-case scenarios, and cross-reference stated behavior against actual code. - Decision Recording: Write lightweight ADRs in docs/adr/ with sequential numbering, offered only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Use Case: While designing an ordering system, a user says "account" ambiguously; the skill prompts them to distinguish Customer from User, updates CONTEXT.md with the resolved term, and records an ADR when they decide Ordering and Billing communicate via domain events rather than synchronous HTTP. ## Quick Start Ask the assistant to help define the domain terms for your project and record the architectural decisions made during the design discussion.

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 domain glossary for my codebase?▼

Create a CONTEXT.md file at the repository root listing canonical domain terms with one or two sentence definitions and avoided synonyms. Terms are added inline as they are resolved during design discussions, not batched.

When should I write an architecture decision record?▼

Write an ADR only when a decision is hard to reverse, surprising without context, and the result of a real trade-off between genuine alternatives. If any condition is missing, skip the record to avoid documentation noise.

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

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

What belongs in a CONTEXT.md glossary file?▼

Only terms specific to the project's domain belong in CONTEXT.md, defined in one or two sentences with avoided alternatives listed. General programming concepts and implementation details are explicitly excluded.

What is the difference between a CONTEXT.md and an ADR?▼

CONTEXT.md is a pure glossary of domain language with no implementation details, while an ADR records a specific hard-to-reverse decision and its rationale. ADRs live in docs/adr with sequential numbering.