domain-modeling

Build and maintain project glossaries and architecture decision records during design discussions.

Updated Jul 12, 2025
One-click install
npx skills add https://github.com/kpayakv2/check-products --skill domain-modeling-kpayakv2
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/kpayakv2/check-products/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/kpayakv2/check-products --skill domain-modeling-kpayakv2

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of domain terminology and the reasoning behind architectural decisions, leading to inconsistent language in code and repeated debates about settled choices. This Skill captures terms in a CONTEXT.md glossary and records trade-offs as ADRs the moment they crystallize. ## Core Features & Use Cases - Glossary Management: Creates and updates CONTEXT.md files with opinionated term definitions, including Avoid lists for rejected synonyms, supporting both single-context and multi-context repos via CONTEXT-MAP.md. - Architecture Decision Records: Writes numbered ADRs in docs/adr/ using a minimal template, offered only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Active Language Sharpening: Challenges vague or conflicting terminology during discussion, stress-tests domain relationships with concrete edge-case scenarios, and cross-references claims against the actual code. - Use Case: While designing an ordering system, a user says "account" ambiguously; the Skill asks whether they mean Customer or User, records the resolved term in CONTEXT.md, and drafts an ADR when the team picks event-sourced orders over a CRUD model. ## Quick Start Ask the assistant to help define the domain terms for your project and record them in a CONTEXT.md glossary.

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 CONTEXT.md glossary for my project?▼

Create a CONTEXT.md at the repo root listing domain terms with one or two sentence definitions, plus an _Avoid_ line for rejected synonyms. Only include terms specific to your domain, not general programming concepts, and update it inline as terms are resolved.

When should I write an architecture decision record?▼

Write an ADR only when 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.

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 have 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 template is a title plus one to three sentences covering context, decision, and rationale; optional sections like Status or Consequences are added only when they add genuine value.

What should not go into a domain glossary?▼

Exclude general programming concepts like timeouts, error types, and utility patterns, even if the project uses them heavily. CONTEXT.md is a glossary only, never a spec, scratch pad, or repository for implementation details.