RocketReach

View saved version →

---
name: build-list
description: Build a list of people or companies by filtering on title, seniority, department, industry, company size, location, and more. Returns a structured table you can export
---

# Build List

Build a targeted list of people (or companies) from RocketReach and return it as a structured table.

## Input

The user describes who (or what) they want in natural language.

- Natural-language description of who or what to find.
- Type - auto-detected (people vs companies); ask once if ambiguous.
- Result count - optional (default 25, max 100).

Examples:

- `/rocketreach:build-list Product managers at Tech companies in Boston, 51-200 employees`
- `/rocketreach:build-list VPs of Sales at healthcare companies in the US`
- `/rocketreach:build-list Directors of Engineering at companies using Salesforce`
- `/rocketreach:build-list cardiologists in Boston`
- `/rocketreach:build-list companies in Maine, 200-1000 employees (company list)`

## Workflow

1. **Decide people or companies.** Determine whether the user wants people or companies from cues:
   - "VPs", "managers", "leaders", "decision-makers", "people who…" → people.
   - "Companies using…", "firms with…", "startups that…", "businesses in…" → companies.
   - Ambiguous ("show me everyone in X") → ask once.
2. **Parse the request into search filters.** Each filter is an array in the query object:

   For people (person_search):
   - Titles → current_title
   - Seniority → management_levels
   - Department → department
   - Skills → skills
   - Education → school / degree
   - Location → location
   - Current employer industry → company_industry
   - Current employer size → company_size
   - Healthcare → health_npi, health_specialization, health_license, health_credentials
   - Free-text → keyword

   For companies (company_search):
   - Identity → name, domain
   - Classification → industry, sic_code, naics_code
   - Size → employees, revenue
   - Location → location
   - Tech stack → techstack
   - Competitors (domains) → competitors
   - Other signals → keyword, company_tag

   Use exclude for any "but not X" patterns.
3. **Run the search.** Call person_search OR company_search with parsed filters. Defaults:
   - page_size: 25 (configurable up to 100).
   - order_by: relevance.

   No credits consumed.
4. **Show the list first, then offer to enrich it if it is a person list.** Present the results as a table using the templates below. Do NOT auto-run lookups on everyone - that spends credits. Ask the user which people (or how many) they want verified contact info for, then run person_lookup on just those, confirming credit type if multiple are active.

## Output - Person List

### Filters applied

Show exactly what was searched on so the user can verify:

| Filter | Value |
| --- | --- |
| current_title | Product Manager |
| company_size | 51-200 |
| location | Boston |

### Results (people)

| # | Name | Title | Company | Location |
| --- | --- | --- | --- | --- |
| 1 | | | | |
| 2 | | | | |

Person Search returns preview fields only (name, current_title, current_employer, location, and the RocketReach profile ID). LinkedIn URL is not part of the search preview — it comes back from person_lookup at enrichment.

## Output - Company List

### Filters applied

Show exactly what was searched on so the user can verify:

| Filter | Value |
| --- | --- |
| employees | 51-200 |
| location | California |

### Results (Company)

| # | Name | Domain | Industry | Size |
| --- | --- | --- | --- | --- |
| 1 | | | | |
| 2 | | | | |

Company Search returns preview fields only (name, domain, industry_str, employee_count, and the RocketReach company ID).

## Next step

- Person list: Enrich the top N → enrich-person on selected people (confirm count + credit type).
- Company list: Find people there → prospect or build-list (people) on selected domains.

## Notes

- Keep the search step and the lookup step clearly separate so the user controls credit spend.
- **No credits consumed.** This is the safe entry point for exploration. The list is a preview; enrichment happens elsewhere.
- **Result truncation.** When Total matching is high (>1000), the top 25 are not a random sample — they're sorted by relevance. Refinement suggestions help users narrow toward the subset they actually want.
- **Filter values must resolve.** Industry names, tech-stack names, etc. follow RocketReach's taxonomy. If a user requests a filter that doesn't resolve (e.g., a niche industry name), surface that and suggest the closest matching values.

View saved version →

---
name: enrich-company
description: Look up a company profile by name, domain, LinkedIn URL, or ticker symbol, Returns a complete company profile that includes domain, employee size, location, revenue, industry, and other firmographic details.
---

# Enrich Company

Take an identifier for a single company and return its full RocketReach profile.

## Input

The user will provide at least one of these to identify the company:

- Domain (preferred - most reliable match)
- RocketReach company ID
- Stock ticker symbol
- LinkedIn URL
- Company name

