domain-modeling

Build and maintain a project domain glossary and architectural decision records.

2|Updated Jul 11, 2026
One-click install
npx skills add https://github.com/MoofonLi/dev-ready --skill domain-modeling-moofonli
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/MoofonLi/dev-ready/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/MoofonLi/dev-ready --skill domain-modeling-moofonli

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose alignment when domain terms drift, vocabulary stays fuzzy, and the reasoning behind architectural choices is forgotten. This Skill keeps a project's domain model sharp by capturing terminology in a CONTEXT.md glossary and recording significant decisions as ADRs the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Challenges conflicting terms, sharpens vague vocabulary, and updates CONTEXT.md inline as terms are resolved, with support for single-context and multi-context repos via CONTEXT-MAP.md. - Architectural Decision Records: Offers ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off, using a minimal sequential-numbered format. - Scenario Stress-Testing: Invents concrete edge-case scenarios and cross-references claims against the actual code to surface contradictions between the stated model and the implementation. - Use Case: While designing an ordering system, the user says "account" loosely; the Skill asks whether they mean Customer or User, records the resolved term in CONTEXT.md, and offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Ask the agent to use the domain-modeling skill to define the term "Order" in CONTEXT.md and record why the team chose Postgres for the write model as an ADR.

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 ubiquitous language glossary for my project?

Create a CONTEXT.md file at the repo root listing each domain term with a one-or-two-sentence definition and an _Avoid_ line for rejected synonyms. Add terms inline as they are resolved during design discussions, keeping the file free of implementation details.

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, then give each context its own CONTEXT.md and docs/adr directory. System-wide decisions stay in the root docs/adr folder.

What format should an ADR follow?

Use sequential numbering like 0001-slug.md in docs/adr/, with 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 CONTEXT.md glossary?

CONTEXT.md is a glossary only and must not contain implementation details, specs, or scratch notes. It covers project-specific domain terms, not general programming concepts like timeouts or error types.