$ loading_
Extract and maintain a domain glossary with consistent terms and ambiguity checks.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "domain-glossary" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/devsquad-copilot/main/.github/plugins/devsquad/skills/domain-glossary/SKILL.md 2. Save it as ~/.claude/skills/domain-glossary/SKILL.md 3. Reload skills and tell me it's ready
Based on this PRD, technical spec, and user stories, extract a domain glossary. For each term, provide the canonical name, definition, common synonyms, confusing alternatives, whether it is ambiguous, and relationship mappings to other terms. Finally, flag conflicting terms that need team review.
A structured domain glossary with canonical terms, synonyms, ambiguity flags, term relationships, and a review issue list.
Check whether terminology is consistent across the following specs, ADRs, and work items. Identify cases where one concept is described with different names, or one term refers to multiple concepts, and provide recommended canonical terms plus a replacement list.
A terminology consistency review listing conflicts, risks, standardization recommendations, and itemized replacements.
I am drafting a new spec. First build a baseline domain glossary from existing project documents, then check whether the terms in my draft align with existing definitions. If new terms appear, determine whether they should be added to the glossary and explain their relationship to existing terms.
A baseline glossary for spec writing, plus compliance checks and recommendations for newly introduced terms.
Enterprise systems accumulate terminology debt: the same concept called different names across teams, specs, and code. Synonym drift corrupts search, work-item labeling, and cross-spec consistency. A shared canonical glossary reduces misunderstanding and improves spec-to-code traceability.
This skill has two modes: extract (build or update a glossary) and validate (check an artifact against the glossary).
| Trigger | Action |
|---|---|
New feature spec created (devsquad.specify) | Extract terms from the spec |
Envisioning completed (devsquad.envision) | Extract terms from the envisioning document |
| Domain discussion in conversation | Extract terms as they emerge |
| Explicit user request ("build a glossary", "define domain terms") | Full extraction from available artifacts |
| Review finding: inconsistent terminology | Update glossary with canonical choice |
docs/domain/GLOSSARY.md (or create from template if it does not exist)docs/features/**/spec.md)docs/envisioning/*.md)docs/architecture/decisions/*.md)docs/domain/GLOSSARY.md using the format below# Domain Glossary
## [Domain Group]
| Term | Definition | Status | Aliases to avoid |
|------|-----------|--------|-----------------|
| **[Term]** | [One sentence: what it IS, not what it does] | [Established/Proposed/Contested] | [Synonyms to avoid] |
## Relationships
- A **[Term A]** belongs to exactly one **[Term B]**
- A **[Term C]** produces one or more **[Term D]**
## Flagged Ambiguities
- "[word]" was used to mean both **[Term X]** and **[Term Y]**. These are distinct concepts: [explanation of the difference and recommended usage].
GLOSSARY.md when the first terms are resolved; do not bloat new projects| Level | Criterion |
|---|---|
| Established | Term appears consistently in accepted specs and ADRs |
| Proposed | Term chosen during extraction but not yet validated by the team |
| Contested | Multiple stakeholders use different terms for the same concept |
Mark contested terms in the Flagged Ambiguities section until resolved.
| Agent | Artifact | Check |
|---|---|---|
devsquad.specify | spec.md | Terms used in the spec exist in the glossary; no synonym drift |
devsquad.review.spec | spec.md | Flag terms that contradict or diverge from the glossary |
…
Design and review software architecture diagrams for clearer, documentation-friendly visuals.
Create, switch, and verify Git branches before starting implementation work.
Initialize projects or verify and generate up-to-date SDD documentation templates.
Verify and create standard community and governance files for new projects.
Verify assignee, dependencies, priority, and capacity before starting a work item.
Systematically triage failures and fix broken builds or unexpected runtime issues.
Name code by domain meaning to improve clarity and team alignment.
Model complex domains and define system boundaries with Domain-Driven Design.
Create and maintain ADRs with checks, references, and planning support.
Design or evaluate web services, APIs, scalability, and reliability tradeoffs.
Generate multilingual code identifier names from domain concepts.
Create or review ADRs to compare technologies and document design trade-offs.