Centralize

View saved version →

---
name: centralize-buyer-mirror
description: "Use to compare buyer roles from the last five closed-won deals with open accounts. Manual MCP analysis; no in-app report."
---

# Buyer mirror

Use to compare buyer roles from the last five closed-won deals with open accounts. Manual MCP analysis; no in-app report.

## Run the play

Resolve five recent closed-won opportunities and inspect their actual buying roles, titles, and available engagement evidence. Identify the recurring buyer profile and state the sample size and missing data. Compare that profile with contacts at each open account. Return mapped matches, missing roles, and questions for the AE. A matching title is a candidate buyer, not proof that the person owns budget.

## Example prompt

Analyze the buyer roles in my last five wins. Compare them with my open accounts and flag missing buyer profiles with evidence.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-champion-co-build
description: "Use during a call with a mapped champion. This is a person-led sales motion."
---

# Champion co-build

Use during a call with a mapped champion. This is a person-led sales motion.

## Run the play

Review the current map, known buying roles, and open questions before the call. Share the map through the team’s normal collaboration flow and ask the champion who is missing, who owns budget, who influences the decision, and which team runs the evaluation. Distinguish the champion’s confirmed answers from inferred reporting lines. Return the proposed map corrections, unanswered MEDDPICC questions, and next contacts. Apply chart or role changes only within the user’s requested scope.

## Example prompt

Prepare a map review with my champion at [Account]. Give me questions about budget, missing stakeholders, decision power, and evaluation ownership.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-coverage-scorecard
description: "Use in rep 1:1s to inspect engagement across top accounts. Plan dependent."
---

# Coverage scorecard

Use in rep 1:1s to inspect engagement across top accounts. Plan dependent.

## Run the play

Confirm access to the enterprise-plan touchpoint coverage report and record its refresh time; it refreshes twice a day. If unavailable, use a manual MCP review of accounts, contacts, and touchpoints within the connected user’s access. Agree the account set and time window. Compare each rep’s engaged contacts, buyer coverage, and gaps, keeping the same definitions across reps. Return the coaching priorities and proposed actions. Do not present manual analysis as a live in-app report.

## Example prompt

Build a touchpoint coverage scorecard for my reps’ top accounts. State the time window, report access, refresh time, buyer gaps, and coaching priorities.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-enrichment-consolidation
description: "Use when evaluating overlapping phone and email enrichment subscriptions."
---

# Enrichment consolidation

Use when evaluating overlapping phone and email enrichment subscriptions.

## Run the play

Review a representative sample and compare current Centralize results with the existing provider. Measure phone and email hit rates, freshness, usable results, and overlap on the same contacts. Centralize enrichment runs in the background; contact search or suggested-contact tools may also start background enrichment and need write access. Return the measured coverage, gaps, and a recommendation. Compare hit rates before claiming parity or recommending a lower ZoomInfo or LeadIQ tier; do not cancel a subscription from this workflow.

## Example prompt

Compare Centralize enrichment with our current provider on the same contact sample. Show phone and email hit rates, freshness, gaps, and evidence for consolidation.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-exec-nudge
description: "Use for a Stage 3+ opportunity with an executive or investor path to its economic buyer."
---

# Exec nudge

Use for a Stage 3+ opportunity with an executive or investor path to its economic buyer.

## Run the play

Confirm the opportunity stage and recorded economic buyer; do not infer the buying role from title alone. Find an executive or investor connection to that named person using Warm Connections. Confirm that the connector has synced LinkedIn. Draft a short nudge tied to the evaluation and a specific next step. Return the evidence, proposed sender, recipient, and draft. A Reach-Out request notifies the teammate; create one only when the user authorizes that action.

## Example prompt

For [Opportunity], find an exec or investor path to the economic buyer and draft a nudge. Flag missing role or LinkedIn evidence.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-forecast-gate
description: "Use before putting an opportunity in Commit. This is a manager-enforced gate."
---

# Forecast gate

