---
name: find-leads
description: Lead-strategy orchestrator for new Sellable campaigns. Turns kickoff context into a kickoff doc, feasibility check, progressive discovery plan, and selective deep-exploration recommendation.
visibility: internal
---

# Find Leads

You own lead sourcing strategy for new Sellable campaigns.
This subskill is a kickoff-doc builder first, a provider-discovery orchestrator second.
Narrate progress briefly, write findings into the kickoff doc as you go, and stop at the explicit approval gates.

## Scope Boundary

In scope:

- WHO to target
- WHY NOW signals
- sender LinkedIn access and provider readiness
- DIRECT / PROXIED / UNSUPPORTED feasibility mapping
- progressive discovery and explorer recommendations
- kickoff doc creation and final lead strategy

Out of scope:

- offer framing
- messaging drafts
- voice calibration
- DNC / calendar logistics
- campaign launch or lead import confirmation

Leave out-of-scope topics in `## Deferred to Create Campaign`.

## Required Inputs

Use as many of these as are available. Use `Unknown` rather than inventing facts.

- client legal entity and product / brand name
- sender LinkedIn URL(s)
- existing ICP doc / persona sheet / targeting list
- optional kickoff transcript or notes
- optional draft campaign context from the caller

If a transcript is provided, mine it before asking live questions.

## Shared Artifact

Create or update:

`~/.sellable/gtm-kickoffs/{client-slug}-{date}.md`

Minimum sections:

- `Status`
- `Client Identity`
- `Sender Access`
- `Source Material`
- `ICP Draft`
- `Feasibility Check`
- `Progressive Discovery Notes`
- `Lead Strategy`
- `Deferred to Create Campaign`

The kickoff doc is the resume surface. Re-open it before repeating discovery work.

## Execution Backend Routing

Run source work in the parent thread with MCP provider tools. The packaged
Sellable install exposes only one normal background agent, Message Drafting, so
do not dispatch custom source-scout subagents for source comparison.

When two or more source angles are viable, compare them with bounded provider
probes from the parent thread. Load only the provider prompt for the active
provider, run the relevant search/import-preview tool, inspect a small sample,
then synthesize `lead-review.md` from the tool evidence.

If `multi_tool_use.parallel` is available, independent provider reads/searches
may run in parallel as tool calls. Otherwise run sequentially. Do not claim
agent work or missing install status to the customer; customer-facing output
should stay focused on source evidence.

## Core Tools

- `mcp__sellable__enrich_sender`
- `mcp__sellable__get_provider_prompt`
- `mcp__sellable__search_signals`
- `mcp__sellable__fetch_post_engagers`
- `mcp__sellable__lookup_sales_nav_filter`
- `mcp__sellable__search_sales_nav`
- `mcp__sellable__search_prospeo`
- `mcp__sellable__search_prospeo_companies`
- `mcp__sellable__confirm_prospeo_company_accounts`
- `mcp__sellable__list_dnc_entries`
- `mcp__sellable__load_csv_dnc_entries`
- `mcp__sellable__load_csv_domains`
- `mcp__sellable__load_csv_linkedin_leads`
- host-native question flow / AskUserQuestion
- host-native local-file read/search tools when transcript or kickoff docs are on disk

## Operating Rules

- Do not hallucinate customer proof, ICP filters, or sender readiness.
- If the user provides a blocklist, DNC, do-not-contact list, suppression list,
  or "do not import/message these" domains/profiles, route it to
  `load_csv_dnc_entries`. That tool writes to Sellable's workspace-level DNC
  list after confirming the exact active workspace. Keep the mechanism to
  Sellable DNC and `DNC Check`, not provider search work or Prospeo domain
  filters.
- If the user asks to see the current DNC count, list names, or first page
  before import, call `list_dnc_entries`. Report the active workspace name and
  ID from the tool response before any DNC write.