Examples:

- `/rocketreach:enrich-company rocketreach.co`
- `/rocketreach:enrich-company RocketReach`
- `/rocketreach:enrich-company www.linkedin.com/company/rocketreach.co`
- `/rocketreach:enrich-company NYSE:CRM`

## Workflow

1. **Confirm Company Export access.** Company lookups require Company Export credits, separate from person credits. If the user's company_export availability hasn't been surfaced in this conversation, call account. If allocated: 0 for company_export:
   - Stop the enrichment flow.
   - Surface: "Your plan doesn't include company_export credits, so company_lookup isn't available. You can search for companies without credit consumption — try /rocketreach:build-list companies [criteria], or contact your account team to enable company exports."
   - Do not call company_lookup
2. **Parse the identifier.** Prefer domain when available, since names can be ambiguous (several companies can share a name). If the user gives only a name and the match is unclear, confirm which company they mean before pulling data. Priority order - RocketReach company ID → domain → ticker → LinkedIn URL → name.
3. **Disambiguate (only if needed).** If the user only enters a company name and nothing else, call company_search with name: [input] and page_size: 5.
   - Single match → mark auto-resolved, proceed.
   - Multiple plausible candidates → present top 3 with name, domain, industry, employee count, HQ. Ask the user to pick. Mark ambiguous.
   - Zero results → mark failed, ask the user for a more specific identifier (like domain).
4. **Call company_lookup** with the resolved identifier.
5. **Display credit cost.** Tell the user whether a Company Export credit was charged. A credit is used when company information is returned; if no match was found, no credit is used.
6. **Format the company profile.** Use the output template below.

## Output

Lead with a header line, then present the returned fields below. Not every field is populated for every company - show what is present.

`[name] ([domain]) - [industry] · [num_employees] employees · [HQ location]`

| Field | Value |
| --- | --- |
| Name | [name] |
| Domain | [domain] |
| Employees | [num_employees] |
| Revenue | [revenue] |
| Industry | [industry] |
| Location | [city], [region], [country] |
| Founded | [year_founded] |
| LinkedIn | [links: linkedin] |
| Tech stack | [techstack] |
| Competitors | [competitors] |
| Departments | [departments] |
| Funding investors | [funding_investors] |
| RocketReach ID | [id] |

Lead with what the user is most likely to care about (size, revenue, industry, location). Tech stack, competitors, departments, and funding are the differentiating fields - surface them when present. SIC/NAICS codes, ticker, full address, and description are also available if the user asks. If fields are unavailable, omit the row.

## Next Steps

- `/rocketreach:build-list` - find people at the company by role.
- `/rocketreach:prospect` - build a prospect list scoped to this company.
- `/rocketreach:enrich-person` - look up a specific named person at the company.

## Notes

- company_export access is gated so some plans may not have access. Make sure to check as part of the initial workflow step above.
- **Disambiguation prefers domain.** When the user provides only a company name, the search step ranks candidates by domain-match strength against the name.
- **Host-level prompts.** The company_lookup tool is marked destructiveHint: true, so the AI client will prompt the user for permission before the lookup call.

View saved version →

---
name: enrich-person
description: Look up a person's profile by name, email, phone, LinkedIn URL, NPI number, or name + employer. Returns their profile and verified contact info (emails, phones)
---

# Enrich Person

Take an identifier for a single person and return their RocketReach profile with contact info.

## Input

The user will provide at least one of these to identify the person:

- LinkedIn URL
- Name + current employer (both required together)
- Email address
- Phone number (resolved to a profile via person_search first — see step 2)
- NPI number (US healthcare professionals)
- RocketReach Profile ID

Examples:

- `/rocketreach:enrich-person www.linkedin.com/in/jamesgullbrand`
- `/rocketreach:enrich-person jamie@rocketreach.co`
- `/rocketreach:enrich-person +12076717456`
- `/rocketreach:enrich-person Jamie Gullbrand at RocketReach`
- `/rocketreach:enrich-person Jamie Gullbrand at www.rocketreach.co`

## Workflow

