domain-modeling

Build and maintain a project domain glossary and living decision records.

6|2|Updated May 6, 2026
One-click install
npx skills add https://github.com/sek788432/Stock-Back-Test-System --skill domain-modeling-sek788432
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/sek788432/Stock-Back-Test-System/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/sek788432/Stock-Back-Test-System --skill domain-modeling-sek788432

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose alignment when domain terms are vague, overloaded, or contradict the code, and when architectural decisions are made without recorded rationale. This Skill actively sharpens a project's domain model by challenging fuzzy terminology, stress-testing concepts with concrete scenarios, and capturing glossary terms and important decisions the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary with opinionated term definitions and explicit _Avoid_ lists, updated inline as terms are resolved. - Terminology Challenge & Scenario Probing: Flags conflicts between user language and the glossary, sharpens vague terms, and invents edge-case scenarios to force precision about concept boundaries. - Living Decision Records: Adds or updates entries in a single living important-decisions document only when a choice is hard to reverse, surprising without context, and involves a real trade-off. - Use Case: While designing an order system, a user says "cancel the account" — the Skill asks whether they mean the Customer or the User, records the resolved term in CONTEXT.md, and offers a decision entry when the team commits to a hard-to-reverse cancellation policy. ## Quick Start Ask the agent to help define the domain terminology for a new feature and record any important architectural decisions in the repository's living decisions document.

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 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 record an architectural decision entry?▼

Record a decision entry only when all three tests pass: the choice is hard to reverse, its rationale is surprising without context, and a real trade-off existed with meaningful rejected alternatives. Otherwise explain in the PR why no entry is needed.

What is the difference between CONTEXT.md and a specification document?▼

CONTEXT.md is purely a glossary of domain terms and contains no implementation details, behavior rules, or design rationale. Specifications and decision rationale live in their owning documents; CONTEXT.md only defines what each term means.

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

Use a CONTEXT-MAP.md at the repository root listing each context, its file location, and its relationships to other contexts. Each context then has its own CONTEXT.md, and the Skill infers which context a discussion belongs to.

When should a decision entry be removed from the decisions document?▼

Remove an entry when it no longer constrains the project, and update entries in place when the current decision changes rather than appending superseded records. Git history preserves the chronology of obsolete decisions.