domain-modeling

Build and maintain project glossaries and architectural decision records during design sessions.

2|Updated May 12, 2026
One-click install
npx skills add https://github.com/tajo9128/BioDockify-Pharma-AI --skill domain-modeling-tajo9128
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/tajo9128/BioDockify-Pharma-AI/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/tajo9128/BioDockify-Pharma-AI --skill domain-modeling-tajo9128

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 about settled decisions. This Skill captures a project's ubiquitous language in CONTEXT.md files and records significant trade-offs as lightweight ADRs the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains opinionated CONTEXT.md glossaries with canonical terms and explicitly avoided synonyms, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Architectural Decision Records: Creates sequentially numbered ADRs in docs/adr/ only when decisions are hard to reverse, surprising without context, and the result of a real trade-off. - Active Model Sharpening: Challenges conflicting terminology, proposes precise terms for vague language, stress-tests domain relationships with edge-case scenarios, and cross-references claims against actual code. - Use Case: While designing an ordering system, a 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 Help me define the domain terminology for my billing module and record why we chose Postgres for the write model.

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 a decision is hard to reverse, surprising without context, and the result of a genuine trade-off between alternatives. Skip ADRs for easily reversed choices, obvious decisions, or cases with no real alternatives.

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 relationships such as event flows or shared types. Each context then maintains its own CONTEXT.md and context-specific docs/adr/ directory.

What format should an ADR follow?

ADRs use sequential numbering like 0001-slug.md in docs/adr/ and can be as short as a title plus one paragraph 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 remain free of implementation details, specs, or scratch notes. Only project-specific domain concepts belong there, not general programming terms like timeouts or error types.