Domain Docs

How engineering skills consume this repository’s domain documentation.

Before exploring, read these

• CONTEXT-MAP.md at repository root. It points to context-specific CONTEXT.md files. Read each context relevant to current work.
• docs/adr/ for system-wide decisions touching current area.
• Context-scoped ADR directories referenced by CONTEXT-MAP.md.

If any file does not exist, proceed silently. Do not flag absence or suggest creating it upfront. /domain-modeling creates domain documents lazily when terminology or decisions become settled.

File structure

This repository uses a multi-context layout:

/
├── CONTEXT-MAP.md
├── docs/adr/                    ← system-wide decisions
├── apps/
│   └── <context>/
│       └── CONTEXT.md
└── packages/
    └── <context>/
        ├── CONTEXT.md
        └── docs/adr/            ← context-specific decisions

CONTEXT-MAP.md is authoritative for context boundaries. Not every app or package needs a CONTEXT.md; create one only when it represents a meaningful domain context.

Use glossary vocabulary

When output names a domain concept—in issue titles, refactor proposals, hypotheses, or test names—use terms defined in relevant CONTEXT.md. Do not drift to explicitly avoided synonyms.

Missing terminology signals either language foreign to project or genuine domain-model gap. Reconsider first; otherwise note gap for /domain-modeling.

Flag ADR conflicts

If output contradicts existing ADR, surface conflict explicitly instead of silently overriding:

Contradicts ADR-0007 (event-sourced orders), but worth reopening because…