domainkit

Scribe of the project's domain model. domainkit keeps two living artifacts current: CONTEXT.md, a short overview of what the product is and who it is for followed by a glossary of the project's ubiquitous language, and docs/adr/, the log of architectural decisions and why they were made. Its core 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. 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. Two explicit modes sit beside that loop: one seeds CONTEXT.md for a project in a single pass, and one checks later whether it still matches the code.

When this fires

Route to one of three modes:

• record, the default. 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. 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.
• init. The user asks to seed the domain model: "set up CONTEXT.md", "write the project overview", "domainkit init". It reads the repo, interviews the owner once, and proposes a whole CONTEXT.md.
• audit. The user asks whether the model still holds: "is CONTEXT.md still accurate", "audit the glossary", "domainkit audit". statuskit routes here when CONTEXT.md has fallen behind the code.

A model-fired run always routes to record. init and audit run only when the user asks for them, because each reads the whole repo and proposes a large diff, and that cost is the user's to choose.

Two things domainkit deliberately is not: