domain-modeling

Build and maintain project domain glossaries and architecture decision records.

1|Updated Sep 13, 2026
One-click install
npx skills add https://github.com/silentFellow/public-dotfiles --skill domain-modeling-silentfellow
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/silentFellow/public-dotfiles/tree/main/agents/skills/domain-modeling
Command: npx skills add https://github.com/silentFellow/public-dotfiles --skill domain-modeling-silentfellow

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of domain terminology and the reasoning behind architectural decisions, leading to inconsistent language in code and repeated debates about settled choices. This Skill actively sharpens a project's domain model by maintaining a CONTEXT.md glossary and recording Architecture Decision Records (ADRs) as decisions crystallize. ## Core Features & Use Cases - Glossary Management: Creates and updates CONTEXT.md files with opinionated, tightly-defined domain terms, including terms to avoid, supporting both single-context and multi-context repositories via CONTEXT-MAP.md. - Terminology Challenges: Detects when language conflicts with the existing glossary or when vague terms are used, and proposes precise canonical terms. - ADR Recording: Offers to write lightweight ADRs 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, a user says "account" ambiguously; the Skill asks whether they mean Customer or User, updates CONTEXT.md with the resolved term, and records an ADR when the team decides Ordering and Billing communicate via domain events instead of synchronous HTTP. ## Quick Start Ask the assistant to help define the domain terms for your project and record the key architectural decisions in CONTEXT.md and docs/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 domain glossary for my codebase?▼

Create a CONTEXT.md file at the repository root listing each domain term with a one or two sentence definition and terms to avoid. The glossary is created lazily when the first term is resolved and updated inline as new terms crystallize.

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 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, where its CONTEXT.md lives, and how contexts relate to each other. Each context keeps its own glossary and can have its own docs/adr/ directory for context-specific decisions.

What format should an ADR follow?▼

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 like Status, Considered Options, and Consequences are added only when they add genuine value.

What should not go into a CONTEXT.md glossary?▼

Exclude general programming concepts like timeouts or error types, implementation details, and spec-like content. CONTEXT.md is purely a glossary of terms unique to the project's domain, with opinionated definitions and avoided synonyms.