domain-modeling

Build and maintain project glossaries and architecture decision records during design discussions.

4|Updated May 26, 2026
One-click install
npx skills add https://github.com/YYG501/PM-AI-Harness --skill domain-modeling-yyg501
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/YYG501/PM-AI-Harness/tree/main/vendor/mattpocock-skills/skills/engineering/domain-modeling
Command: npx skills add https://github.com/YYG501/PM-AI-Harness --skill domain-modeling-yyg501

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology and forget why key architectural decisions were made, leading to inconsistent language in code and repeated re-litigation of settled trade-offs. ## Core Features & Use Cases - Glossary Management: Creates and updates a CONTEXT.md file with opinionated, tightly-defined domain terms, flagging conflicts when your usage drifts from the established language. - Architecture Decision Records: Writes lightweight ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Multi-Context Support: Handles repos with multiple bounded contexts via a CONTEXT-MAP.md that maps contexts and their relationships. - Use Case: While designing an ordering system, you say "account" loosely; the skill challenges whether you mean Customer or User, updates CONTEXT.md with the resolved term, and offers an ADR when you decide Ordering and Billing communicate via domain events instead of synchronous HTTP. ## Quick Start Ask the assistant to help sharpen the domain language for your project and record the key architectural decisions as ADRs while 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 at the repo root listing each domain term with a one or two sentence definition and an _Avoid_ line for rejected synonyms. Add terms lazily as they are resolved during design discussions, and keep the file free of implementation details.

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. Skip ADRs for easily reversed or obvious choices.

What format should an ADR use?

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md. The minimal format is a title plus one to three sentences covering context, decision, and rationale; optional sections for status, considered options, and consequences are added only when they add real value.

How do I handle multiple bounded contexts in one repository?

Create a CONTEXT-MAP.md at the repo root listing each context, where its CONTEXT.md lives, and how contexts relate to each other, such as event flows or shared types. Each context then maintains its own glossary and context-specific ADRs.

What belongs in a CONTEXT.md glossary and what does not?

Only terms specific to the project's domain belong in CONTEXT.md, defined in one or two sentences with rejected alternatives listed under _Avoid_. General programming concepts, implementation details, and spec-like content should be excluded.