domain-modeling

Build and maintain a project domain model with glossaries and architecture decision records.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of domain terminology and the reasoning behind architectural choices, leading to inconsistent language in code and repeated debates about settled decisions. This Skill actively builds and sharpens a project's domain model by maintaining a ubiquitous-language glossary (CONTEXT.md) and recording architecture decision records (ADRs) as decisions crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Challenges conflicting or fuzzy terms during design discussions and updates CONTEXT.md inline with precise canonical definitions and terms to avoid. - Architecture Decision Records: Offers ADRs sparingly — only when a decision is hard to reverse, surprising without context, and the result of a real trade-off — using a lightweight numbered format in docs/adr/. - Multi-Context Support: Handles both single-context repos (one root CONTEXT.md) and multi-context repos via a CONTEXT-MAP.md that maps bounded contexts and their relationships. - Use Case: While designing an ordering system, the user says "account" ambiguously; the Skill asks whether they mean Customer or User, resolves the term, updates CONTEXT.md immediately, and later offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Ask the assistant to help pin down the domain terminology for your project and record the key architectural decisions as ADRs.

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 each domain term with a one-or-two-sentence definition and an _Avoid_ list of rejected synonyms. Update it inline whenever a term is resolved during design discussions, and keep it free of 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 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, where its CONTEXT.md lives, and how contexts relate to each other. Each context keeps its own glossary and context-specific ADRs, while system-wide decisions stay in the root docs/adr/ directory.

What is the difference between a glossary and an ADR?

A glossary (CONTEXT.md) defines domain terms and canonical vocabulary with avoided synonyms, while an ADR records a specific architectural decision and why it was made. The glossary captures language; ADRs capture decisions.

When should I not use domain modeling documentation?

Skip it for easily reversible 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.