anysite-crm-audit

---
name: anysite-crm-audit
description: Read-only data quality audit of the connected CRM - field completeness per mapped property, duplicate candidates, stale records, enrichability estimate. Produces a report and a concrete fix plan, never writes anything - run it first when you don't yet know what's broken; the actual fixing happens in anysite-crm-enrich. Use when the user asks "what's the state of my CRM", wants a data quality report, duplicate check, or a safe first run after connecting a CRM. Requires an active CRM connection.
---

# CRM Audit

The safe first date with a user's CRM: read everything, write nothing, show what's broken
and what enrichment would fix. Also the natural funnel into `anysite-crm-enrich`.

## Prerequisites

Active CRM connection. No profile needed (works better with one — gap analysis follows the
mapped fields).

## Flow

### 1. Inventory

```
crm_get_schema(object_type="contacts") / (object_type="companies")
```
Use `properties` filtering when you only need specific fields — the full schema is large.
Then page through records:
```
crm_query_records(object_type=..., properties=[key fields], after=<cursor>)
```
Audit scope: whole portal if small; else the working list + a stated sample. Say which.

### 2. Analyze (all local — no further API calls)

- **Completeness:** % filled per mapped/target field (email, title, company, domain,
  industry, size, linkedin_url). Rank by gap size.
- **Match-key coverage:** how many contacts have email / linkedin_url / neither (the
  "neither" group is unenrichable and un-dedupable — flag it).
- **Duplicate candidates:** same normalized email; same domain with several company records;
  same person name + company. Candidates only — never auto-merge.
- **Email ↔ employer mismatch:** contact's email domain vs their linked company's domain.
  A mismatch has THREE causes needing different handling (all seen live): the person changed
  jobs; the COMPANY rebranded/changed domain (old domain usually still receives mail — the
  contact is fine); or the email is genuinely stale. Free discriminator already in the data:
  if crunchbase under the domain-derived alias returns a different company NAME than the
  LinkedIn page of that same domain — that's a rebrand, not a departure. FLAG ONLY, never
  auto-fix in either direction — in two causes out of three there is nothing to "fix", and
  "correcting" the company from the email domain overwrites good data with stale. Job-change
  suspects go to anysite-crm-champions.
- **Staleness:** if `anysite_last_enriched_at` (or similar) is mapped — age distribution;
  contacts with no activity fields; companies with dead domains (spot-check a few via
  `webparser/parse` only if the user asks).
- **Association health:** contacts without a company link (visible as missing company
  fields when queried).

### 3. Report

Lead with the 3 numbers that matter: enrichable-now count, duplicate-candidate count,
unenrichable count. Then per-field completeness table, then the fix plan:

- "N contacts have linkedin_url but no title → `anysite-crm-enrich` fills them (~cost)"
- "N companies missing industry/size → enrich via company lookup (~cost)"
- "N duplicate candidates → list for manual review (merging is a CRM-side operation)"

Cost estimates come from the anysite-mcp source map (credits per call × volume). Offer to
run the enrichment as the next step — do not run it from this skill.

## Hard rule

This skill performs zero writes: no upserts, no dry-runs, no "small fixes". Its value is
that it is provably safe to run on day one.