domain-modeling

Build and maintain project domain models through CONTEXT.md glossaries and ADRs.

2|Updated Jun 21, 2026
One-click install
npx skills add https://github.com/IsKenKenYa/skills --skill domain-modeling-iskenkenya
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/IsKenKenYa/skills/tree/main/skills/engineering/domain-modeling
Command: npx skills add https://github.com/IsKenKenYa/skills --skill domain-modeling-iskenkenya

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology over time: the same concept gets multiple names, code drifts from the intended model, and key architectural decisions are forgotten. This Skill actively builds and sharpens the project's domain model during design discussions, capturing terms and decisions the moment they crystallize. ## Core Features & Use Cases - Glossary Management: Challenges conflicting or fuzzy terminology against CONTEXT.md, proposes precise canonical terms, and updates the glossary inline as terms are resolved. - ADR Authoring: Offers Architecture Decision Records only when a decision is hard to reverse, surprising without context, and the result of a real trade-off, using a minimal one-paragraph format. - Multi-Context Support: Handles both single-context repos (one root CONTEXT.md) and multi-context repos via a CONTEXT-MAP.md pointing to per-context glossaries and ADR directories. - 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 drafts an ADR when the team decides Billing communicates with Ordering via domain events instead of synchronous HTTP. ## Quick Start Ask the agent to help define the domain terminology for your project and record the key 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 domain glossary for my codebase?

Create a CONTEXT.md file at the repository root listing each domain term with a one or two sentence definition 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 is surprising without context, and it resulted from a real trade-off between genuine alternatives. If any condition is missing, skip the ADR.

How do I handle domain modeling in a multi-context repository?

Place 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. The minimal format is a short title plus one to three sentences covering context, decision, and rationale; optional sections like Status or Considered Options are added only when they add genuine value.

Should CONTEXT.md include implementation details?

No. CONTEXT.md is a glossary only and must be devoid of implementation details, specs, or scratch notes. It defines what domain terms mean, not how the system implements them.