domain-modeling

Build and maintain a project domain model with CONTEXT.md glossaries and ADR records.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terminology drifts and architectural decisions get forgotten as projects grow, leaving future readers guessing why the code looks the way it does. This Skill actively sharpens a project's domain model by challenging fuzzy terms, stress-testing concepts with concrete scenarios, and recording decisions the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary of canonical domain terms with explicit _Avoid_ lists, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Architecture Decision Records: Creates lightweight, sequentially numbered ADRs in docs/adr/, but only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Live Model Sharpening: Challenges conflicting terminology, proposes precise canonical terms, invents edge-case scenarios, and cross-references user statements against the actual code to surface contradictions. - Use Case: While designing an ordering system, the user says "cancel the account" — the Skill flags that the glossary defines Customer and User as distinct concepts, resolves the term inline, updates CONTEXT.md, and offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Ask the agent to help define the domain language for your project and record any significant architectural decisions as ADRs while you 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 ubiquitous language glossary for my project?▼

Create a CONTEXT.md file at the repo root listing canonical domain terms with one-or-two-sentence definitions and an _Avoid_ list of rejected synonyms. Update it inline whenever a term is resolved during design discussions rather than batching changes.

When should I write an architecture decision record?▼

Write an ADR only when all three conditions hold: the decision is hard to reverse, it would surprise a future reader without context, and it resulted from a genuine trade-off between alternatives. Easy-to-reverse or obvious decisions should be skipped.

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

Place 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 use?▼

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md and contain a short title plus 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 strictly a glossary of domain terms and must stay free of implementation details, specs, and scratch notes. Only concepts unique to the project's domain belong there, not general programming terms.