domain-modeling

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

2|Updated Oct 16, 2021
One-click install
npx skills add https://github.com/pattobrien/dotfiles --skill domain-modeling-pattobrien
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/pattobrien/dotfiles/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/pattobrien/dotfiles --skill domain-modeling-pattobrien

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terminology drifts and design decisions get forgotten as a codebase grows, leaving future readers guessing why things were built a certain way. This Skill actively sharpens a project's domain model by challenging fuzzy terms, stress-testing concepts with concrete scenarios, and recording glossaries and decisions the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains an opinionated CONTEXT.md glossary with canonical terms and explicit _Avoid_ synonyms, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Architecture Decision Records: Creates sequentially 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 terms that conflict with the glossary, cross-references claims against actual code, and updates files inline rather than batching changes. - Use Case: While designing a billing feature, the user says "account" ambiguously; the Skill asks whether they mean Customer or User, resolves the term, updates CONTEXT.md immediately, and offers an ADR when the team picks event-based communication between Ordering and Billing contexts. ## Quick Start Ask the AI to help define the domain language for a new feature 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 domain glossary for my codebase?▼

Create a CONTEXT.md file at the repo root listing canonical terms with one or two sentence definitions and an _Avoid_ line for rejected synonyms. The Skill updates this file inline as terms are 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 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?▼

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 follow?▼

ADRs use sequential numbering like 0001-slug.md in docs/adr/ and can be as short as a title plus one paragraph covering context, decision, and rationale. Optional sections like Status, Considered Options, and Consequences are added only when they add genuine value.

What belongs in a CONTEXT.md glossary?▼

Only terms specific to the project's domain belong in CONTEXT.md, defined in one or two sentences describing what the concept is. General programming concepts like timeouts or error types are excluded, and implementation details never appear in the glossary.