Domain Docs
Last updated
May be stale
This page was last updated ago, on 3 October 2026. Check what it says against the code before relying on it.
How the engineering skills should consume this repo's domain documentation when exploring the codebase.
Before exploring, read these
GLOSSARY.mdat the repo rootdocs/adr/: read ADRs that touch the area you're about to work in.
If any of these files don't exist, proceed silently. Don't flag their absence; don't suggest
creating them upfront. The /domain-modeling skill creates them lazily when terms or decisions
actually get resolved.
File structure
This is a single-context repo:
/
├── GLOSSARY.md ← domain glossary (lifecycle phases, realm vocabulary)
├── AGENTS.md ← conventions, footguns, tool index
├── docs/adr/ ← architecture decision records
├── docs/ ← narrative reference docs (plugins, items, logging, …)
├── gamemodes/cityrp_2_by_limelightgaming/ ← the gamemode itself
├── addons/ ← vendored addons
├── problems/ · todo/ · improvements/ ← known-issue and future-work write-ups
└── src/ ← loose build scripts, NOT a source tree
There is no GLOSSARY-MAP.md and no per-context GLOSSARY.md. Ignore the multi-context conventions
the skills mention: src/ here holds standalone build scripts, so src/<context>/docs/adr/ does
not apply.
docs/adr/ does not exist yet. That is expected, and not something to flag or fix upfront.
Use the glossary's vocabulary
When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a
test name), use the term as defined in GLOSSARY.md. Don't drift to synonyms the glossary
explicitly avoids.
If the concept you need isn't in the glossary yet, that's a signal: either you're inventing
language the project doesn't use (reconsider) or there's a real gap (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 (event-sourced orders), but worth reopening because…