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, because 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, use grillkit when installed or ask the user to settle it directly rather than writing down a guess.
• Not a status tracker. There is no status.md and no "current state" file. Project status is ambient: issues track what's planned, git and session history track what happened, a handoff compacts state on demand. domainkit persists only what those can't recover, meaning the vocabulary and the reasoning behind irreversible choices.

Procedure

Every write is consent-gated, so detect, offer, then write only on a yes. A misfire costs one dismissible offer, never a spurious file.