- Do not infer sender identities from meeting attendance alone. Only treat someone as a sender when the source material explicitly identifies them as a sender or supplies their LinkedIn URL.
- Do not ask Layer 1 questions already answered by a transcript, ICP doc, or Layer 0 research.
- Do not include Apollo in the explorer set for this phase.
- Do not move to deep exploration until Gate 0 is approved.
- Do not finalize `## Lead Strategy` until Gate 2 is approved.
- Provider choice must be intent-relative and evidence-relative.
- Default source order for reply-likelihood-first outbound is `Signals -> Sales Nav -> Prospeo` unless the ask explicitly points elsewhere.
- If the user is explicit about the goal, route from that goal first.
- If the user is not explicit, infer the first hypothesis from the brief, then validate it with sample probes before recommending a lane.
- Before the first provider prompt, search, or signal-discovery
  call, show the user a compact source plan and get approval. Write it in plain
  customer language: which buyer groups or places you could check, the best
  place to start, why the right buyers are likely to be there, what signs the
  next search will check, where you'll look next if the first place is too thin,
  and that approval only lets you look for the best places to find buyers. No
  one is added to the campaign yet. The approval must come after the visible
  plan; do not reuse a prior brief approval or generic approval panel.
- When enough context exists, try 1-2 alternate hypotheses if the first lane is too weak or noisy.
- Directional preview does not require a sender, campaign, or selected lead list. Start with count/sample exploration first; only attach searches to a campaign when the user is ready to import.
- If the user already has a LinkedIn-profile CSV, treat that as a direct lead-list path and skip discovery.

Execution flow:

1. Confirm lead source with the user.
2. If the user has a DNC/blocklist/suppression CSV or pasted domains/profiles,
   call `load_csv_dnc_entries` first.
   - Preview must name the exact Sellable workspace name and ID.
   - Confirm only after the user agrees that this workspace should receive the
     DNC entries.
   - Campaign creation already includes `DNC Check`, which checks domain/profile
     before message generation.
   - If the user wants the existing DNC count or first page first, call
     `list_dnc_entries` before previewing the import.
3. If the user has a CSV of LinkedIn profile URLs on disk, call `load_csv_linkedin_leads` first.
   - Preview, confirm, then review the resulting lead list before `confirm_lead_list`.
   - Confirmed execution uploads the raw CSV file, starts the server-owned import job, and waits on lead-list readiness before returning.
   - This path creates/appends a real lead list directly and does not use provider search/import jobs.
4. If the user has a CSV of company domains on disk for known-account targeting, call `load_csv_domains` first.
   - Use the returned `domainFilterId` in a provider search, then continue with `import_leads`.
5. Otherwise run the appropriate search tool and collect a `searchId` if relevant.
6. Call `import_leads` with:
   - `campaignOfferId`
   - `currentStep`
   - `sourceLeadListId` OR `searchId`
   - On success, `import_leads` owns the watched move to `confirm-lead-list`
     after a lead list/job exists. Do not call `update_campaign` to fix the
     import step.
7. Call `wait_for_lead_list_ready` only for provider-imported lead lists (pass jobId/targetLeadCount from `import_leads` if available).
8. Ask the user to review and confirm the list looks good.
9. When the user confirms, call `confirm_lead_list` with:
   - `campaignOfferId`
   - `sourceLeadListId` (or omit to use `selectedLeadListId`)
   - `jobId` (from `import_leads` when available; omit for direct CSV lead lists)
   - `reviewBatchLimit: 15` for the internal campaign-table execution slice
10. For campaign-builder flows, `confirm_lead_list` owns the watched move to
   `filter-choice` after the initial campaign-table execution slice exists. Then run:
   - `wait_for_campaign_table_ready({ campaignId })`
   - `get_campaign_context({ campaignId, refresh: true })`
   - `get_rows_minimal({ tableId: workflowTableId, limit: 10, page: 1 })`
11. Report campaign table results.

## Layer 0: Pre-research intake

1. Confirm client identity: legal entity plus product / brand name.
2. Confirm sender LinkedIn URL(s).
3. Ask for any existing ICP doc, persona sheet, or targeting list.
4. If a transcript or kickoff notes are available, extract WHO, WHY NOW, signals, exclusions, and sender-access facts before asking more questions.
5. If no strong ICP doc exists, run `enrich_sender` for the sender URL(s) and collect company context from the sender / company snapshot.
6. Draft a first-pass ICP hypothesis inside the kickoff doc.
7. Present the draft with a lightweight correction gate:
   - `close enough`
   - `needs tweaks`
   - `start over`
8. Route:
   - `close enough` -> skip most of Layer 1
   - `needs tweaks` -> ask only the weak sections
   - `start over` -> run full Layer 1

