domain-modeling

Build and maintain project glossaries and architectural decision records during design sessions.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/Avistian/nba --skill domain-modeling-avistian
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/Avistian/nba/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/Avistian/nba --skill domain-modeling-avistian

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 actively sharpens a project's domain model by challenging fuzzy terms, stress-testing concepts with concrete scenarios, and recording decisions the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains an opinionated CONTEXT.md glossary with canonical terms and explicit _Avoid_ lists, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Architectural Decision Records: Creates numbered ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Live Model Sharpening: Challenges conflicting terminology, invents edge-case scenarios to probe domain boundaries, and cross-references user statements against the actual code. - Use Case: While designing a billing feature, the user says "account" — the Skill asks whether they mean Customer or User, resolves the term, 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 help pin down 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 canonical domain terms with one-or-two-sentence definitions and an _Avoid_ list of rejected synonyms. Update it inline whenever a term is resolved during design discussions, keeping it free of implementation details.

When should I write an architectural decision record?▼

Write an ADR only when all three conditions hold: the decision is hard to reverse, it is surprising without context, and it resulted from a real trade-off between genuine alternatives. If any condition is missing, skip the ADR to avoid documentation noise.

How do I handle multiple bounded contexts in one repository?▼

Place 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 have its own docs/adr directory for context-specific decisions.

What format should an ADR follow?▼

An ADR is a sequentially numbered Markdown file 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 markdown-based domain glossary?▼

A Markdown glossary has no automated enforcement, so consistency depends on disciplined inline updates during design sessions. It also cannot validate that code actually uses the canonical terms, which requires manual cross-referencing against the codebase.