What problem does it solve?
In a Stacks app, a domain term becomes the model name, table name, route URI, event name, and component name all at once, so a badly settled term means a rename across five layers later. This Skill actively challenges fuzzy or overloaded terms, stress-tests domain relationships with concrete scenarios, and records the resulting glossary and architecture decisions before they go stale.
Core Features & Use Cases
- Term sharpening and conflict detection: Challenges user language that conflicts with the existing CONTEXT.md glossary and proposes precise canonical terms for vague or overloaded words.
- Code cross-referencing: Verifies stated domain behavior against app/Models, relationship declarations, model events, and routes, surfacing contradictions between language and code.
- CONTEXT.md and ADR authoring: Maintains an opinionated project glossary and writes concise, sequentially numbered ADRs under docs/adr/ only when decisions are hard to reverse, surprising, and involve real trade-offs.
- Use Case: While designing a billing feature, the user says "account" loosely; the Skill asks whether they mean Customer or User, checks the existing models, updates CONTEXT.md with the resolved term, and offers an ADR recording that Ordering and Billing communicate via domain events rather than synchronous HTTP.
Quick Start
Ask the assistant to use the stacks-domain-modeling skill to review the term "subscription" in your Stacks project, reconcile it with the existing models, and record the decision in CONTEXT.md or an ADR.
