What problem does it solve? Teams lose shared understanding of domain terminology and forget why key architectural decisions were made, leading to inconsistent language in code and repeated re-litigation of settled trade-offs. ## Core Features & Use Cases - Ubiquitous Language Management: Create and update CONTEXT.md glossaries with canonical terms, tight definitions, and explicit words to avoid, supporting both single-context and multi-context repos via CONTEXT-MAP.md. - Architecture Decision Records: Write sequentially numbered ADRs in docs/adr/ using a minimal template, offered only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Active Model Sharpening: Challenge conflicting terminology, sharpen fuzzy language, stress-test domain relationships with concrete edge-case scenarios, and cross-reference stated behavior against the actual code. - Use Case: While designing a billing feature, a user says "account" ambiguously; the skill asks whether they mean Customer or User, resolves the term, updates CONTEXT.md inline, and records an ADR when the team picks event-based communication between Ordering and Billing. ## Quick Start Help me define the domain terms for our ordering module and record why we chose event-driven communication in an ADR.