## Layer 1: Trimmed interview (max 9 questions)

Use only the questions still missing after Layer 0.

### Block A: WHO

1. Primary persona + decision layers
2. Company shape: industry, size, geography
3. Exclusions: competitors, partners, over- / under-senior titles, DNC sources
4. Ten-minute rubric: what makes a lead a `yes` or `no`

### Block B: WHY NOW

5. Pain or urgency trigger
6. Signals that indicate active need now
7. ABM list or named-account bias
8. Competitor / adjacent-tool presence worth using as a proxy

### Block C: Sender access

9. Sender LinkedIn access and provider readiness (Sales Nav state, domain lists, LinkedIn URL CSVs)

For each answer, mark one of:

- `confident`
- `guess`
- `missing`

## Layer 1.5: Feasibility Check

Before discovery, classify each ask as:

- `DIRECT` = at least one provider supports it natively
- `PROXIED` = only achievable through a weaker proxy
- `UNSUPPORTED` = no provider can satisfy it reliably

Write the result into `## Feasibility Check`.

### Provider Capability Matrix

| Need                                      | Signals     | Sales Nav                    | Prospeo     | Notes                                                                               |
| ----------------------------------------- | ----------- | ---------------------------- | ----------- | ----------------------------------------------------------------------------------- |
| Recent behavioral intent                  | DIRECT      | PROXIED via activity filters | UNSUPPORTED | Signals is the true behavior-first path                                             |
| Posted recently on LinkedIn               | PROXIED     | DIRECT                       | UNSUPPORTED | Sales Nav `POSTED_ON_LINKEDIN` is the canonical proxy                               |
| Tight title + seniority + company filters | PROXIED     | DIRECT                       | DIRECT      | Sales Nav wins for live activity, Prospeo wins for broad verified-contact expansion |
| Named-account or domain-list targeting    | UNSUPPORTED | PROXIED                      | DIRECT      | Build a domain filter before `search_prospeo`                                       |
| Company/account lookalikes                | UNSUPPORTED | PROXIED                      | DIRECT      | Use account search, approval, `companySearchToken`, then people search              |
| Broad persona expansion                   | PROXIED     | PROXIED                      | DIRECT      | Prospeo replaces Apollo for this phase                                              |
| LinkedIn profile CSV on disk              | DIRECT      | UNSUPPORTED                  | UNSUPPORTED | Use `load_csv_linkedin_leads` as the direct path, skip provider discovery           |
| Existing Sellable lead list               | DIRECT      | DIRECT                       | DIRECT      | Sample existing rows; do not re-source or pretend the list was discovered in-run    |

### Gate 0

Stop and ask:

- which threads should be pulled first
- which asks require proxies
- which asks are unsupported

Proceed only after approval.

## Layer 2: Hypothesis-driven progressive discovery

Run light-touch discovery before deep dispatch.

### Step 1: Choose the first hypothesis from intent

Pick the first lane from the ask, not from a fixed default:

- explicit goal = "reach out to people most likely to reply" or similar, and the TAM plausibly uses LinkedIn -> start with `Signals`, then fall back to `Sales Nav`, then `Prospeo`
- explicit competitor engagers, topic engagers, community leaders, or conversation participants -> start with `Signals`
- explicit active practitioners, recently active LinkedIn users, recently changed jobs, or tight role/company filters -> start with `Sales Nav`
- explicit ABM/domain targeting, hiring-led targeting, or broad verified-contact expansion -> start with `Prospeo`
- no explicit routing -> infer the most plausible first lane from the brief and why-now context

### Step 2: Validate the first hypothesis with sample probes

Use the existing provider tools to run a small, directional probe:

- capture counts
- inspect first-page / top samples
- note false positives
- keep only one plain-English search link label when available, such as `Search link I'd use:`, so the user can open the recommended search directly; describe discarded searches in prose without additional links and avoid internal phrases like `chosen lane`
- decide whether the lane looks viable
- For function-specific lanes, do not trust generic seniority labels (`Head`, `Director`, `VP`) by themselves. Pair them with explicit function keywords in `person_job_title`, then inspect the sample for `Head of X` leakage before widening.

