domain-modeling

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

Updated Aug 19, 2026
One-click install
npx skills add https://github.com/PVMalove/claude-agent-harness --skill domain-modeling-pvmalove
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/PVMalove/claude-agent-harness/tree/main/skills/vendor/mattpocock/engineering/domain-modeling
Command: npx skills add https://github.com/PVMalove/claude-agent-harness --skill domain-modeling-pvmalove

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 the project's ubiquitous language and records hard-to-reverse decisions the moment they crystallize. ## Core Features & Use Cases - Glossary Management: Maintains an opinionated CONTEXT.md of canonical domain terms with explicit _Avoid_ synonyms, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Language Sharpening: Challenges conflicting or vague terms during design discussions, stress-tests domain relationships with concrete edge-case scenarios, and cross-references claims against the actual code. - Architecture 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. - Use Case: While designing a billing feature, the user says "account" ambiguously; the Skill asks whether they mean Customer or User, updates CONTEXT.md with the resolved term, and offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Ask the agent to help pin down the domain terminology for your feature and record any significant architectural decisions as ADRs.

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 at the repo root listing canonical domain terms with one-or-two-sentence definitions and an _Avoid_ line for 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. Skip ADRs for easily reversed or obvious choices.

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 file follow?▼

ADRs live in docs/adr/ with sequential names like 0001-slug.md and contain a short 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 genuine value.

What are the limitations of a CONTEXT.md glossary?▼

CONTEXT.md is strictly a glossary and must not contain implementation details, specs, or scratch notes. It only covers terms unique to the project's domain, excluding general programming concepts like timeouts or error types.