business-glossary
Skill0 starsChanged 2 months agoMITView on GitHub
Resolve or define business terms before they get baked into a measure, table or report name. Use when a request contains an ambiguous business term (revenue, customer, active, churn, order), when defining a new measure, when two people appear to mean different things by the same word, or when the user asks what a term means here.
In this repository6 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- naming-checkSkill
- skill-nameSkill
- workspace-bootstrapSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 29
If defined: use it, and state the definition you are working from in one line so the user can correct you cheaply.
- Distinctive: line 31
If not defined, and it matters: stop and ask. Offer the two or three readings you can see.
- Distinctive: line 32
Do not silently pick one — a wrong assumption becomes a measure, the measure gets a name, the name gets into a report, and it is a …
- Distinctive: line 44
If it takes a paragraph, it isn't a glossary entry — write it up in the project folder and link it.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Business Glossary
The most expensive bugs in analytics are not code bugs — they are two people using one word for two things, and nobody noticing until the numbers are in front of a board. This skill makes the agent stop and check rather than guess.
When to use
- A request contains a business term with more than one plausible meaning
- A new measure, table or report is being named after a business concept
- Two sources disagree on a number that "should" match
- The user asks what a term means in this organisation
When not to use
- Fabric or Power BI technical vocabulary — that's
../../standards/glossary.mdand the Microsoft Fabric skills - Terms local to a single project — check that project's
project-context.mdfirst
Procedure
- Look it up in
../../standards/glossary.md, then in the project'sproject-context.md. Project scope wins over global scope where they differ — and if they differ, say so out loud, because that is usually a mistake worth fixing. - If defined: use it, and state the definition you are working from in one line so the user can correct you cheaply.
- If not defined, and it matters: stop and ask. Offer the two or three readings you can see. Do not silently pick one — a wrong assumption becomes a measure, the measure gets a name, the name gets into a report, and it is a six-month problem.
- If not defined, and it doesn't matter: proceed, and note the assumption.
- When a new term is agreed, add it to the glossary in the same change as the artefact that uses it. A term agreed in chat and not written down was not agreed.
- Name the owner. A term with no owner has no tiebreaker.
Writing a definition
- One sentence, stated positively.
- Say what it excludes — that is where the disagreement lives (
Net Salesexcludes VAT and freight). - Fill the "don't confuse with" column; it does more work than the definition itself.
- If it takes a paragraph, it isn't a glossary entry — write it up in the project folder and link it.
Failure modes
| Symptom | Cause | Fix |
| Two measures, similar names, different numbers | Same term defined twice, independently | Consolidate; keep one, alias the other, deprecate loudly |
| A number "changed" with no code change | Definition drifted informally | Version the definition; note the change date in the glossary |
| Endless "which revenue?" in reviews | Term used in names but never defined | Define it, then rename the artefacts |
| Glossary nobody reads | It grew to 200 rows of obvious terms | Only define terms that have caused, or could cause, an argument |
Related
../../standards/glossary.md— the glossary itself../naming-check/SKILL.md— turning an agreed term into a compliant nameprojects/*/project-context.md— project-scoped overrides
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.