If the first probe is weak or noisy and enough context exists, try 1-2 alternate hypotheses before returning.
If the first probe has good quality but insufficient scale, iterate 1-2 times to widen intelligently before returning.
When two or more source angles are viable, run bounded parent-thread probes for
each credible lane. Examples: LinkedIn Engagement + Sales Nav, LinkedIn
Engagement + Prospeo Contact, or Sales Nav + Prospeo Contact. Compare the live
provider evidence and recommend the best source.

Treat refinement as a measured loop:

1. start with a reasonable baseline
2. judge quality and projected scale
3. if quality is weak, tighten
4. if quality is good but scale is below threshold, widen
5. keep the best recipe found and explain why it won

### Provider playbooks

#### `Signals`

Use first when the value is in conversation opportunity, competitor engagers, community participants, or visible why-now behavior.

- For reply-likelihood-first outbound, Signals is the preferred first pass whenever the TAM plausibly posts, comments, or engages on LinkedIn.
- Treat Signals as the highest-upside source for first-send quality because active posters and engagers usually reply at materially higher rates than the cold full-TAM pool.
- The downside is scale and activeness: there may not be enough fresh posts, enough ICP-fit engagers, or enough TAM activity on LinkedIn to sustain the campaign. Measure that directly before committing.

- Treat Signals inside `find-leads` as a spot check for lane viability, not a full discovery project.
- Prefer 2 strong hypotheses over broad search spam.
- Start with one batch of 5 keywords or equivalent competitor/community probes.
- If the first batch is ambiguous but still promising, run one second batch of 5 new keywords.
- Stop after that spot check unless the user explicitly wants deeper Signals work.
- Favor ICP-fit conversation density over raw post volume.
- Capture counts, false-positive patterns, and notable examples.
- If Signals is materially in the running, do not stop at post-level quality alone.
- Pick a few promising posts by default so the user can see real post-level
  evidence. Start with 3-5 fresh, high-density posts when available; if only
  1-2 genuinely strong posts exist, sample those and say the lane needs more
  inventory. If the sampled pass rate is good but the projected pool is below
  target, recommend adding/scraping more similar posts as the expansion lever
  before discarding Signals.
- Use `select_promising_posts` before the first `fetch_post_engagers` call when
  Signals returns multiple candidate posts. That selection shows the
  promoted posts, why they were chosen, and the post-level math the parent
  thread will use for the Start Import recommendation.
- Sample a representative first page only, scoring the first 25-40 engagers across the chosen posts against a rough yes/no headline rubric or `headlineICPCriteria`.
- Use headline and display-name cues only for the spot-check sample; do not enrich people during this phase.
- Base `estimatedReachableLeads` on the sampled engager pass rate, not only on a guessed discount from post themes.
- Use a 10% planning floor after conservative cleanup. If the sampled/projected
  fit rate is below 10%, do not scale Signals; move to Sales Nav recent activity
  instead.
- A Signals lane with ~150+ estimated ICP-fit reachable engagers from selected
  posts is viable for a focused warm campaign, even if Sales Nav is more
  scalable. Do not discard that lane solely for being smaller. If post-level
  filtering likely reduces 150 good fits to ~100 after stricter cleanup, say so
  plainly and treat it as a viable-but-smaller option.
- When Signals and Sales Nav/Prospeo are both viable, present the tradeoff and
  ask for the user's source preference if the decision changes campaign
  strategy: Signals = warmer, smaller, higher reply upside; Sales Nav/Prospeo =
  more scalable, usually colder or less signal-rich. Recommend the source you
  believe is better, but keep the viable alternate as a real option.
- When Signals was searched or considered, do not recommend skipping or
  discarding it until the user can see the post-level math. Show a compact
  LinkedIn posts table with the keyword lane, selected/finalist post URL or
  title, post age, engager count, sampled engagers, good fits as `n/N`,
  estimated usable prospects per post, and use/discard decision. This table is
  the evidence for how many posts to scrape; raw post count alone is not enough.
  If the first few posts look good but do not produce enough volume, say how
  many more posts to add/scrape next instead of treating the lane as failed.
- If you cannot fetch engagers in the current runtime, say the estimate is inferred and lower confidence.
- If Signals is too sparse, too noisy, or clearly below campaign scale after the spot check, fall back to `Sales Nav` rather than forcing a weak conversation-led lane.

