domain-modeling

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

Updated Sep 5, 2023
One-click install
npx skills add https://github.com/eyenalxai/dotfiles --skill domain-modeling-eyenalxai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/eyenalxai/dotfiles/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/eyenalxai/dotfiles --skill domain-modeling-eyenalxai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terminology drifts and architectural decisions get forgotten as projects grow, leaving future readers guessing why the code looks the way it does. This Skill actively sharpens a project's domain model by challenging fuzzy terms, stress-testing concepts with concrete scenarios, and recording decisions the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary with canonical terms and explicit _Avoid_ alternatives, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Architecture Decision Records: Creates lightweight, sequentially numbered ADRs in docs/adr/, but only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Active Model Sharpening: Challenges terms that conflict with the glossary, proposes precise names for vague language, and cross-references user statements against the actual code to surface contradictions. - Use Case: While designing an ordering system, a user says "cancel the account." The Skill flags that the glossary defines Customer and User separately, asks which is meant, updates CONTEXT.md with the resolved term, and offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Help me pin down the domain terminology for my ordering system and record the architectural decisions we make along the way.

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 an _Avoid_ line for rejected synonyms. Update it inline whenever a term is resolved during design discussions rather than batching changes.

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 genuine trade-off between alternatives. If any condition is missing, skip the ADR to avoid 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, then give each context its own CONTEXT.md and docs/adr directory. System-wide decisions stay in the root docs/adr folder.

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.