domain-modeling

Builds and maintains project domain glossaries and architectural decision records.

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

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, updated inline as terms are resolved. - 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. - Multi-Context Support: Detects CONTEXT-MAP.md for multi-context repositories and routes terms and decisions to the correct bounded context. - Use Case: While designing an ordering system, the user says "account" ambiguously; the Skill challenges the term, resolves it to Customer versus User, updates CONTEXT.md immediately, and offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Ask the assistant to use the domain-modeling skill to define the term "cancellation" in CONTEXT.md and record why we chose event sourcing 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 a ubiquitous language glossary for my project?▼

Create a CONTEXT.md file at the repository 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.

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 genuine trade-off between alternatives. If any condition is missing, skip the ADR.

How do I handle domain modeling across multiple bounded contexts?▼

Place a CONTEXT-MAP.md at the repository root listing each context, its location, and its relationships. Each context then keeps its own CONTEXT.md glossary and context-specific docs/adr directory for local decisions.

What belongs in CONTEXT.md versus an ADR?▼

CONTEXT.md is purely a glossary of domain terms with tight definitions, free of implementation details. ADRs capture why specific decisions were made, such as technology lock-ins, integration patterns, or deliberate deviations from obvious approaches.

What is the format for numbering ADR files?▼

ADRs live in docs/adr/ with sequential numbered filenames like 0001-slug.md and 0002-slug.md. Scan the directory for the highest existing number and increment by one when adding a new record.