domain-modelling

Build and maintain project domain glossaries and architecture decision records in Markdown.

3|Updated Jan 10, 2026
One-click install
npx skills add https://github.com/MaxWolf-01/agents --skill domain-modelling-maxwolf-01
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modelling
Source: https://github.com/MaxWolf-01/agents/tree/main/mx/skills/domain-modelling
Command: npx skills add https://github.com/MaxWolf-01/agents --skill domain-modelling-maxwolf-01

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of why decisions were made and use inconsistent terminology across a codebase, causing confusion and repeated debates. This Skill captures domain language in a CONTEXT.md glossary and records significant trade-offs as lightweight ADRs the moment they crystallize. ## Core Features & Use Cases - Glossary Management: Creates and updates CONTEXT.md files with opinionated term definitions, including avoided synonyms and multi-context maps via CONTEXT-MAP.md. - Architecture Decision Records: Writes numbered ADRs in a decisions/ directory, but only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Active Language Sharpening: Challenges vague or conflicting terminology during design discussions and cross-references claims against the actual code. - Use Case: While designing an ordering system, the user says "account" ambiguously; the Skill prompts them to distinguish Customer from User, records the resolved term in CONTEXT.md, and drafts an ADR when they choose event-sourced writes over a CRUD model. ## Quick Start Ask the agent to help define the domain terms for your project and record the key architectural decisions as ADRs.

Frequently Asked Questions about domain-modelling

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 each ambiguous or newly coined term with a one-to-two sentence definition and avoided synonyms. Only terms with non-obvious or competing meanings earn an entry; obvious terms stay out.

When should I write an architecture decision record?

Write an ADR only when all 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. Easy-to-reverse or obvious decisions should be skipped.

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 decisions/ directory. System-wide decisions stay in a root-level decisions/ folder.

What is the difference between a glossary entry and an ADR?

A glossary entry defines what a term means in one or two sentences and survives redesigns, while an ADR records why a specific mechanism or trade-off was chosen. Implementation details belong in the ADR or design doc, not the glossary.

Can this skill detect contradictions between code and documentation?

Yes. During design discussions it cross-references stated behavior against the actual code and surfaces contradictions, such as the code cancelling entire orders while the user claims partial cancellation is possible.