/lead-generation

name: lead-generation
description: >-
  Source, qualify, enrich, and research a B2B lead list from an Ideal Customer Profile, end to end.
  Use this skill whenever the user wants to "find leads", "source prospects", "build a lead list",
  "get me leads for [ICP]", "scrape leads", "find companies that match", "build a prospect list",
  "/lead-gen", or describes who they sell to and wants a contactable, qualified list back. It picks the
  right data source for the ICP (Google Maps for local businesses, Sales Navigator or LinkedIn scrapers
  for B2B roles, a prospecting database otherwise), confirms the tools are connected, sources at the
  right volume, qualifies every lead with parallel subagents, enriches and verifies contact data
  (email + phone), runs deep per-lead research, and delivers a clean CSV or Google Sheet. Trigger it
  even when the user does not name a tool, as long as they want leads that match a profile. The output
  feeds the `outreach` skill.
disable-model-invocation: true

Lead Generation

Turn an Ideal Customer Profile into a clean, qualified, enriched, contactable lead list. This skill is the front of the outbound machine: it decides where the right prospects live, pulls them, proves each one actually fits, finds and verifies their contact details, researches them deeply enough to personalize later, and hands a finished list to `outreach`.

The whole point is that a lead list is only as good as the worst decision in it. A great scraper pointed at the wrong source, or a clean list nobody verified, both waste the campaign. So this skill is opinionated about sequence: resolve the ICP, route to the source that actually holds that ICP, confirm the tools work before spending money, then source → qualify → enrich → research → deliver.

The flow

0. Resolve the ICP        who, offer, where they live, how many, seniority, criteria
1. Route to the source    Maps vs Sales Nav/LinkedIn vs prospecting DB vs niche   -> references/source-routing.md
2. Preflight              confirm the chosen source + enrichment tools are connected -> references/connectors.md
3. Source                 keyword parse, test batch, pass-rate, volume, full pull  -> references/volume-and-batching.md
4. Qualify                parallel lead-qualifier subagents, 10 leads each
5. Enrich + verify        find + verify email and phone, only verified move on     -> references/enrichment.md
6. Research               parallel lead-researcher subagents, 5 each, depth by source
7. Deliver                CSV always, Google Sheet if gws is available

Read the referenced file when you reach that phase. The SKILL body is the map; the references hold the exact actor IDs, schemas, recovery patterns, and math.

Two operating modes

This skill runs both inside the BenAI Sales OS vault and standalone for any client. Detect which at the start and behave accordingly.

• **Sales OS / vault mode.** A `Context/config.md` (and `Context/icp.md`, `offer.md`) exists in or above the working directory, or the user is clearly working inside the Sales OS. Read those docs as ground truth instead of interviewing. This skill is **Hybrid**: it delivers a list (action) AND updates what the OS knows (brain). So it writes a campaign record under `Lead-Gen/campaigns/<name>/` and logs every file it touches to `Daily/logs/YYYY-MM-DD.md`. Wikilink every entity. Never use em dashes.
• **Standalone / client mode.** No Sales OS context present. Interview the user for the same fields (Phase 0), deliver the list plus a short run summary, and skip the vault logging. This is the default for a fresh client install. The master-guide onboarder, when present, will have written the client's own `Context/` docs; if so, prefer reading them over interviewing.

If you are unsure which mode you are in, ask once: "Are we working inside your Sales OS vault, or is this a standalone list build?"

Phase 0: Resolve the ICP

Lock these six things before sourcing anything. In vault/client-context mode, read them from `Context/icp.md`, `Context/offer.md`, and `Context/config.md`. Otherwise ask, concisely, in one or two grouped questions.

1. **The offer.** What is being sold, and why would these leads care. This propagates to every later phase: researchers focus on signals relevant to it, and `outreach` ties every line back to it. 2. **Who the ICP is (company level).** Industry/vertical, company size band, geography, and any hard disqualifiers. 3. **Where the ICP resides.** This is the single most important routing input. A plumber lives on Google Maps; a marketing-agency founder lives on LinkedIn; a SaaS RevOps lead lives in a prospecting database. See `references/source-routing.md`. 4. **How many leads.** The target count. Drives the volume math (sourcing over-pulls to survive qualification) and the subagent counts. 5. **The individual-level ICP.** The decision-maker tier (C-suite, VP, director, manager) and the exact designations to target (e.g. "Founder / CEO / Owner", or "Head of Marketing / Marketing Director"). This becomes a seniority+title filter at the source and a check at qualification. 6. **Qualification criteria.** The concrete, testable rules a lead must pass. If the user does not supply them, derive them from the ICP and the offer, then show the derived criteria and the AND/OR logic for a quick confirm. Vague criteria produce a vague list.

Confirm the six back in two or three lines before moving on. Sourcing spends money; a 20-second confirm is cheap insurance.

Phase 1: Route to the source

Pick the data source from where the ICP resides. The full decision tree, with exact Apify actor IDs, data-richness notes, and the downstream research-depth rule for each source, is in **`references/source-routing.md`**. Read it now. The short version:

| ICP lives on... | Primary source | Data richness | What's missing | | --- | --- | --- | --- | | Local / brick-and-mortar (Google Maps) | Apify Google Maps scraper | Thin (name, site, phone,