domain-modeling

Builds and maintains project domain glossaries and architectural decision records in Markdown.

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

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 ubiquitous language and records hard-to-reverse decisions as they happen. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains an opinionated CONTEXT.md glossary with canonical terms and explicitly avoided synonyms, supporting both single-context and multi-context repos 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, proposes precise terms for vague language, stress-tests domain relationships with edge-case scenarios, and cross-references claims against the actual code. - Use Case: While designing a billing feature, the 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 picks event-based communication between Ordering and Billing. ## Quick Start Ask the assistant to use the domain-modeling skill to define the term "Order" in CONTEXT.md and record why the write model uses 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 repo root listing canonical domain terms with one-to-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 architectural decision record?▼

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

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

Place a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships, then give each context its own CONTEXT.md and docs/adr/ directory. System-wide decisions stay in the root docs/adr/ folder.

What format should an ADR use?▼

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md and contain a short title plus one to three sentences covering context, decision, and rationale. Optional sections for 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 a glossary only and must not contain implementation details, specs, or scratch notes. It should only include terms specific to the project's domain, not general programming concepts like timeouts or error types.