domain-modeling

Build and maintain project domain glossaries and architectural decision records.

Updated Jul 16, 2026
One-click install
npx skills add https://github.com/pjherron/hypoc --skill domain-modeling-pjherron
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/pjherron/hypoc/tree/main/hypoc/skills/domain-modeling
Command: npx skills add https://github.com/pjherron/hypoc --skill domain-modeling-pjherron

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology over time, leading to inconsistent language in code, docs, and conversations. 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 - Glossary maintenance: Creates and updates CONTEXT.md inline as terms are resolved, keeping it free of implementation details. - Terminology challenges: Flags conflicts between user language and the existing glossary, and proposes precise canonical terms for vague words. - Scenario stress-testing: Invents edge-case scenarios to force precision about boundaries between domain concepts, and cross-references claims against actual code. - Selective ADRs: Offers architectural decision records only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Use Case: While designing an order system, the user says "cancel an order" — the Skill notices the code only supports full cancellation, surfaces the contradiction, and updates CONTEXT.md with the resolved definition of partial cancellation. ## Quick Start Ask the assistant to help pin down the domain terminology for your project and record the decisions in CONTEXT.md and 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 domain glossary for my project?▼

Create a CONTEXT.md file at the repository root and add terms as they are resolved during design discussions. Keep it strictly a glossary of domain language with no implementation details, and update it inline the moment a term is agreed upon.

When should I write an architectural 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. If any condition is missing, skip the ADR.

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

Place a CONTEXT-MAP.md at the repository root pointing to each context's location. Each bounded context gets its own CONTEXT.md and docs/adr directory, while system-wide decisions stay in the top-level docs/adr folder.

What is the difference between reading a glossary and domain modeling?▼

Reading CONTEXT.md for vocabulary is a passive habit any workflow can do. Domain modeling is the active discipline of changing the model: challenging conflicting terms, sharpening vague language, and writing down new definitions and decisions.

Should CONTEXT.md contain implementation details or specs?▼

No. CONTEXT.md is a glossary and nothing else — it must be devoid of implementation details, specs, and scratch notes. Implementation decisions belong in ADRs under docs/adr, not in the glossary.