domain-modeling

Create and maintain domain glossaries and architectural decision records in Markdown.

Updated Dec 17, 2025
One-click install
npx skills add https://github.com/Frantss/oxform --skill domain-modeling-frantss
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/Frantss/oxform/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/Frantss/oxform --skill domain-modeling-frantss

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill addresses the ambiguity and drift that occur when technical implementation diverges from the core business concepts, ensuring the codebase remains a true reflection of the domain.

Core Features & Use Cases

  • Glossary Management: Maintains a canonical CONTEXT.md file to define project-specific terminology and eliminate overloaded terms.
  • Architectural Decision Records (ADRs): Provides a structured, lightweight framework for documenting high-stakes design trade-offs.
  • Use Case: When a team is debating whether to use the term "Client" or "Customer" across a new billing module, this skill forces a decision, updates the glossary, and records the rationale to prevent future confusion.

Quick Start

Use the domain-modeling skill to define the term Customer in our context and record an architectural decision regarding our choice of database.

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 glossary for domain-driven design?

You maintain a ubiquitous language glossary by managing a canonical CONTEXT.md file that defines project-specific terminology to eliminate overloaded terms and prevent domain drift. This ensures consistent terminology across the codebase.

What is the best way to document architectural decision records for system boundaries?

Documenting architectural decision records requires a structured framework utilizing specific Markdown formatting standards and sequential ADR numbering to record the rationale for high-stakes design trade-offs and critical system boundaries.

How do I resolve terminology debates like choosing between Client or Customer in a billing module?

Resolve terminology debates by forcing a decision, updating the glossary, and recording the rationale to prevent future confusion. This ensures consistent terminology like defining Customer within your specific project context.

Do I need specific Markdown formatting standards for domain modeling documentation?

Yes, you need specific Markdown formatting standards for context definitions and sequential ADR numbering. Adhering to these formatting standards ensures your ubiquitous language glossary and architectural decision records remain structured and consistent.

When should I use domain-driven design documentation to prevent codebase drift?

Use domain-driven design documentation when technical implementation diverges from core business concepts. It ensures the codebase remains a true reflection of the domain by enforcing consistent terminology and documented rationale.