Forge-Glossary-Management

Harvest candidate terms from requirements, meeting notes, and stakeholder interviews, then classify them as domain or engineering terms. Draft testable definitions with stakeholders, resolve conflicts, and publish the glossary as a single authoritative artefact cross-linked from requirements and design docs.

Identify synonyms and homonyms where the same word means different things or different words mean the same thing. The Product Owner disposes on contested choices, and the chosen term plus retired aliases are recorded in the glossary with the resolution rationale.

Start at the beginning of the Specify phase, before large-scale requirements elicitation. Maintain it continuously: add terms when they first cause ambiguity, and review the glossary whenever requirements, design, or code change.

No. Project terms must not silently redefine Framework-level vocabulary defined in the Framework Glossary. Conflicts between project and framework terms are escalated through the framework's change management process.

Glossary management owns the shared vocabulary and definitions, while requirements elicitation gathers and writes the requirements themselves. Glossary terms are used verbatim inside requirements, but writing requirements is outside this Skill's scope.