domain-modeling

Build and maintain project glossaries and architecture decision records during design discussions.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain language drifts as projects grow: terms get overloaded, decisions lose their rationale, and code diverges from how the team talks about the system. This Skill actively sharpens a project's domain model by challenging fuzzy terminology, cross-checking claims against code, and recording glossary entries and architecture decisions the moment they crystallize. ## Core Features & Use Cases - Glossary Management: Creates and updates CONTEXT.md files with precise canonical terms, flagging conflicts between how users speak and what the glossary defines. - Architecture Decision Records: Writes ADRs in docs/adr/ when decisions are hard to reverse, surprising without context, and the result of genuine trade-offs. - Multi-Context Support: Handles repositories with multiple bounded contexts via CONTEXT-MAP.md, keeping context-specific glossaries and ADRs in their own directories. - Use Case: While designing an order system, a user says "cancel the account." The Skill asks whether they mean the Customer or the User, checks whether the code supports partial cancellation, updates CONTEXT.md with the resolved term, and offers an ADR for the cancellation policy decision. ## Quick Start Ask the assistant to help define the domain terminology for your project and record it in a CONTEXT.md glossary as terms are resolved.

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 domain glossary for my codebase?▼

Create a CONTEXT.md file at the repository root and add terms as they are resolved during design discussions. Keep it strictly a glossary of canonical definitions with no implementation details, and update it inline whenever a term is clarified.

When should I write an architecture decision record?▼

Write an ADR only when three conditions hold: the decision is hard to reverse, it would surprise a future reader without context, and it resulted from a genuine trade-off between alternatives. If any condition is missing, skip the ADR.

How do I handle multiple bounded contexts in one repository?▼

Place a CONTEXT-MAP.md at the repository root pointing to each context's location. Each context then keeps its own CONTEXT.md glossary and a local docs/adr directory for context-specific decisions, while system-wide ADRs stay at the top level.

What is the difference between a CONTEXT.md glossary and a spec?▼

A CONTEXT.md is purely a glossary of canonical domain terms and their definitions. It must not contain implementation details, specifications, scratch notes, or design decisions; those belong in ADRs or other documentation.

What should I do when domain language conflicts with the code?▼

Surface the contradiction immediately rather than letting it persist. For example, if the code cancels entire orders but the discussion assumes partial cancellation, ask which behavior is correct and update the glossary or code accordingly.