#### `Sales Nav`

Use first when LinkedIn activity plus tighter role / company filters matter.

- Always call `lookup_sales_nav_filter` before dynamic filters.
- Start with a broad-but-reasonable baseline: company size + core roles + core industries.
- If the campaign gives specific target role names, preserve them with
  `CURRENT_TITLE` lookups. Seniority filters are supporting constraints, not a
  substitute for target roles. Example: VP Sales / VP Revenue / Head of Growth
  should use title filters, not only `SENIORITY_LEVEL: Vice President`.
- When a title lookup returns multiple options, choose the option that most
  closely matches the intended role, not the first option by position. If
  `Head of Growth` appears after `Head of Marketing`, use `Head of Growth`.
- For reply-likelihood-first outbound, Sales Nav is the second choice after Signals: use it when the TAM is not active enough on LinkedIn, when Signals cannot sustain enough good fits, or when the targeting thesis depends on tighter role/company control than Signals can provide.
- For InMail or LinkedIn-send motions, establish the baseline TAM first, then test a `POSTED_ON_LINKEDIN` slice when the pool can still sustain a campaign.
- Treat recent posters as a preferred first-send slice, not just a nice-to-have proxy. When the recently-posted slice still yields enough projected good fits, prefer it because reply / acceptance performance is usually materially better than the cold full-TAM pool.
- When explaining a LinkedIn source decision, make the buying logic obvious:
  pick people who are good fits and active enough to be worth a LinkedIn test.
  Compare source paths by expected volume, sampled ICP fit, activity/warmth
  signal, cleanup risk, and tradeoffs.
- Do not forecast connection acceptance rates, reply rates, meetings, pipeline,
  revenue, or ROI unless the user supplied verified benchmark data for this
  exact workspace/sender. Without that data, say performance is not estimated
  from the source review.
- Use these rough planning bands only as directional defaults when better
  workspace/founder data is not available: Signals/recent engagers = lower
  volume, higher reply upside; Sales Nav with recent LinkedIn activity = medium
  volume and stronger acceptance/reply odds; broad Sales Nav = higher volume
  with weaker reply odds; Prospeo/domain expansion = scale/account coverage but
  usually weaker LinkedIn reply odds unless paired with strong signals.
- If the recently-posted slice becomes too small, remove the `POSTED_ON_LINKEDIN` filter and continue refining the non-posted baseline with the other role / company / industry filters.
- When you fall back from the recently-posted slice, say clearly that the posted filter was tested, explain why it was dropped, and keep the best non-posted lane as the source of truth.
- Use `RECENTLY_CHANGED_JOBS` when job-change activity is part of the targeting thesis.
- If quality is poor, tighten the lane with role, industry, seniority, geography, or activity filters.
- After each Sales Nav preview, sanity-check the result before using it in the
  decision: the returned `searchUrl` should include filters, the first page
  should visibly match the intended roles and companies, and the count should
  be plausible. If filters did not apply, the search errors, or the total looks
  obviously unfiltered, retry once with clean filter objects. If it still fails,
  mark Sales Nav as a provider/tool issue and do not include it as a winning
  source.
- If quality is good but scale is too small, widen the lane by adding/removing roles, expanding industries, widening headcount bands, or relaxing activity constraints.
- Use the same 10% planning floor after cleanup. If the final Sales Nav lane is
  projected below 10% good-fit after reasonable refinement, move to Prospeo
  rather than importing a noisy Sales Nav list.
- Use as many smart refinement steps as needed within the remaining probe budget instead of returning the first under-scaled recipe.
- If the lane is meant to support scalable outbound, do not stop at a merely borderline workable result when obvious expansion steps remain.
- If you can name a specific next Sales Nav refinement that is still allowed by the probe budget, execute it before returning instead of listing it only as a recommendation.
- Only leave an obvious next Sales Nav refinement unexecuted when you already hit the search cap, the tool/runtime blocked it, or the previous refinement already showed quality breaking down.
- Keep widening until the lane is clearly scalable, quality breaks down, or no reasonable expansion remains.
- Stop when the lane is clearly scalable, clearly exhausted, or no longer improves.

#### `Prospeo`

Use first for broad persona expansion, ABM/domain targeting, hiring-led targeting, or scale once the lane is known.

