domain-modeling

Maintain domain glossaries and architectural decision records during design sessions.

2|Updated May 14, 2026
One-click install
npx skills add https://github.com/AnthonyPoschen/agent-skills --skill domain-modeling-anthonyposchen
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/AnthonyPoschen/agent-skills/tree/main/skills/domain-modeling
Command: npx skills add https://github.com/AnthonyPoschen/agent-skills --skill domain-modeling-anthonyposchen

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of domain terminology and the reasoning behind architectural decisions, leading to inconsistent language, repeated debates, and future engineers undoing deliberate choices. This Skill keeps a living glossary and decision log that crystallise as you design. ## Core Features & Use Cases - Ubiquitous Language Management: Challenge fuzzy or conflicting terms in real time and record canonical definitions in CONTEXT.md, with avoided synonyms listed explicitly. - Lightweight ADRs: Record hard-to-reverse, surprising, trade-off-driven decisions as short numbered ADRs under docs/adr/ without heavyweight templates. - Multi-Context Support: Handle single-context repos with one CONTEXT.md or multi-context repos via a CONTEXT-MAP.md linking per-context glossaries and ADRs. - Use Case: While designing a billing feature, the user says "account" ambiguously; the Skill asks whether they mean Customer or User, updates CONTEXT.md with the resolved term, and offers an ADR when the team picks event-based communication between Ordering and Billing. ## Quick Start Ask the agent to sharpen the domain language for your current 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 document domain terminology in a software project?▼

Create a CONTEXT.md glossary at the repo root defining each domain term in one or two sentences, with avoided synonyms listed under each entry. Update it inline whenever a term is resolved during design discussions rather than batching changes.

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 keeps its own CONTEXT.md glossary and docs/adr/ directory for local decisions.

What format should an ADR follow?▼

Use sequential numbered files like 0001-slug.md under docs/adr/ containing a short title and one to three sentences covering context, decision, and rationale. Optional sections for status, considered options, and consequences are added only when they add genuine value.

What are the limitations of a glossary-only approach to domain modeling?▼

CONTEXT.md is strictly a glossary and must not contain implementation details, specs, or scratch notes. Teams needing full design documentation should keep that elsewhere and reserve the glossary purely for canonical terminology.