domain-modeling

Build and maintain project glossaries and architecture decision records during design discussions.

Updated Aug 21, 2026
One-click install
npx skills add https://github.com/dohcivil-ui/naichangmoo.com --skill domain-modeling-dohcivil-ui
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/dohcivil-ui/naichangmoo.com/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/dohcivil-ui/naichangmoo.com --skill domain-modeling-dohcivil-ui

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terminology drifts and key architectural decisions go unrecorded, leaving future readers guessing why the code looks the way it does. This Skill actively sharpens a project's domain model by challenging vague terms, resolving contradictions with the code, and writing down glossaries and decisions the moment they crystallize. ## Core Features & Use Cases - Glossary Management: Create and update CONTEXT.md files with opinionated, tightly-defined domain terms, including explicit "avoid" lists for ambiguous synonyms. - Architecture Decision Records: Write lightweight ADRs in docs/adr/ with sequential numbering, but only when a decision is hard to reverse, surprising, and the result of a real trade-off. - Multi-Context Support: Handle repos with multiple bounded contexts via a CONTEXT-MAP.md that lists contexts and their relationships. - Use Case: While designing an ordering system, the user says "account" loosely; the Skill asks whether they mean Customer or User, records the resolved term in CONTEXT.md, and offers an ADR when the team decides Ordering and Billing will communicate via domain events instead of synchronous HTTP. ## Quick Start Help me sharpen the domain language for our billing module and record the decision to use event-driven communication between contexts as an ADR.

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 each domain term with a one or two sentence definition and an _Avoid_ list of rejected synonyms. Keep it free of implementation details; it is a glossary only, not a spec or scratch pad.

When should I write an architecture decision record?

Write an ADR only when all three conditions hold: the decision is hard to reverse, it would surprise a future reader without context, and it resulted from a genuine trade-off between alternatives. Easy-to-reverse or obvious decisions should be skipped.

How do I handle multiple bounded contexts in one repository?

Create a CONTEXT-MAP.md at the repo root listing each context, where its CONTEXT.md lives, and how contexts relate to each other, such as event flows or shared types. Each context keeps its own glossary and context-specific ADRs.

What format should an ADR follow?

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.

What are the limitations of a CONTEXT.md glossary?

CONTEXT.md only covers terms specific to the project's domain, not general programming concepts like timeouts or error types. It must stay free of implementation details and is not a specification, so it cannot replace design docs or API documentation.