Naming Audit

Take a source — a list of claimed labels/values/mappings ("the Portal shows X, CRM says Y, rename to Y") — and verify each item against the authoritative system of record, one at a time. The output per item is a short card with a verdict and the exact path to check.

The whole skill rests on one discipline you must not skip: trace the binding before you judge the wording. A label is only "wrong" relative to the specific field it actually writes to/reads from — not relative to a similarly-named field elsewhere. The source doc's "authoritative" column is frequently from the wrong entity; do not trust it.

When to invoke

"naming audit" · "label audit" · "check wording/terminology" · "does the Portal/app label match CRM/DB/API?" · "verify this naming spreadsheet" · "reconcile field names" · "is this the canonical label?" · "CRM/source-of-truth wins — fix the UI to match". Any time the user has a list of specific claimed names/values to check item-by-item.

Not this skill: broad "what's missing / how far are we" capability comparison → fit-gap-analysis. Turning the confirmed fixes into work items → the backlog plugins (ado-backlog / github-backlog).

The three roles (name them first)

• Source — the document making claims (the audit sheet, dictionary, i18n file, finding list). Treated as unverified hypotheses, including its "authoritative" column.
• Implementation — where the label is shown (UI code, a report, an export). What you're auditing.
• Authority (system of record) — the live system that defines the correct value (CRM/Dataverse metadata, DB information_schema, API/OpenAPI contract, design-token source, option-set definitions). This wins, always.