skills.rest
gmackie
gmackieCOMMUNITY
Explore all skills by this author →
Website𝕏@grahammackieGitHub

domain-modeling

Build and maintain project domain glossaries and architectural decision records.

Updated Mar 27, 2026
Search Tags:#architecture#documentation#domain modeling#adr#glossary#bounded context#ubiquitous language
One-click install
npx skills add https://github.com/gmackie/agent-skills --skill domain-modeling-gmackie
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/gmackie/agent-skills/tree/main/skills/domain-modeling
Command: npx skills add https://github.com/gmackie/agent-skills --skill domain-modeling-gmackie

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology and forget why architectural decisions were made, leading to inconsistent language in code and repeated debates over settled trade-offs. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary that pins down canonical domain terms, flags conflicting usage, and lists words to avoid. - Architectural Decision Records: Creates lightweight ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Multi-Context Support: Handles repos with multiple bounded contexts via a CONTEXT-MAP.md that lists contexts and their relationships. - Use Case: While designing a billing feature, the user says "account" ambiguously; the skill challenges the term, resolves it to Customer versus User, updates CONTEXT.md inline, and offers an ADR when the team picks event-based communication between Ordering and Billing. ## Quick Start Ask the agent 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 canonical domain terms with one or two sentence definitions and words to avoid. Update it inline whenever a term is resolved during design discussions rather than batching changes.

When should I write an architectural 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. Skip ADRs for easily reversed or obvious choices.

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 other contexts. Each context then keeps its own CONTEXT.md glossary and context-specific docs/adr directory.

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 is strictly a glossary and must stay free of implementation details, specs, and scratch notes. It only covers terms specific to the project's domain, not general programming concepts like timeouts or error types.

Related Skills

Explore More Software Engineering Skills→
ishandutta2007ishandutta2007
13

Skill: Grill with Docs

Stress-test plans against CONTEXT.md terminology and ADR decisions.

Community
Intermediate
rohitg00rohitg00
2.8k

domain-modeling

Build a shared-language glossary and bounded contexts before writing code.

Community
Intermediate
529-studio529-studio
2

business-auditor

Validate frontend implementations against business rules and Vietnamese terminology.

Official
Advanced
taiyousan15taiyousan15

sdd-event-storming

Guide Event Storming workshops and generate Markdown domain reports.

Community
Advanced