domain-modeling

Build and maintain project domain glossaries and architecture decision records.

1|Updated Mar 2, 2025
One-click install
npx skills add https://github.com/marjorg/setup --skill domain-modeling-marjorg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/marjorg/setup/tree/main/home/.agents/skills/archive/0-matt/domain-modeling
Command: npx skills add https://github.com/marjorg/setup --skill domain-modeling-marjorg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of domain terminology and the reasoning behind architectural decisions, leading to inconsistent language in code and repeated debates about settled choices. This Skill actively sharpens a project's domain model by maintaining a CONTEXT.md glossary and recording ADRs when significant trade-offs are made. ## Core Features & Use Cases - Glossary Management: Creates and updates CONTEXT.md files with canonical domain terms, tight definitions, and explicitly avoided synonyms, supporting both single-context and multi-context repos via CONTEXT-MAP.md. - Language Sharpening: Challenges vague or conflicting terminology during design discussions and cross-references stated behavior against actual code to surface contradictions. - ADR Recording: Writes lightweight, sequentially numbered ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Use Case: While designing a billing feature, the assistant notices you say "account" ambiguously, resolves it to "Customer" in CONTEXT.md, and records an ADR explaining why Billing communicates with Ordering via domain events instead of synchronous HTTP. ## 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 genuine trade-off between alternatives. If any of these three conditions is missing, skip the ADR since there is nothing worth recording.

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?

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md and contain a short title plus 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 terms belong in a CONTEXT.md glossary?

Only include terms specific to the project's domain, defined in one or two sentences describing what the concept is. General programming concepts like timeouts or error types do not belong, even if the project uses them extensively.