domain-modeling

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

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose alignment when domain terminology drifts between conversations, code, and documentation. This Skill actively sharpens a project's domain model during design discussions by challenging fuzzy terms, stress-testing relationships with concrete scenarios, and recording decisions the moment they crystallize. ## Core Features & Use Cases - Glossary Enforcement: Detects when terms conflict with the existing CONTEXT.md glossary and surfaces contradictions immediately. - Scenario Stress-Testing: Invents edge-case scenarios to force precision about boundaries between domain concepts. - Code Cross-Referencing: Checks whether stated domain behavior matches what the code actually does and flags contradictions. - Selective ADR Creation: Offers Architecture 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 the account." The Skill asks whether they mean Customer or User, updates CONTEXT.md with the resolved term, and proposes an ADR when the team picks a hard-to-reverse cancellation strategy. ## Quick Start Ask the agent to help sharpen the domain model for your project and record resolved terms in CONTEXT.md as you discuss the design.

Frequently Asked Questions about domain-modeling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I maintain a domain glossary for my codebase?▼

Keep a CONTEXT.md file at the project root containing only canonical term definitions, with no implementation details. Update it inline the moment a term is resolved during discussion rather than batching changes later.

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. If any condition is missing, skip the ADR.

What is the difference between CONTEXT.md and CONTEXT-MAP.md?▼

CONTEXT.md is a single glossary at the project root for one domain context. CONTEXT-MAP.md exists when a repo has multiple contexts and points to where each individual context file lives.

Can a domain glossary include implementation details?▼

No. CONTEXT.md must be totally devoid of implementation details. It is a glossary only, not a spec, scratch pad, or repository for implementation decisions.

How do I keep domain language consistent with code?▼

Cross-reference stated behavior against the actual code during discussions. When the code contradicts what was said, such as supporting partial cancellation when only full cancellation was described, surface the contradiction and resolve which is correct.