domain-modeling

Builds and maintains project glossaries and architecture decision records during design discussions.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of domain terminology and the reasoning behind architectural choices, leading to inconsistent language in code and repeated debates about settled decisions. This Skill actively sharpens a project's domain model by challenging fuzzy terms, cross-checking claims against code, and recording glossaries and decisions as they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary with canonical terms and explicitly avoided synonyms, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Architecture 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. - Active Model Sharpening: Challenges conflicting terminology, invents edge-case scenarios to stress-test domain relationships, and flags contradictions between stated behavior and actual code. - Use Case: While designing an ordering system, a user says "account" ambiguously; the Skill asks whether they mean Customer or User, updates CONTEXT.md with the resolved term, and offers an ADR when the team decides Ordering and Billing will communicate via domain events instead of synchronous HTTP. ## Quick Start Ask the assistant to help define the domain terminology for your project and record the key 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 domain glossary for my codebase?

Create a CONTEXT.md file at the repo root listing canonical terms with one or two sentence definitions and avoided synonyms. Update it inline whenever a term is resolved during design discussions, keeping it free of implementation details.

When should I write an architecture decision record?

Write an ADR only when a decision is hard to reverse, surprising without context, and the result of a genuine trade-off between alternatives. If any of these three conditions is missing, skip the ADR to avoid documentation noise.

How do I handle multiple bounded contexts in one repository?

Create a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships, with a separate CONTEXT.md inside each context directory. System-wide ADRs live at the root while context-specific ADRs live in each context's docs/adr folder.

What format should an ADR follow?

An ADR needs only a short title and one to three sentences covering context, decision, and rationale, stored as a sequentially numbered file like 0001-slug.md in docs/adr. Optional sections like Status, Considered Options, and Consequences are added only when they add genuine value.

What are the limitations of a CONTEXT.md glossary?

CONTEXT.md is strictly a glossary and must not contain implementation details, specs, or scratch notes. It should only include terms specific to the project's domain, excluding general programming concepts like timeouts or error types.