domain-modeling

Build and maintain project domain glossaries and architectural decision records.

1|Updated Oct 29, 2025
One-click install
npx skills add https://github.com/jwh3times/holland-vip --skill domain-modeling-jwh3times
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/jwh3times/holland-vip/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/jwh3times/holland-vip --skill domain-modeling-jwh3times

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 both single-context repos (one 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 challenges the term, resolves it to Customer versus User, updates CONTEXT.md inline, and 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 any significant 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 a decision is hard to reverse, surprising without context, and the result of a real trade-off between genuine alternatives. If any of the three conditions is missing, skip the ADR to avoid documentation noise.

How do I handle domain modeling across multiple bounded contexts?▼

Use a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships, with a separate CONTEXT.md per context. System-wide ADRs live in the root docs/adr/ while context-specific decisions live in each context's own docs/adr/.

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 not contain implementation details, specs, or scratch notes. It only covers terms specific to the project's domain, excluding general programming concepts like timeouts or error types.