# 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 present
- `docs/adr/`, if present, for architectural decisions that touch the area being discussed

If these files do not exist, proceed silently. Do not flag their absence or suggest creating them upfront. The producer skill `/grill-with-docs` creates them lazily when terms or decisions actually get resolved.

## File structure

This repo is currently single-context:

```text
/
├── CONTEXT.md
├── docs/adr/
│   ├── 0001-example-decision.md
│   └── 0002-example-decision.md
└── docs/
```

## Use the glossary's vocabulary

When output names a domain concept, use the term as defined in `CONTEXT.md`. Do not drift to synonyms that the glossary explicitly avoids.

If the concept is missing from the glossary, either the language is speculative or the project has a real vocabulary gap. Note the gap for `/grill-with-docs`.

## Flag ADR conflicts

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