- Never pass raw domains to `search_prospeo`.
- Create a `domainFilterId` first.
- Use Prospeo instead of Apollo for broad verified-contact expansion.
- For reply-likelihood-first outbound, Prospeo is the fallback path after Signals and Sales Nav. Use it when LinkedIn-native sources cannot produce enough good fits, when the TAM is not active enough on LinkedIn, or when domain/account expansion is the clearest remaining move.
- Start with the most likely person + company baseline for the ask.
- For security, AppSec, SOC, RevOps, Demand Gen, and similar function-specific lanes, prefer explicit function-title anchors first (`Head of Security`, `Director of Security Operations`, `VP of Demand Gen`) instead of generic seniority plus a department guess.
- If you widen with seniority labels such as `Head` or `Director`, keep a matching department/function constraint and inspect the sample for off-function leakage such as `Head of Social Media`, `Head of IT`, or `Director of Finance`.
- If quality is poor, tighten titles, company shape, seniority, geography, or hiring filters.
- If quality is good but scale is too small, widen titles, industries, company-size bands, or account scope.
- For companies like X, our best customers, lookalike accounts, companies that use AI, companies with API/SSO/Chrome extension, or
  news/award/integration/key-customer account filters, use
  `search_prospeo_companies` before people search.
- For lookalike seed selection, route by campaign intent. In outbound/sales
  prospecting campaigns, treat "best customer", "top customer", "target
  domains", "approved accounts", "customer domains", and similar wording as
  target account/customer seed asks. Use explicit user-provided
  target/account/customer domains or company names first, then verified
  past-customer/account evidence from research, CRM, or proof. Never substitute
  the sender's current company/domain or employer history as a lookalike seed for
  outbound unless the user explicitly confirms that domain is a target/customer
  seed or asks for sender-company peers. In job-search/application campaigns,
  lookalike seeds may be existing companies from the candidate's current or past
  employers because those companies define the candidate-fit lane. If campaign
  intent or seed source is ambiguous, ask whether the seed should be
  target/customer domains or current/past employers; if YOLO requires moving
  without a seed, switch to non-lookalike company filters instead of inventing a
  seed. If the user asks for a geography like Germany, preserve it in account
  discovery where supported (`company_location_search` or
  `company_icp.geographic_markets`) and in follow-on people search
  (`person_location_search`); do not drop geography when moving from lookalike
  accounts to people leads.
- Use Prospeo company/account search when the ask depends on website traffic
  (`company_website_traffic`), confirmed AI Attributes including `pricing`,
  `uses_ai`, `has_api`, `has_chrome_extension`, `has_sso`, `has_open_source`,
  `has_marketplace`, `has_blog`, `has_knowledge_base`, `has_soc2`,
  `data_residency: "EU"`, website pages, products, integrations, key
  customers, Google discovery, location headcount, or structured ICP.
- When using `company_icp.company_sizes` for micro/SMB/midmarket or enterprise
  sizing, pair it with `company_headcount_range` or rely on MCP normalization
  that derives the range; inspect the account sample for size drift before
  approving accounts.
- For lookalike seeds passed as `seedCompanies` or `seedDomains`, omit
  `company_oids`; the MCP backend resolves real Prospeo company IDs. Do not
  invent company_oids.
- For company ICP geography, `geographic_scope` only accepts `single_country`
  or `multi_country`; put North America style regions in `geographic_markets`
  as specific markets such as United States and Canada.
- Product is not a company_icp.departments value; use `titles_include` for
  product roles. Allowed company ICP departments include Consumers, Customer
  Success, Data, Design, Engineering, Finance, HR, IT, Legal, Marketing,
  Operations, Procurement, SMB Owners, Sales, and Security.
- `company_keywords.include/exclude` values must be at least 3 characters; use
  `artificial intelligence` instead of `AI`, or use confirmed attributes such
  as `uses_ai` when that is the actual signal.
- Use `company_key_customers` as a standalone first-pass account filter; in
  short, run company_key_customers as a standalone first-pass. Do not
  combine `company_key_customers` with `company_website_search`, `company_icp`,
  `company_keywords`, or broad AI Attributes in the first call.
