domain-modeling

Create and maintain domain models via glossary definitions and architectural decision records.

Updated Apr 8, 2026

Search Tags:#architecture #documentation #adr #domain-driven design #glossary #ubiquitous language

Ready to run

npx skills add https://github.com/tonomb/personal-pnl --skill domain-modeling-tonomb

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/tonomb/personal-pnl/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/tonomb/personal-pnl --skill domain-modeling-tonomb

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This skill addresses the ambiguity and drift that occur when technical implementation diverges from business intent, ensuring your codebase accurately reflects the domain.

Core Features & Use Cases

Glossary Management: Maintains a canonical CONTEXT.md to define project-specific terminology and eliminate overloaded language.
Architectural Decision Records: Provides a structured, lightweight framework for recording high-stakes design decisions and their trade-offs.
Use Case: When a team is debating whether a specific entity should be called a Customer or a User, this skill facilitates the resolution of the term and updates the project glossary to prevent future confusion.

Quick Start

Use the domain-modeling skill to define the term Invoice in our billing context and record the decision to use a specific database schema.

Frequently Asked Questions about domain-modeling

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

FAQPage Schema

How do I maintain a ubiquitous language when our team debates whether to call an entity a Customer or a User?▼

You record architectural decisions using a structured, lightweight ADR framework that documents high-stakes design choices and their trade-offs. This ensures consistency across the codebase during software design phases when technical trade-offs require formal documentation.

What is the best way to document domain-driven design terminology to prevent implementation divergence?▼

You can use this skill for domain-driven design in any software design phase where ubiquitous language and technical trade-offs require formal documentation. It requires adherence to provided ADR and CONTEXT file formats to ensure consistency across your codebase.

How do I record high-stakes architectural decisions and their technical trade-offs?▼

When do I need formal documentation for domain modeling and ubiquitous language?▼

This skill provides a structured, lightweight ADR framework for recording architectural decisions and maintains a canonical CONTEXT.md glossary. It differs from generic documentation by specifically targeting domain-driven design terminology and technical trade-off tracking.