establishing-project-context

# Establishing Project Context ## Overview Maintain project domain language in `CONTEXT.md` so humans and agents use the same canonical terms. This skill is the single active-modeling and write-policy owner; it does not own passive glossary reads. `CONTEXT.md` is terminology infrastructure, not Aegis governance, architecture, requirements, task state, session memory, or runtime authority. Those retain their current project owners. ## Passive Consumption vs Active Modeling Passive consumption is a cheap habit of the task-owning workflow: 1. For non-trivial project work, check `CONTEXT-MAP.md`, then relevant root or bounded-context `CONTEXT.md` files when present. 2. Read only relevant active terms and relationships; index first when large. 3. Treat open ambiguities as unresolved data, not active truth. 4. Continue the owning workflow without loading this skill. Load this skill only for active modeling when at least one signal exists: - a newly resolved domain concept - a vague, overloaded, or conflicting term - an approved rename, merge, deprecation, or meaning change - authority, code, tests, or public language contradict the glossary - a deprecated alias re-enters user-visible language Tiny factual, status, formatting, or mechanical work performs no context ceremony. ## Location and Safety - Single context: `<project-root>/CONTEXT.md` - Multiple bounded contexts: root `CONTEXT-MAP.md` maps context names to local `CONTEXT.md` files; system-wide language stays ...