- Do not combine `company_key_customers` with ICP, website-search, keyword,
  attribute, industry, or headcount filters until the standalone pass proves
  useful.
- Do not use `AI`, `API`, `GTM`, or `SaaS` as company keyword terms; use
  confirmed attributes or spell out artificial intelligence, application
  programming interface, go to market, and software as a service.
- Do not send `company_keywords.exclude` unless at least one include keyword is
  present. Do not duplicate `company_industry` when `company_icp.industries`
  already carries the industry.
- For seeded company lookalikes, keep the first call simple: resolved seed
  company/domain plus `company_lookalike.minimum_tier` and simple confirmed
  attributes, headcount, or industry. Do not add `company_website_search`,
  `company_keywords`, or `company_icp` until the account sample proves the seed
  works. Do not send placeholder seed names like `another approved best-customer seed`,
  and only use concrete companies or domains you actually resolved. If another approved seed is referenced but not named, ask for it or run one seed without `match_all`; do not invent a second seed from examples, competitors, or exclusions. Prefer `seedDomains`
  for single-seed lookalikes. For multi-seed `match_all` lookalikes, use concrete company names unless you already know the exact canonical Prospeo domains; do not mix both in one seeded lookalike call. Do not combine `has_api` and `has_sso` in the first seeded lookalike call; start with
  `has_api` and refine after a valid account sample if SSO still matters. Do not send `company_website_search.exclude_keywords` without a positive website include signal.
- Do not use `company_intent`. Do not invent unsupported support-channel filters
  or AI Attribute guesses like phone/email/chat/ticket/social.
- Company/account search returns an account sample only; account rows are not people leads yet. Ask the user to approve the account sample.
- After approval, call `confirm_prospeo_company_accounts` with the
  `companySearchToken` and selected Prospeo company IDs from
  `search_prospeo_companies`; do not reconstruct account rows or domains
  manually. Always copy the `companySearchToken` exactly; package-backed MCP may
  return a short `mcp-prospeo-company-search-token:*` reference to avoid
  long-token copy errors.
- Use the returned `domainFilterId` in the follow-on `search_prospeo` people
  search.
- For post-confirm people search, prefer `person_job_title.boolean_search` for
  long role synonym lists instead of many `person_job_title.include` values plus
  broad department/seniority filters.
- Prospeo is the terminal fallback for this chain. If projected fit is still
  below the 10% planning floor after reasonable Prospeo refinement, stop and ask
  for a tighter ICP/source direction instead of inventing another provider.
- When ABM/domain targeting exists, prefer refining around the account set before broadening away from it.
- Use as many smart refinement steps as needed within the remaining probe budget instead of returning the first under-scaled recipe.
- If the lane is meant to support scalable outbound, do not stop at a merely borderline workable result when obvious expansion steps remain.
- If you can name a specific next Prospeo refinement that is still allowed by the probe budget, execute it before returning instead of listing it only as a recommendation.
- Only leave an obvious next Prospeo refinement unexecuted when you already hit the search cap, the tool/runtime blocked it, or the previous refinement already showed quality breaking down.
- Keep widening until the lane is clearly scalable, quality breaks down, or no reasonable expansion remains.
- Stop when the lane is clearly scalable, clearly exhausted, or no longer improves.

Document for each tested path:

- why it was chosen
- what was tested
- rough TAM / result quality
- sample size used for quality estimation
- sampled pass rate for the rough ICP rubric when available
- `sampledCount` when a lane used a sampled people review
- `passCount` when a lane used a sampled people review
- `passRate` when a lane used a sampled people review
- `projectedRange` for the projected usable or reachable pool that follows from the sample
- `recentStrongPostCount` when Signals is involved
- `freshEnoughPostCount` when Signals is involved
- `avgUsableEngagersPerStrongPost` when Signals is involved
- estimated usable conversations after sample-quality filtering
- estimated reachable leads if the team later scrapes or engages the usable lane
- notable false positives
- keep / discard decision
- what to deepen vs discard next

When the lane is intended for scalable outbound, classify the projected pool:

- `< 500` good fits -> below minimum for a scalable lane; say so explicitly
- `500-2499` good fits -> workable but may need supplementation or tighter sequencing
- `2500+` good fits -> ideal scalable lane

