curate-languagelisted

## Variables Request: `$ARGUMENTS` ## Purpose Maintain the consuming project's active, committed vocabulary record. The glossary is not a static dictionary and not the domain model by itself: it records language the team has actually resolved so the same model language can be used consistently in conversation, documentation, tests, and code. This skill owns **changing** that record. Merely reading the nearest glossary so another skill uses the right words is a one-line habit and does not require this workflow. Detailed entry, discovery, and multi-context rules live in [context/glossary-contract.md](context/glossary-contract.md). Read that file before any glossary write. ## Workflow ### 1. Establish what is resolved Start from the conversation, `$ARGUMENTS`, existing glossary entries, and relevant project artifacts. Identify the concrete language change: - a new project-specific concept has a stable meaning - one term is being used for two concepts - several names compete for one concept - an existing definition no longer matches the team's model - the same spelling intentionally means different things in different known contexts Exercise the candidate language in one or two domain scenarios. If the meaning, canonical term, or context is still disputed, ask one focused question and do not write yet. Never manufacture consensus. When the proposed meaning describes existing software behavior, inspect the relevant code and tests. If they contradict the conversation, sur