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, if it exists.
• docs/adr/, if it exists. Read ADRs that touch the area you’re about to work in.
• AGENTS.md and docs/00-index.md for this repo’s operating doctrine and canonical reading order.
• docs/02-product-capability-contract.md when the work changes product scope, parity, or completion semantics.

If CONTEXT.md or docs/adr/ do not exist, proceed silently. Do not flag their absence or create them upfront. Domain modeling skills create them lazily when terms or decisions actually get resolved.

File structure

This is a single-context repo:

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

CONTEXT.md and docs/adr/ may be absent until the first glossary term or ADR-worthy decision is resolved.

Use the glossary’s vocabulary

When your output names a domain concept in an issue title, refactor proposal, hypothesis, or test name, use the term as defined in CONTEXT.md when that file exists.

If the concept you need is not in the glossary yet, either reconsider whether you are inventing language the project does not use, or note it for /domain-modeling.

Flag ADR conflicts

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

Contradicts ADR-0007 — but worth reopening because…