Use before putting an opportunity in Commit. This is a manager-enforced gate.

## Run the play

Confirm a recorded economic buyer and inspect their recent engagement. Confirm a named champion whose sentiment is Supporter, with supporting evidence. Treat missing roles, stale touchpoints, and unknown sentiment as evidence gaps. Return pass, fail, or insufficient evidence for each criterion, plus the next action to close the gap. Roles can sync from Salesforce opportunity contact roles; sentiment and map accuracy still need maintenance. Do not change the forecast or mark a title as economic buyer automatically.

## Example prompt

Check [Opportunity] against our Commit gate: engaged economic buyer and Supporter champion. Show evidence, missing data, and next actions.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-map-based-pipeline-review
description: "Run weekly with the frontline manager. This is a management ritual on existing data."
---

# Map-based pipeline review

Run weekly with the frontline manager. This is a management ritual on existing data.

## Run the play

Review open opportunities on the account map. Inspect recent touchpoints, buying roles, and sentiment to find single-threaded deals and unengaged decision makers. Check whether each economic buyer is actually engaged and whether the champion’s support has evidence. Propose a thread-fill action with a named target, owner, and due date for each gap; mark unassigned fields explicitly. Return a review agenda and action list. Save or assign tasks only if requested. The review does not run or flag gaps automatically.

## Example prompt

Prepare this week’s map-based pipeline review. Flag single-threaded deals and propose a named target, owner, and due date for each thread-fill action.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: "centralize-org-chart"
description: "Build or refresh an account's org chart in Centralize: leaders on top, teams grouped by business unit, leavers removed, new hires added. Say \"build the org chart for [Account]\" or \"refresh [Account]\". Also use it to map an account, clean up its contacts, or add newly imported contacts to a chart."
---

# Centralize Org Chart Builder

Build a clean, deal-ready org chart for a prospect account in Centralize, structured the way our team reads account maps: exec spine on top, business-unit group nodes under the revenue leader, region/segment sub-groups inside Sales, narrow stacked columns instead of wide flat rows. The chart exists to answer MEDDPICC questions at a glance — who's the economic buyer, where does power sit, which region owns the evaluation — so favor clarity over org-chart-perfect accuracy, and always tell the AE which lines are inferred.

Two modes, same workflow:

- **Build** — the chart is empty or thin.
- **Refresh** — the chart exists but is months stale. Detect leavers, add new hires, fix misfiled people, and preserve the AE's hand-built structure.


## Connected tools and evidence

Use the connected Centralize MCP tool list and current schemas. Tool names may be singular or batch forms (for example setOrgChartManagers and removeOrgChartNodes). Use returned IDs, honor workspace access, and inspect each batch result for partial failures. Contact search and suggestions can trigger background enrichment and require write scope. A requested build or refresh covers chart curation; it does not authorize outreach or unrelated record changes.

The GTM/post-sale template below suits sales-team account maps. Adapt the scope when the user is mapping another buying organization. Titles, geography, and job history support inference; verified reporting evidence and the AE’s confirmed structure take precedence. A leader with no reports is a reason to investigate, not proof that a team exists.

## Target structure (the template)

