domain-modeling

Build and maintain project domain glossaries and architectural decision records.

Updated Aug 11, 2026
One-click install
npx skills add https://github.com/Kunj-Sharma03/agent-contextify --skill domain-modeling-kunj-sharma03
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/Kunj-Sharma03/agent-contextify/tree/main/skills-main/skills/engineering/domain-modeling
Command: npx skills add https://github.com/Kunj-Sharma03/agent-contextify --skill domain-modeling-kunj-sharma03

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of domain terminology and the reasoning behind architectural choices, leading to inconsistent language in code and repeated debates over settled decisions. This Skill captures a project's ubiquitous language in CONTEXT.md files and records significant trade-offs as lightweight ADRs. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains opinionated CONTEXT.md glossaries with canonical terms and explicitly avoided synonyms, challenging conflicting or fuzzy terminology as it appears in conversation. - Architectural Decision Records: Creates minimal 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 both single-context repos (one root CONTEXT.md) and multi-context repos via a CONTEXT-MAP.md linking per-context glossaries and ADRs. - Use Case: While designing a billing feature, the user says "account" ambiguously; 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 help pin down the domain terminology for your project 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 file at the repo root listing canonical domain terms with one-to-two sentence definitions and avoided synonyms under each entry. Update it inline whenever a term is resolved during design discussions rather than batching changes.

When should I write an architectural decision record?

Write an ADR only when all three conditions hold: the decision is hard to reverse, it is surprising 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?

Create a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships with other contexts. Each context then keeps its own CONTEXT.md glossary and context-specific docs/adr/ directory.

What format should an ADR follow?

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 for 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, or scratch notes. Only include concepts unique to the project's domain, not general programming concepts like timeouts or error types.