domain

Domain Docs

How the engineering skills should consume this repo's domain documentation when exploring the codebase.

Before exploring, read these

• CONTEXT.md at the repo root, or CONTEXT-MAP.md at the repo root if it exists: it points at one CONTEXT.md per context. Read each one relevant to the topic.
• docs/adr/: read ADRs that touch the area you're about to work in. In multi-context repos, also check src/<context>/docs/adr/ for context-scoped decisions.

If any of these files don't exist, proceed silently. Don't flag their absence or suggest creating them upfront. The /domain-modeling skill creates them lazily when terms or decisions are resolved.

File structure

Single-context repo:

/
├── CONTEXT.md
├── docs/adr/
└── src/

Multi-context repo (presence of CONTEXT-MAP.md at the root):

/
├── CONTEXT-MAP.md
├── docs/adr/              # system-wide decisions
└── src/
    ├── ordering/
    │   ├── CONTEXT.md
    │   └── docs/adr/       # context-specific decisions
    └── billing/
        ├── CONTEXT.md
        └── docs/adr/

When CONTEXT-MAP.md exists, read it first and then load the context-specific glossary and ADRs relevant to the work.

Use the glossary's vocabulary

When output names a domain concept, use the term as defined in CONTEXT.md. If the concept you need isn't in the glossary yet, reconsider the terminology or note the gap for /domain-modeling.

Flag ADR conflicts

If output contradicts an existing ADR, surface it explicitly rather than silently overriding.