domain-modeling

Build and maintain project domain glossaries and architecture decision records.

Updated Apr 28, 2026
One-click install
npx skills add https://github.com/GregM1991/skills --skill domain-modeling-gregm1991
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/GregM1991/skills/tree/main/skills/vendor/mattpocock/domain-modeling
Command: npx skills add https://github.com/GregM1991/skills --skill domain-modeling-gregm1991

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of domain terminology and the reasoning behind architectural decisions, leading to inconsistent language in code and repeated debates about settled choices. This Skill actively sharpens a project's domain model by maintaining a CONTEXT.md glossary and recording Architecture Decision Records (ADRs) as decisions crystallize. ## Core Features & Use Cases - Glossary Management: Creates and updates CONTEXT.md files with canonical domain terms, tight definitions, and explicitly avoided synonyms, supporting both single-context and multi-context repos via CONTEXT-MAP.md. - Terminology Challenges: Detects when language conflicts with the existing glossary, sharpens vague terms, and cross-references stated behavior against actual code. - Selective ADR Recording: Offers numbered ADRs in docs/adr/ 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 asks whether they mean Customer or User, records the resolved term in CONTEXT.md, and drafts an ADR when the team chooses event-sourced writes over synchronous updates. ## Quick Start Ask the assistant to help define the domain terms for your project and record them in a CONTEXT.md glossary.

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 CONTEXT.md glossary for my project?▼

Create a CONTEXT.md at the repo root listing domain terms with one-to-two sentence definitions and avoided synonyms under each entry. Terms are added lazily as they are resolved during design discussions, and the file stays free of implementation details.

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 these three conditions is missing, skip the record to avoid documentation 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, with a separate CONTEXT.md inside each context directory. System-wide ADRs live in the root docs/adr folder while context-specific decisions stay local.

What belongs in a domain glossary versus a spec document?▼

A glossary contains only canonical term definitions and avoided synonyms, never implementation details, specs, or scratch notes. Only terms specific to the project's domain belong; general programming concepts like timeouts or error types are excluded.

What format should an ADR follow?▼

An ADR uses sequential numbering like 0001-slug.md in docs/adr/ and contains a short title plus one to three sentences covering context, decision, and rationale. Optional sections for status, considered options, and consequences are added only when they add genuine value.