1. **Identify the person.** Pick the strongest identifier the user gave. A RocketReach profile ID, NPI, email, or LinkedIn URL resolves a single person directly; name + current employer usually does too. A **phone number is not a person_lookup identifier** — resolve it to a profile via person_search first (step 2). If they only gave a name, ask for the employer too, since name alone is ambiguous.
2. **Disambiguate / resolve to a profile (only if needed).** If the input is a phone number, a vague role, or a name without a deterministic identifier, call person_search with the parsed cues (phone, current_employer, name, current_title) and page_size: 5.

   Resolution rules:
   - Single result → mark auto-resolved, proceed to enrichment.
   - Top result high confidence (matches all input cues) → present the candidate to the user and proceed.
   - Multiple plausible candidates → present top 3 with name, title, current employer, location. Ask the user to pick. Mark ambiguous until picked.
   - Zero results → mark failed, ask the user for a more specific identifier.
3. **Pick the lookup type and confirm they have enough credits.** Depending on the user's plan, they will have one of the following types of credits. If the user has multiple active credit types, then we should confirm with the user which type should be used before continuing. The enrichment will consume 1 lookup credit (plus 1 person_export credit if issued on the user's plan; silently skipped if not issued).
   - Premium Credit - A or A- grade email or phone
   - Standard Credit - A or A- grade email only
   - Phone Credit - When a phone is returned
   - Enrich Credit - When the contact exists in our database
4. **Call person_lookup** with the resolved identifier and the lookup type. Preferred identifier order: RocketReach profile ID → NPI → email → LinkedIn URL → name + employer. A phone-based lookup uses the profile ID resolved in step 2.
5. **Handle pending lookups.** The lookup is asynchronous. If it returns `status: pending`, the contact is still resolving — tell the user results are still verifying and that final verified emails/phones will follow. Poll via check_person_status with the returned profile_id, respecting the response's retry_after_seconds hint (~3s between polls). check_person_status does not consume credits.
6. **Display Credit Cost.** Display if a credit was charged for the lookup. If the criteria below wasn't met, then we can say that no credit was used.
   - Premium Credit - A or A- grade email or phone
   - Standard Credit - A or A- grade email only
   - Phone Credit - When a phone is returned
   - Enrich Credit - When the contact exists in our database
7. **Format the contact card.** Use the output template below.

## Output

Lead with a header line, then present the returned fields below. Not every field is populated for every profile - show what is present. Only include contact data that is available based on the credit type used - Standard (contact data is limited to email only), Premium (emails + phones), Phone (emails + phones), Enrich (no contact data),

`[Name] -  [current_title] at [current_employer] · [location]`

| Field | Value |
| --- | --- |
| Name | [name] |
| Title | [current_title] |
| Employer | [current_employer] ([current_employer_domain]) |
| Location | [city], [region], [country] |
| LinkedIn | [linkedin_url] |
| Best Work Email | [recommended_professional_email] (grade) |
| Best Personal Email | [recommended_personal_email] (grade) |
| Best Phone | [the phone in phones[] marked recommended] (type) |
| Other Work Emails | [remaining professional emails from emails[], with grades] |
| Other Personal Emails | [remaining personal emails from emails[], with grades] |
| Other Phones | [remaining phones from phones[], with types] |
| Experience | [job_history[]: company, title, dates] |
| Education | [education[]: school, degree] |
| RocketReach ID | [id] |

Pick the "best" of each directly from the dedicated fields: Best Work Email = recommended_professional_email, Best Personal Email = recommended_personal_email, Best Phone = the entry in phones[] flagged recommended. List every other entry from emails[] (split by type: professional vs personal) and phones[] in the matching "Other" row. Each email in emails[] carries a type (professional / personal) and a grade - always show the email grade (A / A- / B).

## Next Steps

- `/rocketreach:enrich-company`: look up the contact's employer for firmographic detail.
- `/rocketreach:build-list`: find more people at the same company or in the same role.
- `/rocketreach:prospect`: build a ranked list of similar prospects.

## Notes

- **Asynchronous lookups.** Some lookups resolve immediately; others return pending and require polling via check_person_status. Typical resolution is a few seconds. The workflow handles both.
- **Credit asymmetry.** person_export is silently skipped if not issued on the user's plan — the lookup still succeeds, but the reported cost should reflect what was actually charged (1 lookup credit only in that case).
- **Healthcare data presence varies.** NPI, specialization, and credentials are populated only when the resolved person is in RocketReach's US healthcare data set. Their absence is not an error.
- **Host-level prompts.** The person_lookup tool is marked destructiveHint: true, so the AI client will prompt the user for permission before the lookup call. This is the per-call safety net; the skill should narrate it cleanly rather than try to suppress it.

View saved version →

---
name: prospect
description: Describe your ideal customer in plain English and get a ranked table of decision-makers with verified contact data
---

# Prospect

Turn a plain-English description of an ideal customer into a ranked list of decision-makers with verified contact info, in one flow.

