Make your CRM mean one thing to everyone.
Cuts field sprawl to the ones that drive decisions, locks a definition and query pattern on each, and maps every stage to what must be true to sit in it.
In plain English: “What do these fields actually mean, and which ones matter?”
Inside: The decision-driven field cut, the definition template, the stage-exit matrix, and the activity formula.
Install it in one line, or paste it in.
~/.claude/skills/ and runs automatically when it is relevant.Connect your context. Set it to your motion.
it reads your actual objects, field names, and fill rates, so the library names real fields and flags the dead ones.
it ties each field to the report or metric that depends on it, so you know what breaks if it goes empty.
it aligns the stage matrix to the methodology you already run.
This was built to be CRM-agnostic. Set these to your stack:
The library is yours. The skill's job is to cut the field sprawl down to the ones that actually change a decision, and to lock what each one means so a report never lies.
| Set this | What it is | Default / Example |
|---|---|---|
| OBJECTS | the records you run GTM on | AccountOpportunityContactLead |
| CORE_FIELDS | the fields that drive decisions | your own short list (the skill helps you find them) |
| STAGES | your pipeline stages | your real stage names |
| STAGE_TESTS | what must be true to be in a stage | your exit criteria per stage |
| ACTIVITY_SOURCES | where real engagement is logged | emailcallsmeetingsproduct |
| OWNERS | who is accountable for each field | repmanageropssystem |
Everything the skill does, in full.
Turns a messy CRM into a source of truth. It interviews you about your process, names the fields that actually drive decisions (not the 200 nobody fills), locks a plain-English definition and a query pattern for each, and maps your pipeline stages to what must be true at every one. The output is a reference every rep, analyst, and downstream skill reads from, so "what does this field mean?" has one answer instead of five.
- 1Name the fields that drive decisions
Most CRMs carry hundreds of fields and use twenty. Start from the decisions you make, forecast, prioritize, route, renew, and keep only the fields those decisions depend on. Everything else is noise the library should not bless.
- 2Lock a definition and a query pattern per field
Every kept field gets a one-line plain definition (what it means, who sets it, when) and a query pattern (how a skill or report reads it reliably). No field enters the library without both. This is what kills the "it depends who you ask" problem.
- 3Build the stage matrix
Map every pipeline stage to what must be true to sit in it: the fields that must be filled, the activity that must exist, the exit test. A deal that fails its stage test is misstaged, and the matrix is what lets an analyst catch it.
- 4Define the activity formula
Name what counts as real engagement and from which sources, so "active" and "dark" mean the same thing everywhere. A single-source activity check lies; name the full set (email, calls, meetings, product) and how days-dark is computed.
- 5Flag the dead and the dangerous
Call out fields that are always empty (drop them), fields that mean different things to different teams (redefine them), and fields people game (add a guard). The library is as much about what to stop trusting as what to keep.
- Every field in the library has a plain definition AND a query pattern. No entry with only one.
- The stage matrix has an explicit exit test per stage, never just a name.
- The activity formula names its sources; no single-source "active" claim.
- Dead and ambiguous fields are flagged, not silently included.
- No field is trusted on a fill rate it does not have. Low-fill fields are labeled, not assumed.
CRM FIELD LIBRARY · [your org] · built [date]
Field Definition Query pattern
Deal_Stage where the opp sits in the process Opportunity.StageName
Next_Step the committed next action + date Opportunity.Next_Step__c
Champion_Identified a named internal advocate exists Contact role = Champion
Last_Activity_Date most recent real engagement max(email, call, meeting)
STAGE MATRIX (exit tests):
Discovery -> problem named + next step set + 1 meeting logged
Validation -> champion identified + success criteria written
Commit -> mutual plan + close date defended by activity
ACTIVITY FORMULA:
active = any of {email reply, call connect, meeting held, product use}
in last 21 days; else days-dark = today - last of those
FLAGGED:
- Lead_Source (32% filled) -> unreliable for routing, fix or drop
- "Engaged" (means 3 different things by team) -> redefine
Where an operator takes this next.
The library is step one. Here is where an operator takes it once it holds.
Define the fields once, and every report and every skill stops arguing about what they mean.
Point your deal-health, book-of-business, and forecast skills at the field library so they all read the same definitions and the same stage tests, no drift.
Have a scheduled Claude task scan Salesforce or HubSpot against the library and DM owners in Slack the records missing a required field for their stage.
Keep the library in Notion or GitHub so a stage-model change updates one doc and every downstream skill inherits it.
One skill is the on-ramp.
A single skill does one job. Chained into a playbook, or run as a full build, it becomes a system. Here is where this one plugs in.