domain-modeling

Builds and maintains project glossaries and architecture decision records during design discussions.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology and forget why architectural decisions were made, leading to inconsistent language in code and repeated debates. This Skill actively sharpens a project's domain model by challenging fuzzy terms, resolving contradictions with code, and recording decisions the moment they crystallize. ## Core Features & Use Cases - Glossary Management: Creates and updates CONTEXT.md files with opinionated term definitions, including terms to avoid, supporting both single-context and multi-context repositories via CONTEXT-MAP.md. - Architecture Decision Records: Writes lightweight ADRs in docs/adr/ with sequential numbering, but only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Active Language Sharpening: Challenges vague or conflicting terminology during design sessions and cross-references stated behavior against actual code to surface contradictions. - Use Case: While designing a billing feature, a 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 assistant to help define the domain terminology for your project and record it in a CONTEXT.md glossary as you discuss the design.

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. Update it inline as terms are resolved during design discussions rather than batching changes.

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 record.

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

Create a CONTEXT-MAP.md at the repository root listing each context, its location, and its relationships, then place a separate CONTEXT.md inside each context directory. System-wide ADRs stay at the root while context-specific ones live beside each context.

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.

Should CONTEXT.md include implementation details?▼

No, CONTEXT.md is a glossary only and must be devoid of implementation details. It defines what domain terms mean, not how the system works, and should not be used as a spec or scratch pad.