domain-modeling

Build and maintain project domain glossaries and architectural decision records.

Updated Jul 31, 2026
One-click install
npx skills add https://github.com/julianckt/adoptarun --skill domain-modeling-julianckt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/julianckt/adoptarun/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/julianckt/adoptarun --skill domain-modeling-julianckt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose alignment when domain terms drift, vocabulary stays fuzzy, and the reasoning behind architectural choices is never written down. This Skill actively sharpens a project's domain model during design sessions by challenging ambiguous 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 opinionated canonical terms and explicit "avoid" lists, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Architectural Decision Records: Creates lightweight ADRs in docs/adr/ with sequential numbering, but only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Active Model Sharpening: Challenges conflicting terminology, proposes precise terms for vague language, invents edge-case scenarios, and cross-references user statements against actual code behavior. - Use Case: While designing an ordering system, a user says "cancel the account." The Skill flags that the glossary defines cancellation for Orders, not Customers, 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 Ask the assistant to help define the domain terminology for your project and record any significant architectural decisions as ADRs.

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 each domain term with a one or two sentence definition and an "Avoid" list of rejected synonyms. Update it inline whenever a term is resolved during design discussions rather than batching changes.

When should I write an architectural 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?

Create a CONTEXT-MAP.md at the repo root listing each context, where its CONTEXT.md lives, and how contexts relate to each other. Each context keeps its own glossary and can maintain its own docs/adr directory for context-specific decisions.

What format should an ADR follow?

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md. The minimal format is a 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 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 should only include terms specific to the project's domain, not general programming concepts like timeouts or error types.