domain-modeling

Build and maintain project domain glossaries and architecture decision records.

Updated Jul 22, 2026
One-click install
npx skills add https://github.com/Chau165/local_skill --skill domain-modeling-chau165
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/Chau165/local_skill/tree/main/codex/skills/domain-modeling
Command: npx skills add https://github.com/Chau165/local_skill --skill domain-modeling-chau165

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology and forget why key architectural decisions were made, leading to inconsistent language in code and repeated re-litigation of settled choices. This Skill actively sharpens a project's domain model during design discussions and records outcomes in CONTEXT.md glossaries and ADR files. ## Core Features & Use Cases - Ubiquitous Language Management: Challenges conflicting or fuzzy terms in conversation and updates CONTEXT.md inline with canonical definitions and terms to avoid. - 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/. - Multi-Context Support: Handles single-context repos with one CONTEXT.md or multi-context repos via a CONTEXT-MAP.md linking per-context glossaries and decision logs. - Use Case: While designing an ordering system, the user says "account" ambiguously; the Skill asks whether they mean Customer or User, records the resolved term in CONTEXT.md, and drafts an ADR when the team picks event-sourced orders over a CRUD model. ## Quick Start Ask the assistant to help define the domain terms for your project and record them in a CONTEXT.md glossary as you discuss the design.

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 at the repo root listing canonical terms with one-to-two sentence definitions and an _Avoid_ line for rejected synonyms. Update it inline as terms are resolved during design discussions rather than batching changes.

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 genuine trade-off between alternatives. If any of the three conditions is missing, skip the record to avoid noise.

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, then give each context its own CONTEXT.md and docs/adr directory. System-wide decisions stay in the root docs/adr folder.

What belongs in a CONTEXT.md glossary?

Only terms specific to the project's domain belong in CONTEXT.md, defined in one or two sentences. General programming concepts like timeouts or error types are excluded, and implementation details never appear in the glossary.

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

CONTEXT.md is a glossary defining domain vocabulary and nothing else, while an ADR records a specific architectural decision and its rationale. Glossaries capture what terms mean; ADRs capture why choices were made.