This runs the full pipeline: search for the right people, rank them, then enrich the best ones. Use build-list instead if the user only wants to browse matches without spending credits.

## Input

The user describes their ideal customer in plain English.

- Title / management level / department - required (must include at least one)
- Industry - optional
- Company Size - optional
- Location - optional

If the description is too vague to search well, ask 1-2 quick questions to clarify further.

## Examples

- `/rocketreach:prospect VPs of Sales at Series B SaaS companies in the US`
- `/rocketreach:prospect Heads of Marketing at EU e-commerce companies with 100-500 employees`
- `/rocketreach:prospect CTOs at fintech startups in NYC`
- `/rocketreach:prospect Procurement directors at large manufacturers using SAP`
- `/rocketreach:prospect SDR leaders at companies using Salesforce and Outreach`

## Workflow

1. **Parse the ICP into search filters.** Use person_search to map to the fields outlined below
   - Job title → current_title
   - Management level → management_levels
   - Department → department
   - Location → location
   - Company Industry → company_industry
   - Company Size → company_size
2. **Check Credits available.** Call account once. Capture the user's lookup credit balance, person_export issuance, and daily API call limit. Compute the batch cost projection:
   - Default: 10 candidates enriched = 10 lookup credits (+ 10 person_export credits if issued).
   - If the projected cost would consume more than the user's available lookup credits, OR if the user is on a free plan, flag this and pause for explicit confirmation before proceeding.
3. **Discover Candidates.** Call person_search with the parsed filters. Defaults:
   - page_size: 25 (search broadly; enrich the top 10).
   - order_by: relevance.
4. **Preview Candidates.** Present the top 25 candidates as a preview table with name, title, company, location. Restate the credit cost:
   - Enriching the top 10 candidates will consume 10 lookup credits (+ 10 person_export credits if issued). Your current balance: [N] lookup credits available.
   - Reply with "go" to proceed, "show me more" to expand to 25, or specify a number to enrich (1–25).
   - Pause for confirmation. Do not consume credits before the user responds.
5. **Batch enrichment.** On confirmation, call person_lookup in parallel for the confirmed candidate set:
   - Batch size: ≤ 10 concurrent calls.
   - Track which calls return pending vs immediate complete data.
   - For pending results, batch the polling: call check_person_status with all pending profile_ids (up to 100 per call) every 3–5 seconds until all complete or a 60-second timeout. Surface any remaining unresolved at the end.
6. **Rank by ICP fit.** Score each result against the matched criteria:

   Matched Criteria to check:
   - Job title
   - Management level
   - Department
   - Location
   - Company Industry
   - Company Size

   Ranking:
   - Strong - if more than 75% of the input criteria matches
   - Good - if more than 50% of the input criteria matches
   - Partial - if more than 25% of the input criteria matches
7. **Format the output.** Use the output template below.

## Output

Leads matching: [ICP summary]

| # | Name | Title | Company | Best Work Email (grade) | Best Personal Email (Grade) | Best Phone | ICP Fit |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | | | | | | | Strong |
| 2 | | | | | | | Good |

Best Email = recommended_professional_email (or recommended_personal_email if no work email), Best Phone = the phones[] entry flagged recommended.

Summary: Found X matches, enriched top Y. Z credits used ([type]).

## Next actions

- `/rocketreach:enrich-person` - drill into one of the resulting leads.
- `/rocketreach:healthcare-prospect` - when the ICP is healthcare-shaped.
- `/rocketreach:enrich-company` - look up one of the employer companies in detail.
- `/rocketreach:build-list` -  for a search-only pass before committing to enrichment credits.

## Notes

- **Host-level prompts during batch.** Each person_lookup call may trigger a per-call permission prompt in the user's AI client (the lookup tools are destructiveHint: true). Most hosts offer an "allow for this session" affordance after the first prompt; surface this in the first prompt's narration if the host supports it.
- **person_export asymmetry.** Plans without person_export credits issued will see the lookup succeed but the export credit silently skipped. The reported cost should reflect what was actually charged.
- **Pending lookups.** Some lookups take longer than a few seconds to resolve. The batched polling pattern handles this; if any remain unresolved after 60 seconds, surface them as pending in the summary so the user knows to check back.
- **Search-result quality varies by ICP specificity.** Very broad ICPs ("any executive") will produce many low-fit candidates; very narrow ICPs may return < 10 candidates. Iteration Options should propose concrete refinements based on the actual result distribution.