Genarrative/docs/agents/domain.md

Domain Docs

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

Layout

This repo uses a single-context layout for Matt Pocock engineering skills:

• CONTEXT.md at the repo root, when present, is the primary domain glossary/context file.
• docs/adr/, when present, contains architecture decision records.
• If either path does not exist, proceed silently; do not block the task just to create it.

Before exploring, read these

1. Root CONTEXT.md, if present.
2. Relevant ADRs under docs/adr/, if present.
3. Existing project context that predates this setup:
   • .hermes/README.md
   • .hermes/shared-memory/project-overview.md
   • .hermes/shared-memory/team-conventions.md
   • .hermes/shared-memory/development-workflow.md
   • .hermes/shared-memory/decision-log.md
   • .hermes/shared-memory/pitfalls.md
   • Relevant files under docs/technical/, docs/prd/, docs/design/, and docs/experience/

Follow AGENTS.md when it is more specific than this file. If older docs conflict with current code or newer technical docs, treat current code and newer docs as authoritative and update stale docs when the task requires it.

Use the glossary's vocabulary

When your output names a domain concept in an issue title, refactor proposal, diagnosis, test name, or implementation plan, use the term as defined in CONTEXT.md when available. Do not drift to synonyms the glossary explicitly avoids.

If the concept you need is not in the glossary yet, either use the established vocabulary from .hermes/shared-memory/ and docs/, or note the gap for a future documentation pass.

Flag ADR conflicts

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