domain-modeling

Maintains a CONTEXT.md ubiquitous-language glossary and ADRs under docs/adr/ as domain decisions settle.

Updated May 5, 2026
One-click install
npx skills add https://github.com/josippapez/ai-setup --skill domain-modeling-josippapez
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/josippapez/ai-setup/tree/main/claude/plugins/orchestrate/skills/domain-modeling
Command: npx skills add https://github.com/josippapez/ai-setup --skill domain-modeling-josippapez

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terminology drifts and architectural decisions get forgotten, leaving future readers guessing why the code looks the way it does. This Skill captures the project's ubiquitous language in CONTEXT.md and records hard-to-reverse decisions as ADRs the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Glossary: Builds and sharpens CONTEXT.md with opinionated term definitions, listing rejected synonyms under Avoid so the team speaks one language. - Architecture Decision Records: Writes minimal 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. - Multi-Context Support: Detects CONTEXT-MAP.md for repos with multiple bounded contexts and routes terms and decisions to the right context. - Use Case: While designing an ordering system, the user says "account" ambiguously; the Skill challenges the term, resolves it to Customer, updates CONTEXT.md inline, and offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Ask the assistant to pin down the terminology for the current feature and record the decision we just made as an ADR.

Frequently Asked Questions about domain-modeling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create an architecture decision record for my project?

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md. Each ADR is a short markdown file stating the context, the decision, and why — often a single paragraph, with optional Status, Considered Options, and Consequences sections only when they add value.

How do I build a ubiquitous language glossary for a codebase?

Create a CONTEXT.md at the repo root defining each domain term in one or two sentences, with rejected synonyms listed under _Avoid_. Update it inline the moment a term is resolved rather than batching changes, and keep it free of implementation details.

When should I write an ADR versus skipping it?

Write an ADR only when all three hold: the decision is hard to reverse, surprising without context, and the result of a real trade-off. Skip it for easily reversed choices, obvious decisions, or cases with no genuine alternatives.

Does the glossary format support multiple bounded contexts?

Yes. A CONTEXT-MAP.md at the repo root lists each context, its location, and relationships between contexts, while each context keeps its own CONTEXT.md and context-specific docs/adr/ directory. Single-context repos just use one root CONTEXT.md.

What are the limitations of a CONTEXT.md glossary?

CONTEXT.md is a glossary only — it must not contain implementation details, specs, or scratch notes. It covers terms unique to the project's domain, not general programming concepts like timeouts or error types.