domainkit

# domainkit Scribe of the project's **domain model**. domainkit keeps two living artifacts current as work happens: **`CONTEXT.md`**, a glossary of the project's ubiquitous language, and **`docs/adr/`**, the log of architectural decisions and why they were made. Its loop is narrow on purpose — **detect the moment, offer to record it, write on consent** — so the vocabulary and the reasoning behind hard choices stay pinned down without anyone remembering to do it. It runs primarily as a **byproduct of design work**, though explicit invocation is supported. While a decision is being grilled, a plan drafted, or code written, a term crystallizes or a decision lands — that's when domainkit fires, proposes the entry, and writes it once you say yes. ## When this fires A **domain term** needs pinning down — it's vague, overloaded, or two words are being used for one concept — or a **decision** gets settled that meets the ADR bar (below). Also on explicit asks: "record this decision", "write an ADR", "update the glossary", "add this term to the ubiquitous language", "/domainkit". And when another skill needs the domain model kept current, it defers here rather than carrying the format itself. Two things it deliberately is **not**: - **Not the interrogator.** Challenging a term, inventing edge-case scenarios, stress-testing whether a decision holds — that's an interrogation step. domainkit records the *settled* understanding; if a term or decision is still genuinely unresolved, us...