domain-glossary-maintenance

Maintains a shared PM and engineering domain glossary as a versioned knowledge entry in .hero/knowledge.

3|2|Updated Aug 24, 2026
One-click install
npx skills add https://github.com/hero-engine/hero --skill domain-glossary-maintenance-hero-engine
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-glossary-maintenance
Source: https://github.com/hero-engine/hero/tree/main/domains/pm/skills/domain-glossary-maintenance
Command: npx skills add https://github.com/hero-engine/hero --skill domain-glossary-maintenance-hero-engine

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Cross-team confusion is usually vocabulary confusion: PM says "account," engineering hears "user," and an entire spec gets built on a word two people read differently. This Skill keeps one shared, living definition of every load-bearing term as a knowledge entry in .hero/knowledge, so specs reference a single canonical meaning instead of silently re-defining terms. ## Core Features & Use Cases - Structured Term Entries: Defines a five-field entry shape (definition, owner, aliases, not-to-be-confused-with, dates) where each field prevents a specific class of ambiguity. - Add and Retire Discipline: Provides signals for when a term is load-bearing and contested enough to add, and requires explicit deprecation with pointers rather than silent deletion when terms retire. - Ambiguity Tracing: Treats recurring "what do you mean by X?" spec review comments as glossary bug reports, tracing ambiguous acceptance criteria back to missing or drifted entries. - Use Case: During a spec review, a reviewer flags "notify the user" as ambiguous because an Account has many users. Use this Skill to add a glossary entry distinguishing User from Account, then reference it by slug so the next spec does not reintroduce the ambiguity. ## Quick Start Ask the agent to create or update the domain glossary entry in .hero/knowledge for a contested term that came up in spec review.

Frequently Asked Questions about domain-glossary-maintenance

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a shared domain glossary for product and engineering teams?▼

Create one knowledge entry in .hero/knowledge (e.g. domain-glossary.md) with a structured block per term covering definition, owner, aliases, not-to-be-confused-with, and dates. Specs reference terms by slug instead of re-defining them, keeping one canonical meaning.

What fields should a glossary term entry include?▼

Each entry needs five fields: a one-sentence definition, an owner who arbitrates disputes, aliases teams actually use, sibling terms it is not to be confused with, and added plus last-reviewed dates so staleness is visible.

When should I add a term to a domain glossary?▼

Add a term when it is load-bearing and contested: it appears in specs and two people would define it differently. Signals include review comments asking "do you mean X or Y" and the same word used for two concepts. Skip obvious nouns.

Should retired glossary terms be deleted or deprecated?▼

Retire terms explicitly by marking them deprecated with a pointer to the replacement rather than deleting them. Silent deletion leaves old specs referencing a vanished definition and re-opens the confusion the entry closed.

Why do spec reviews keep stalling on terminology questions?▼

Recurring "what do you mean by X" comments usually trace to one undefined or drifted glossary term doing double duty. The fix is adding or sharpening the glossary entry as part of closing the review, not just clarifying that one spec.

Should PM and engineering maintain separate glossaries?▼

No. Two forked glossaries that define the same terms differently defeat the purpose. Record both readings when the sides disagree, name an owner who arbitrates, and converge to one shared entry per term.