ManikandanandClaude Opus 5.5
ba15a574ab
Snapshot of the working project as of 2026-10-23 (local 2d4d4fc), one commit with no earlier history: the tracked files were de-identified first (synthetic claim ids and patient data only; see Context.md section 7). Credentials, run logs, screenshots, claim reports and client workbooks are gitignored and not included. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.6 KiB
Domain Docs
How the engineering skills read this repo's domain documentation before working on it. The repo is single-context: one glossary and one ADR folder, both at the repo root.
Before exploring, read these
GLOSSARY.mdat the repo root: the project's terms (VERIFY / LIVE-WRITE, Charge Summary, condition, ...).docs/adr/: read the ADRs that touch the area you're about to work in.
If either is missing, proceed silently: don't flag its absence and don't suggest creating it
upfront. The domain-modeling skill creates them lazily, when a term or a decision actually gets
settled.
File structure
/
├── GLOSSARY.md
├── docs/adr/
│ ├── 0001-verify-sets-boxes-on-screen-only.md
│ └── 0002-save-corrections-off-until-client-approves.md
└── src/ecw_bot/
Use the glossary's vocabulary
When your output names a domain concept (in a Jira summary, a refactor proposal, a hypothesis, a
test name), use the term as GLOSSARY.md defines it, e.g. VERIFY / LIVE-WRITE for the run
modes, Charge Summary for the results sheet, condition for one rule module. 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 the
domain-modeling skill).
Flag ADR conflicts
If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
Contradicts ADR-0001 (VERIFY sets boxes on screen only), but worth reopening because…