domain-modeling

Build and maintain project domain glossaries and architecture decision records.

Updated Sep 21, 2026
One-click install
npx skills add https://github.com/maxentr/la-cuisine-de-mm --skill domain-modeling-maxentr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/maxentr/la-cuisine-de-mm/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/maxentr/la-cuisine-de-mm --skill domain-modeling-maxentr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology and the reasoning behind architectural decisions, leading to inconsistent language in code and repeated debates over settled choices. ## Core Features & Use Cases - Glossary Management: Create and update CONTEXT.md files that define canonical domain terms, flag avoided synonyms, and support multi-context repos via CONTEXT-MAP.md. - Architecture Decision Records: Write lightweight ADRs in docs/adr/ with sequential numbering, offered only when decisions are hard to reverse, surprising, and involve real trade-offs. - Language Sharpening: Challenge vague or conflicting terminology during design discussions and cross-reference stated behavior against actual code. - Use Case: While designing an ordering system, a user says "account" ambiguously; the skill proposes precise terms like Customer vs User, records them in CONTEXT.md, and drafts an ADR when the team picks event-sourced writes over a CRUD model. ## 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 domain glossary for my codebase?

Create a CONTEXT.md file at the repo root listing canonical domain terms with one or two sentence definitions and avoided synonyms. 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 real trade-off between genuine alternatives. Easy-to-reverse or obvious decisions should be skipped to avoid noise.

How do I handle multiple bounded contexts in one repository?

Create 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 folder.

What format should an ADR follow?

ADRs use sequential numbered files like 0001-slug.md 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 a glossary only and must not contain implementation details, specs, or scratch notes. It covers only terms specific to the project's domain, excluding general programming concepts like timeouts or error types.