domain-modeling

Maintains project glossaries in CONTEXT.md and records architectural decisions as ADRs.

Updated May 22, 2026
One-click install
npx skills add https://github.com/kitfunso/claude-config --skill domain-modeling-kitfunso
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/kitfunso/claude-config/tree/main/skills/domain-modeling
Command: npx skills add https://github.com/kitfunso/claude-config --skill domain-modeling-kitfunso

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases drift into inconsistent terminology and undocumented decisions, leaving future readers guessing why things were built a certain way. This Skill actively sharpens a project's domain model during design discussions by resolving ambiguous terms, keeping a canonical glossary, and recording hard-to-reverse decisions. ## Core Features & Use Cases - Glossary Management: Builds and updates CONTEXT.md with opinionated term definitions, canonical names, and Avoid lists for rejected synonyms, supporting both single-context and multi-context repos via CONTEXT-MAP.md. - Terminology Challenges: Detects when code and conversation use two names for one concept, cites both locations, and resolves them into a single canonical term. - Selective ADR Recording: Offers Architecture Decision Records only when a decision is hard to reverse, surprising without context, and the result of a real trade-off, using a minimal numbered format in docs/adr/. - Use Case: While discussing a new reporting endpoint, the Skill notices the code calls a concept "Sleeve" in one module and "bucket" in another, surfaces the collision with file references, and updates CONTEXT.md with the resolved term inline. ## Quick Start Ask the assistant to use the domain-modeling skill to review the terminology in your codebase discussion and update CONTEXT.md with any resolved terms.

Frequently Asked Questions about domain-modeling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I keep domain terminology consistent across a codebase?▼

Maintain a CONTEXT.md glossary at the repo root that defines each domain term in one or two sentences and lists rejected synonyms under _Avoid_. Update it inline whenever a term is resolved during design discussions rather than batching changes.

When should I write an architecture decision record?▼

Write an ADR only when all three tests pass: the decision is hard to reverse, surprising without context, and the result of a genuine trade-off between real alternatives. Simple renames or obvious choices do not warrant an ADR.

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 through events or shared types. Each context keeps its own glossary and context-specific ADRs.

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

Only domain terms specific to the project's context, each with a tight one-or-two-sentence definition and an _Avoid_ list of synonyms. Implementation details, specs, architecture notes, and general programming concepts do not belong in it.

What format should an ADR follow?▼

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md. The minimal template is a short 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.