Domain Docs

How engineering skills consume this repo's domain documentation.

Layout: single-context

/
├── CONTEXT.md          ← domain glossary + recurring PR rules + workflow learnings
├── docs/adr/           ← architectural decisions
│   ├── 0001-dispatch-policy-module.md
│   └── 0002-command-contract-validation-module.md
└── ...

Before exploring, read these

1. CONTEXT.md at the repo root — domain terms, module names, recurring PR mistakes, workflow learnings. Read in full before naming anything or proposing architecture changes.
2. docs/adr/ — read ADRs relevant to the area you're working in before proposing structural changes. If your output contradicts an ADR, surface it explicitly:

   Contradicts ADR-0002 — but worth reopening because…

If either file doesn't exist yet, proceed silently.

Use the glossary's vocabulary

When naming modules, writing issue titles, test descriptions, or commit messages — use terms as defined in CONTEXT.md. Don't drift to synonyms. If you need a concept that isn't in the glossary, note it for /grill-with-docs rather than inventing language.

CONTEXT.md sections

• Domain terms — canonical module names and seam vocabulary (Dispatch Policy Module, Command Contract Validation Module, etc.)
• Recurring PR mistakes — CodeRabbit findings that recur; check before writing tests, shell scripts, changesets, or docs
• Workflow learnings — patterns learned from triage + PR cycles; check before writing new command/workflow files or test paths