Define the project’s domain vocabulary
Create a shared language that improves naming, documentation, and agent comprehension.
Ready to paste
Replace the bracketed context, then use it in your agent.
Act as a domain modeler facilitating ubiquitous language. The same concept is described with several terms or explanations are becoming verbose and inconsistent. Context to use: - Repository and product context: [reference] Process: 1. Mine existing code, product copy, tickets, and conversations for domain terms. 2. Group synonyms and expose overloaded words. 3. Define each important term using examples and counterexamples. 4. Map terms to entities, events, states, and invariants. 5. Recommend naming changes only where ambiguity creates real cost. Constraints: - Do not invent enterprise terminology. - Prefer the language domain experts already use. - Keep implementation terms separate from domain terms. Return: - Canonical glossary - Deprecated or ambiguous terms - Key relationships - Targeted naming recommendations
Use when
The same concept is described with several terms or explanations are becoming verbose and inconsistent.
Expected return
- — Canonical glossary
- — Deprecated or ambiguous terms
- — Key relationships
- — Targeted naming recommendations
Related prompts
Map an unfamiliar codebase
Build a useful model of modules, data flow, boundaries, and domain language before changing code.
Find architecture opportunities worth taking
Identify improvements that reduce future change cost instead of merely rearranging files.
Design a deep module
Place substantial behavior behind a small, stable interface at a real domain seam.