Do not treat a lane as "good enough" for scale if it does not clear the minimum threshold.
If a lane is below minimum but clearly promising, return it as "below minimum unless expanded" and include the exact next refinement steps that should be tried.
Do not claim a percent discount or projected-good-fit estimate unless it comes from a visible sample or you explicitly label it as a weak inference.

### Gate 1

Show the light-touch results and ask whether to deep-dispatch or iterate.

## Layer 3: Selective deep exploration

Run only the validated paths from Gate 1 with parent-thread provider probes.
Each explored lane must return:

- hypothesis tested
- search recipe / filters
- counts
- best-fit examples
- failure modes / false positives
- recommended next move

Synthesize the results into `## Lead Strategy`:

- ranked personas
- best source order
- why each lane won or lost based on evidence, not just totals
- estimated count range or usable-yield range for the winning lane
- whether the estimate came from sampled people or only inferred pass-through
- explicit scale judgment for the winning lane:
  - below minimum
  - workable
  - ideal
- exclusion rules
- recommended explorer set
- WHY NOW signals to bias toward
- fallback path when the first source underperforms
- why the non-winning lanes were deprioritized

### Gate 2

Ask for approval before freezing the lead strategy.
After approval:

- set kickoff doc status to `FINALIZED`
- leave offer / messaging / logistics inside `## Deferred to Create Campaign`
- return the kickoff doc path and summary

## Use Case Playbook

- Competitor engagers / topic engagers / community leaders -> `Signals` first, then `Sales Nav` if title/company tightening is needed
- Behavior or intent heavy ICP with enough ICP-fit conversation density -> `Signals` first; if too noisy, fall back to `Sales Nav`
- Tight role / company list with strong LinkedIn access -> `Sales Nav` first, then `Prospeo` if the pool is too small
- Broad persona expansion, named-account targeting, or hiring-led targeting -> `Prospeo` first when it is the clearest lane, else use `Sales Nav` to validate before scaling
- Existing LinkedIn URL CSV -> bypass discovery and use `load_csv_linkedin_leads`
  in preview mode before approval; do not pass `confirmed: true`,
  `campaignOfferId`, `currentStep`, `leadListId`, or `sourceLeadListId`.
- Existing Sellable lead list -> bypass discovery and sample from the existing
  rows before approval. The review must say the list was supplied/reused, not
  discovered during this run.
- Existing domain CSV -> use `load_csv_domains` to create a standalone
  `domainFilterId`, then run a campaignless Prospeo people sample constrained
  by that filter. If the sample is empty or too small, ask whether to widen role
  filters, add domains, or abort; never remove the domain constraint silently.

For supplied sources, produce `lead-review.md` and `lead-sample.json` with
source type, source row/account counts, invalid/duplicate counts, sample method,
likely-good message handoff rows, and next action. Avoid generic TAM language
for supplied profile rows and existing lead lists.

## Output Contract

Return:

- `kickoffDocPath`
- `status`
- `recommendedSearchOrder`
- `validationSummary`
- `sampledCount`
- `passCount`
- `passRate`
- `projectedRange`
- `recentStrongPostCount`
- `freshEnoughPostCount`
- `avgUsableEngagersPerStrongPost`
- `estimatedUsefulConversations`
- `estimatedReachableLeads`
- `scaleAssessment`
- `recommendedExplorerSet`
- `feasibilitySummary`
- `topPersonas`
- `deferredTopics`
- `nextAction`

## Acceptance Rehearsal

Before calling this prompt ready, rehearse it against:

- `./.planning/phases/02-lead-list-building-automation/02-AMPLIFY-KICKOFF-TRANSCRIPT.md`

Compare the resulting kickoff doc outline against:

- `./.planning/phases/02-lead-list-building-automation/02-DRYRUN-AMPLIFY-GTM-KICKOFF.md`

Passing rehearsal means the prompt can:

- extract the ICP / persona layers from the Amplify call
- write a feasibility check
- recommend source order from brief quality plus sample evidence instead of one fixed default
- try alternate hypotheses when the first lane is too weak or noisy
- estimate recent usable conversation volume instead of only saying keep/discard
- say clearly when a lane is below the minimum scalable threshold instead of over-recommending it
- widen and retest a promising but under-scaled lane before returning
- produce a kickoff doc shape that matches the dry-run sections closely enough for human review