domain-modeling

Build and maintain project domain glossaries and architectural decision records.

Updated May 9, 2024
One-click install
npx skills add https://github.com/AceCodePt/dotfiles --skill domain-modeling-acecodept
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/AceCodePt/dotfiles/tree/main/.config/opencode/skills/domain-modeling
Command: npx skills add https://github.com/AceCodePt/dotfiles --skill domain-modeling-acecodept

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 builds a ubiquitous language glossary (CONTEXT.md) and records architectural decisions (ADRs) as they crystallize during design discussions. ## Core Features & Use Cases - Ubiquitous Language Management: Challenges conflicting terms, sharpens vague language, and updates CONTEXT.md inline with opinionated term definitions and avoided synonyms. - Architectural Decision Records: Offers ADRs only when decisions are hard to reverse, surprising without context, and the result of real trade-offs, using a minimal numbered format in docs/adr/. - Multi-Context Support: Handles single-context repos with one CONTEXT.md or multi-context repos via a CONTEXT-MAP.md linking per-context glossaries and decisions. - Use Case: While designing a billing feature, the 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-based communication between Ordering and Billing contexts. ## Quick Start Ask the assistant to help define the domain terms for your project and record the architectural decisions made during the design discussion.

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 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 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 other contexts. Each context then gets its own CONTEXT.md glossary and context-specific docs/adr/ directory.

What format should an ADR follow?▼

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md. The minimal format is a title plus one to three sentences covering context, decision, and rationale; optional sections like Status or Considered Options 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.