Domain Memory

Domain Memory is a continuous development loop, not a one-time knowledge dump. The reviewed Registry guides implementation; implementation evidence updates the Registry for the next Agent.

First time here? AGENTS.md has the vocabulary, a table of common tasks with their commands, and the mistakes that force a redo, in one page.

In an unfamiliar repository, run the read-only readiness command first, and treat only reviewed records as facts; candidates are handoff material and authorize no implementation (AGENTS.md). See readiness for the evidence and output contract.

Choose one focused capability:

• Extract: turn a requirement, existing code, or a requirement change or refactoring into DDD candidates with evidence. Use domain-memory-extract.
• Read: before coding, load the reviewed terms, Context, ownership, invariants, and existing collaboration. Use domain-memory-read.
• Design: when a request changes a boundary, contract, event, consistency rule, or material business rule, prepare a reviewable Change Package. Use domain-memory-design.
• Maintain: after implementation or source drift, update the smallest affected asset as a candidate and preserve evidence. Use domain-memory-maintain.
• Review: before relying on domain facts or handing off work, validate the Registry, source evidence, audit chain, and proposal state. Use domain-memory-review.
• Implementation hygiene: after Read or Design, and whenever a repository check forces a change, check that code expresses the reviewed boundary without turning generic style rules into Registry facts. Use domain-memory-implementation-hygiene.

For a brownfield refactoring that preserves the reviewed model, use the brownfield refactoring fast path before opening a Change Package. It is a proof of preservation, not a shortcut around unknown ownership or changed contracts.

All capabilities share one file-backed Registry, policy, source map, audit chain, and Change Package schema.

Read the seven-step workflow for material domain changes and the file-backed API for command shapes. The scripts are the controlled write boundary; Git remains the collaboration and review boundary.

A Registry that has never named an approval authority holds candidates only, and no capability can promote one. The API reference's Preparing the approval authority section covers the two situations: a repository whose pull requests are reviewed, and a repository where the maintainer signs instead.

Use tactical design reasoning when guiding implementation. Preserve domain boundaries and invariants, then let the Agent choose the language-idiomatic tactical pattern; do not turn this Plugin into a code template library.

For a material change, pass the compact implementation handoff from Read or Design to the coding Agent. It carries facts and proof obligations, not code shape.

When the change reaches an external system, settle the boundary with ports and adapters. For how the code states the reviewed facts, how a refactoring proves it preserved behavior, and why this Plugin carries no numeric limit, use code expression.

Verify any claimed tactical Pattern with pattern verification, including a counterfactual test when the change is material.

Supporting references: evidence rules, Registry authoring, Registry schema, proposal lifecycle, and reliability target architecture.

plugin.json packages Skills and optional scripts but does not declare subagents. A host may delegate these capabilities to its own agents; otherwise run them sequentially. See host integration.

Distribute the complete capability set as the Plugin. Distribute one directory under skills/ when a host accepts only a standalone Skill; the root router is not a standalone replacement for the lifecycle capabilities. See packaging.