```
Company root
└── CEO
    ├── C-suite peers person-to-person under the CEO (CTO, CFO, CPO...)
    │   ├── co-founders/advisors stack under the founder-CTO if there are several
    │   └── CMO keeps marketing directs nested under them (VP Mktg Ops → managers)
    └── CRO (or senior-most revenue leader) — the hub; EVERY unit below is a
        │                                     group node nested under this person
        ├── [Sales]
        │   ├── [NAMER]     → NA leaders as siblings (e.g. Head of Enterprise,
        │   │                 Head of Commercial) → managers → AE stacks by geo
        │   │                 └── [Public] → public-sector leader → their AEs
        │   │                     (sub-groups can nest under a person when a
        │   │                      distinct team exists, e.g. federal)
        │   ├── [EMEA]      → EMEA VP → segment/country managers → AE stacks
        │   ├── [APAC]      → APAC VP → regional directors → their teams
        │   └── [Strategic] → strategic-sales leader (a group even for one person)
        ├── [Business Development] → BD leader → regional BD leads → SDR/BDR
        │       stacks; if NO leader exists, chain the members into one column
        │       inside the group, senior-most on top (layout convenience — flag it)
        ├── [RevOps]       → RevOps leader → ops managers, analytics, sales ops
        ├── [Customer Success] (or [Success] / [Account Management] — match the
        │       company's titles or the existing group) → CS/AM leaders as
        │       siblings → CSM/AM stacks by region/segment; a support/services
        │       VP sits here too if worth mapping
        ├── [Enablement]   → anyone with "enablement" in their title
        └── [Partnerships] → channel/alliances leader → partner managers,
                channel directors (federal SI/channel included — function wins)
```

Rules that make this shape work:

- **Every functional unit is a group node, and regions/segments inside Sales are group nodes too.** Groups carry the org story; people carry the reporting lines inside each group. A unit or region gets its box even when it holds a single person.
- **Group names are unique chart-wide.** `parentGroupName` reuses any existing group with that name wherever it sits, so you cannot have `[EMEA]` in both Sales and CS. Inside non-Sales units, use person chains instead of region sub-groups.
- **Region names:** `NAMER`, `EMEA`, `APAC`, `LATAM`. Segment names: `Strategic`, `Public`, `Enterprise`, `Mid-Market`, `Commercial` — short, matching how the company's own titles carve territories. Reuse the exact existing name from `getOrgChart` or you'll spawn a duplicate group.
- **Width control — stack, don't sprawl.** No parent fans out wider than ~3-4 boxes (real managers/directors don't count toward the cap). Same-rank ICs cluster into vertical chains by shared trait — segment in title → city/geography → function flavor — earliest start date (senior-most) on top, the rest one-per-level beneath. Keep chains ~3 deep; split longer ones by sub-geography. These chains are layout conveniences, NOT reporting lines — name each stack and its anchor in the report.
- **Solutions/presales people get no unit of their own** — nest them under the sales leader whose team they support. Marketing stays under the CMO on the CEO side.
- **An AE's hand-built arrangement outranks the template** (e.g. BD under the CMO). Keep their structural choices but fix misfiled people inside them; flag a structural choice that looks wrong rather than silently changing it.

## Workflow

### 1. Find the account

`searchCustomers` with the company name. If duplicates come back (same name/domain), call `getOrgChart` on each and use the one with a company root and contacts; one that errors "Customer not found" is junk. Tell the AE about the duplicate so they can delete it.

### 2. Pull the chart, the full roster, and suggested contacts

- `getOrgChart` first. Note existing groups (`groupName` set, `contact` null), who sits where, and red flags: leaders with zero reports, managers whose reports are in the wrong region or segment.
- `searchContacts` with the customerId and `limit: 100`. The server returns ~27-28 per page, so paginate with `cursor` until `nextCursor` is null (the response `message` states the total). Pages usually overflow and get saved to files — process them together with `jq -s`.
- Useful jq pass: for each contact print id, name, location, function/seniority, latest target-company job (title, start, isCurrent), any newer current job elsewhere, and the first prior non-target job. When checking for a newer job elsewhere, check ALL jobs flagged current and ignore membership-type titles (advisor, board, investor, member, adjunct, fellow, mentor, angel) — they aren't employment moves. Tag each contact OK / LEFT / MOVED? / NO-JOB.
- `suggestedContacts` for the account. Add current GTM/post-sale people who are missing; mention out-of-scope suggestions instead of silently dropping them.

### 3. Clean the roster before placing anyone

