domain-modeling

Build and maintain project domain glossaries and architectural decision records.

Updated Jan 19, 2023
One-click install
npx skills add https://github.com/inkfin/dotfiles --skill domain-modeling-inkfin
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/inkfin/dotfiles/tree/main/dot_agents/skills/exact_domain-modeling
Command: npx skills add https://github.com/inkfin/dotfiles --skill domain-modeling-inkfin

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 domain model during design sessions by challenging fuzzy terms, stress-testing concepts with concrete scenarios, and recording glossary entries and ADRs the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary with canonical terms and explicit _Avoid_ lists, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Active Term Challenging: Detects when your wording conflicts with the existing glossary or with the actual code, and surfaces the contradiction immediately. - Disciplined ADR Writing: Offers Architecture Decision Records in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Use Case: While designing an ordering system, you say "cancel the account" — the Skill asks whether you mean the Customer or the User, resolves the term, updates CONTEXT.md inline, and records an ADR for the event-sourced write model decision. ## Quick Start Ask the AI to help pin down the domain terminology for your project and record any significant 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 ubiquitous language glossary for my project?▼

Create a CONTEXT.md file at the repo root listing canonical domain terms with one-or-two-sentence definitions and an _Avoid_ list of rejected synonyms. Update it inline whenever a term is resolved during design discussions.

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 real trade-off between genuine alternatives. If any of the three conditions is missing, skip the ADR to avoid documentation noise.

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

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 belongs in a domain glossary versus a spec?▼

A glossary contains only context-specific domain terms with tight definitions, never implementation details, general programming concepts, or design rationale. Implementation decisions belong in ADRs, not in CONTEXT.md.

What format should an ADR follow?▼

An ADR is a sequentially numbered Markdown file in docs/adr/ containing a short title and one to three sentences covering context, decision, and rationale. Optional sections like Status, Considered Options, and Consequences are added only when they add genuine value.