---
name: domain-glossary-and-adr-keeper
description: "Keeps a project's vocabulary consistent by challenging new terms against a glossary and recording each naming or design choice as an ADR. Use when a project is adding terms or making a design choice that must be checked against existing vocabulary and recorded. Do not use for writing a general README or documenting an API reference. Related topics: coding, writing."
---

# Domain Glossary and ADR Keeper

Keeps a project's vocabulary consistent by challenging new terms against a glossary and recording each naming or design choice as an ADR.

## When to use

Use this skill when a project is adding terms or making a design choice that must be checked against existing vocabulary and recorded. Do not use it for writing a general README or documenting an API reference.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Compare every new term with the glossary and flag clashes, near-duplicates and synonyms.
3. Challenge each new term for ambiguity and recommend reuse, rename or add with a one-sentence entry.
4. Write the decision record with context, decision, rejected alternatives and consequences.
5. Link the record to the glossary terms it introduces and any record it supersedes.
6. Output the glossary changes and the record in the chosen format.

## Inputs

- **Existing glossary** (longer free text)
- **New terms or names proposed** (longer free text)
- **Decision made** (longer free text)
- **Alternatives considered** (longer free text)
- **Record format** (choose one: Short ADR, Full ADR, Glossary entry only)

## Output

Updated glossary entries and a decision record with title, date, status, context, decision, alternatives and consequences.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Domain Glossary and ADR Keeper

Review the terms and decisions below against our glossary and record them.

- Existing glossary: {{Existing glossary}}
- New terms or names proposed: {{New terms or names proposed}}
- Decision made: {{Decision made}}
- Alternatives considered: {{Alternatives considered}}
- Record format: {{Record format}}

For each new term, check it against the glossary for a clash, a near-duplicate or a synonym. Challenge it: does an existing term already cover this, is the word ambiguous in this domain, would a newcomer read it the way we mean? Recommend reusing, renaming or adding it, and write the glossary entry in one plain sentence. For the decision, write the record in the chosen format with a title, date, status, the context that forced the choice, the decision in one sentence, the alternatives with the reason each lost, and the consequences including costs. Link the decision to any glossary terms it introduces. Keep numbering consistent and note any earlier record this one supersedes.

## Pitfalls

- Adding a second word for something the glossary already names, which splits the vocabulary.
- Recording the decision without the rejected alternatives, so it gets relitigated.
- Writing definitions that use the term itself.