- **LEFT** (the target-company job has an end date, or a newer current job elsewhere started after it). Remove them from the chart. If a departed person was a leader, their team re-parents to the group automatically — call out the leadership vacancy as deal intel. If their newest current job is at the target company, they're in, even if an old employer is still wrongly flagged current.
- **NO-JOB** (target-company email but no target-company job in the data — enrichment lag). If they're already on the chart and a prior job ended around a plausible join date, keep them and flag. If they're not on the chart, don't add them; flag them for the AE. No company email and current elsewhere → junk.
- **Dedupe.** Same LinkedIn URL twice: keep the record with the company email and flag the other for merge.
- **Scope to GTM + post-sale:** C-suite, sales, BD/SDR, RevOps, solutions/presales, enablement, partnerships, marketing leadership, and CS/AM (CSMs, AMs, expansion AMs, TAMs, onboarding) — post-sale headcount is where seat-count expansion lives. Exclude talent/HR, engineers, delivery/implementation, product support, founder's associates and back office. Mention notable borderline people.
- **Flag stale data:** emails from a previous employer and missing titles. Warn the AE not to sequence to old-employer addresses.

### 4. Classify roles — titles lie

Startups often title everyone "GTM", "Growth", "Growth & BD" or "Enterprise GTM", which mixes AEs and BDRs together.

- Classify by **prior job history**, not the current title. Previously an AE, AM or sales director → carries a bag (AE). From SDR/BDR/BD-associate or early-career roles → BDR.
- Sanity-check manager titles too. A "Demand Generation Manager", or a "Director, Growth & BD" with Non-Manager seniority, is not necessarily a people manager — don't let them anchor a team without evidence.
- A leader with zero reports ("Head of Commercial", "VP EMEA") may mean their team is misfiled. Investigate before assigning reports.
- Region beats manager for AEs. London AEs under a US enterprise manager are almost always wrong; place them under the EMEA leader.

### 5. Infer reporting lines

Infer from title + prior roles + seniority + geography, and be explicit with the AE afterward about which calls were guesses:

- Sales: regional VPs → their region group; segment leaders → siblings inside the region; managers → their segment leader; AEs → the manager whose region/segment matches, stacked per the width rule.
- A distinct public-sector/federal team gets a `[Public]` sub-group.
- BD: SDRs → the BD leader. A newer permanent Head of BD sits above an older "Interim Head", who usually becomes the regional BD lead (flag it). Stack BDRs by region/segment.
- CS/AM: leaders parent to the CS group as siblings. CSMs → their segment/region manager, or a chain inside the group if that manager left.
- When a title's function points to one leader and its region to another, function usually wins — flag it.

### 6. Write the chart

`setOrgChartManager(customerId, contactId, parentContactId | parentGroupName, [groupParentContactId | groupParentGroupName])`:

- Pass **at most one** of `parentContactId` / `parentGroupName`. `parentContactId: null` puts a contact directly under the company root — use for the CEO.
- `parentGroupName` reuses an existing group anywhere in the chart, or creates it. `groupParentGroupName` nests or moves that group inside another group — e.g. create `NAMER` inside `Sales` with its first leader: `parentGroupName: "NAMER", groupParentGroupName: "Sales"`. `groupParentContactId` hangs the group off a person (e.g. `[Partnerships]` under the CRO). Groups can be nested and moved by the API, so there is no drag list.
- Create a new group with ONE call first (the leader's placement), then place its other members in parallel. Parallel creates of the same new group can race and duplicate it.
- **Moving a contact brings their whole subtree, so place people top-down, level by level:** group leaders (L1), then their direct reports (L2), then the second element of each stack (L3), and so on. Batch within a level in parallel and wait for each level before the next. The target parent is then always already in its final spot, so there are no accidental subtree drags or cycle rotations. Ignore `wasReparented`; verify at the end.
- `removeOrgChartNode(customerId, nodeId | groupName)` works on contacts AND groups. Children re-parent to the removed node's parent, the contact record is untouched, and influencer links on a removed contact are cleared. Use it for confirmed leavers, junk records, and duplicate or empty groups — run removals BEFORE restructuring. Flag ambiguous cases instead of removing them.
- Do NOT edit the chart via Claude-in-Chrome. Canvas drops have insert-and-swallow semantics and coordinate drags are unreliable — a miss quietly rewires the chart.

### 7. Verify and report

Re-pull `getOrgChart` and confirm each group contains exactly the intended branch, there are no duplicate groups, and every stack is in the intended order. Then report to the AE, concisely:

- **Removals** — who left and where they went, plus any leadership vacancy created
- **Structure as built** — compact tree, groups as headers, new additions marked
- **What was misfiled** — the biggest structural fixes (regional AEs under the wrong leader, a leader with no team, a non-manager running a team)
- **Judgment calls to sanity-check** — every inferred line worth doubting, every layout stack and its anchor
- **Cleanup for the AE** — duplicate records/accounts to merge, NO-JOB contacts, stale emails
- **Deal intel** — leadership gaps, hiring waves (new teams haven't mapped their relationships yet), execs from existing customers or competitors (warm paths), PE/ownership signals, likely EB and evaluators
- Offer the next layer: influencer flags (`setOrgChartInfluencers`) and sentiment (`updateContactSentiment`) once the AE names the champion and EB — that's the layer that actually feeds MEDDPICC.

## API limitations (tell the AE, don't fight them)

- **No group renames** — to fix a name, remove the group, re-create it with the right name, and re-attach its members.
- **No merging duplicate contact records** — flag dupes for the AE to merge in the UI.
- **Group names are unique chart-wide** (see structure rules).

## Tone of the final report

The team uses MEDDPICC. Keep it direct, no fluff. Lead with what changed, then the judgment calls, then deal-strategy observations (single-threaded risk, warm paths, where seat count lives). Never use the word "quick."

View saved version →

---
name: centralize-persona-functions-creation
description: "Define buyer functions and personas for a named account in the connected Centralize workspace. Use when the user asks to configure who that account's sales team sells to."
---

# Configure buyer functions and personas

Read [workspace and write boundaries](../../references/workspace-safety.md) first.
Model the external buyers that the named company's sales team serves, not the plugin developer's own buyers.

## Establish scope and existing definitions

Resolve the company with `searchCustomers`. Read `getAccountContext`, `listFunctions`, `listPersonas`, and `listSeniorities`.
If the account does not exist, stop and ask whether the user wants to add it. Do not create an unrelated default function.
If account context does not establish the company's buyers, ask for its target roles and sales motion.
Do not require external enrichment, private call notes, or another plugin to complete this workflow.

Reuse matching functions and persona concepts. Flag duplicates and prospect-specific text on workspace defaults without editing them.
Do not assume that the connected workspace contains a fixed set of functions or seniority names.

## Present the plan

For each new function, give its name, responsibilities, four to eight example job titles, and five to eight related keywords.
Use generic responsibilities so the function does not contain another prospect's sales pitch.
Mark each definition as reuse or create. New account-specific functions require `isDefault: false` and `accountIds` for the selected account.

For each persona, give its name, function, discovered seniorities, and business context of no more than 1,000 characters.
Explain the buyer's responsibilities, relevant problem, buying triggers, role in the decision, and common objections.
State which claims come from account context and which require user confirmation.

Personas are workspace-wide definitions even when they include `customerOverrides`. Explain this scope before approval.
Reuse an existing persona when it fits. The plugin has no persona-update operation, so do not create duplicates to emulate an update.
When an existing persona needs a new override, report the required edit for the user to make in Centralize.
Obtain confirmation of the exact definitions, account bindings, and workspace-wide effects before creation.

## Create and verify

Create approved functions with `createFunction` before the personas that depend on them.
Trim names, keep them within 200 characters, and exclude colons from function names.
Keep function descriptions within 1,000 characters.

Use `createPersona` with either `customFunctionName` or `function`, following the current schema.
Use discovered `customSeniorityNames` or supported base `seniorities` without inventing names.
Use `customerOverrides` only when creating an approved new persona that requires account-specific mappings.
Never imply that `createPersona` edits an existing persona.

Read `listFunctions` and `listPersonas` again. Report stored names, account bindings, created definitions, and unsupported edits.
After a partial failure, re-read existing definitions before retrying to prevent duplicate creation.

View saved version →

---
name: centralize-prospect-workspace-setup
description: 'Set up supported account maps, buyer personas, and account views in the connected Centralize workspace. Use for a requested prospect workspace setup after the intended workspace is established.'
---

# Set up the connected workspace

Read [workspace and write boundaries](../../references/workspace-safety.md) first.
This workflow adapts Hunter's prospect setup to the operations available through this plugin.
It cannot administer another workspace or complete browser-only settings.

## Establish the requested setup

Call `whoami` and compare the returned workspace with the user's intended workspace.
If they differ, stop before writes. Ask the user to connect the intended workspace.
Do not assume that the connector belongs to Centralize's internal sales workspace or to the prospect.

Ask only for missing account names and domains, target buyers, and requested saved account views.
Read existing accounts and account context before proposing additions.
Show the setup plan and its effects before confirmation. Account creation can activate accounts, consume capacity, and start background work.
Keep account activation, deep research, notifications, and workspace-wide defaults outside the plan unless specifically requested.

## Apply supported steps

1. For an approved new account, call `addAccounts` with the confirmed name and domain. Inspect results before dependent steps.
2. For buyer definitions, use [the persona workflow](../centralize-persona-functions-creation/SKILL.md). Reuse definitions before creation.
3. For each requested account map, use [the chart workflow](../centralize-org-chart/SKILL.md). Confirm proposed changes before writes.
4. For a requested saved accounts list, use `createAccountView` with filters supported by its current schema.

Each saved view must match the requested owner and sharing scope. Use a resolved owner rather than a viewer-relative filter for a named person's view.
Do not guess user identifiers. If the available tools cannot resolve a required owner or sharing setting, report that limitation before creation.
Do not activate an existing account merely because it is absent from a search result.

## Report remaining setup

The plugin does not support workspace switching, edits to existing functions or personas, default stakeholder filters, or account starring.
It also cannot create saved views for Home, Contacts, Connections, Opportunities, or Job Changes through `createAccountView`.
Do not replace these missing operations with browser automation or another connector.
Give the user a concise list of remaining settings to complete in Centralize.

Read back accounts and charts with the available read tools. Use a returned view link to report successful view creation.
Do not claim an unverified default, sharing setting, or saved view is complete.
Report completed steps, failed steps, user-approved inferences, and remaining setup separately.

View saved version →

---
name: centralize-single-champion
description: "Use when a customer has only one engaged contact. Add their manager and a peer before T-120 relative to renewal. Manual review."
---

# Single champion

Use when a customer has only one engaged contact. Add their manager and a peer before T-120 relative to renewal. Manual review.

## Run the play

Confirm the renewal date and define the engagement window. Review the map and touchpoints to verify that only one contact is engaged. Identify the champion’s manager and a relevant peer, marking inferred lines. Propose a champion-sponsored introduction and a named owner for each relationship. Return the renewal date, T-120 target date, evidence, contacts, and next steps. If renewal timing is missing, say so. There is no single-champion alert.

## Example prompt

Review [Customer] for single-champion risk before renewal. Show T-120, engagement evidence, the champion’s manager and peer, and proposed intros.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-spend-by-density
description: "Use when choosing metros for field events using contacts at open opportunities."
---

# Spend by density

Use when choosing metros for field events using contacts at open opportunities.

## Run the play

Resolve the open-opportunity account set and group relevant contacts by metro using location radius filters on contacts and warm connections. State the radius, scope, location gaps, and deduplication basis. Compare contact density and available relationship owners by city. Return a ranked metro list with contact counts and named warm paths that could support invitations. This is a planning workflow, not an automatic event campaign. Verify opportunity-level buying-role filter behavior before relying on it; do not treat omitted roles as no buyer coverage.

## Example prompt

Rank metros for a field event using contacts at our open opportunities. State the radius and data gaps, and show warm connections in each city.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-territory-balance
description: "Use to compare books by warm-path density rather than account count alone. Manual MCP analysis; no in-app report."
---

# Territory balance

Use to compare books by warm-path density rather than account count alone. Manual MCP analysis; no in-app report.

## Run the play

Resolve the territory assignments and accessible account sets. Define warm-path density consistently, such as available paths per account, and distinguish distinct connectors from path counts. Compare books using the same measure. Flag stale relationships, unsynced connectors, and incomplete data before drawing conclusions. Return the imbalances and proposed account moves with their rationale. Do not change ownership or territory assignments without a specific request.

## Example prompt

Compare our books by warm-path density. Define the measure, flag sync and freshness gaps, and propose territory changes with evidence.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-thread-gap
description: "Use for Stage 2+ opportunities with no engaged economic buyer or fewer than three engaged contacts. Manual review."
---

# Thread gap

Use for Stage 2+ opportunities with no engaged economic buyer or fewer than three engaged contacts. Manual review.

## Run the play

Resolve the opportunity stage, map, buying roles, and touchpoints. State the engagement window and count distinct engaged contacts, not activity events. Identify whether the economic buyer is known and engaged. For each gap, find a warm path to a missing buyer or evaluator and propose the next action. Return the account, thread count, buyer evidence, target, connector, and proposed owner. Nothing automatically flags this gap; run the review through a manager or MCP.

## Example prompt

Review Stage 2+ opportunities for an unengaged economic buyer or fewer than three engaged contacts. State the engagement window and suggest warm paths to fill gaps.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-warm-before-cold
description: "Use when a target account has a warm path, before starting a cold sequence."
---

# Warm before cold

Use when a target account has a warm path, before starting a cold sequence.

## Run the play

Resolve the account and target contact. Review warm connections, the relationship owner, and the evidence behind each path. Check that the relevant teammates have synced LinkedIn and that the relationship is current. Choose the strongest credible path and draft a specific introduction request. Return the target, connector, evidence, and draft; flag missing sync coverage. Create a Reach-Out request only when the user authorizes notifying that teammate.

## Example prompt

Find the best warm path into [Account] before I sequence it. Show the target, connector, relationship evidence, and a draft intro request.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-warm-path-sort
description: "Use when deciding which accounts in a rep’s book to work first."
---

# Warm-path sort

Use when deciding which accounts in a rep’s book to work first.

## Run the play

Resolve the book and account owner. Count available warm paths by account, distinguish paths from unique connectors, and record the count basis. Rank accounts by warm-path count and return the top 20 with a named target and strongest path. Flag stale connections, missing LinkedIn syncs, and accounts whose path data is unavailable; unavailable does not mean zero. This is a Connections-page or MCP review, with no automatic territory rebalance.

## Example prompt

Rank my book by available warm paths. Show the top 20, strongest connector and target per account, and data gaps.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.

View saved version →

---
name: centralize-whitespace
description: "Use when a customer’s map shows teams that may not use your product. Manual expansion motion."
---

# Whitespace

Use when a customer’s map shows teams that may not use your product. Manual expansion motion.

## Run the play

Review the customer map and suggested contacts. Overlay customer-provided usage or adoption data to identify covered and uncovered teams; the map alone does not establish product usage. If usage data is missing, label teams as candidates and ask for that evidence. Identify the next team lead and a credible connection through the current champion. Return the team, adoption evidence or gap, target, champion, and draft intro. No customer-account expansion workflow runs automatically.

## Example prompt

Compare [Customer]’s map with our usage data. Find uncovered teams and propose champion-sponsored intros to the next team leads.

Use current Centralize tool schemas and returned IDs. Cite sources and mark uncertainty. Draft outreach and tasks unless requested.