@sellable/mcp 0.1.557 → 0.1.559

package/skills/find-leads/SKILL.md

@@ -1,57 +1,639 @@
 ---
 name: find-leads
-description: Find or source prospects, build and watch a live Sellable lead list, and export the finished list without creating a campaign.
-visibility: public
-allowed-tools:
-  - mcp__sellable__get_auth_status
-  - mcp__sellable__start_cli_login
-  - mcp__sellable__wait_for_cli_login
-  - mcp__sellable__get_active_workspace
-  - mcp__sellable__list_workspaces
-  - mcp__sellable__set_active_workspace
-  - mcp__sellable__get_subskill_prompt
-  - mcp__sellable__get_subskill_asset
-  - mcp__sellable__search_subskill_prompts
-  - mcp__sellable__get_provider_prompt
-  - mcp__sellable__bootstrap_find_leads
-  - mcp__sellable__get_find_leads_run
-  - mcp__sellable__update_find_leads_run
-  - mcp__sellable__wait_for_find_leads_run
-  - mcp__sellable__cancel_find_leads
-  - mcp__sellable__reissue_find_leads_watch_link
-  - mcp__sellable__preflight_find_leads_provider
-  - mcp__sellable__lookup_sales_nav_filter
-  - mcp__sellable__search_sales_nav
-  - mcp__sellable__search_prospeo
-  - mcp__sellable__search_signals
-  - mcp__sellable__select_promising_posts
-  - mcp__sellable__import_leads
-  - mcp__sellable__wait_for_lead_list_ready
-  - mcp__sellable__get_rows_minimal
-  - mcp__sellable__export_table_csv
+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
 ---
 
-# Sellable Find Leads
+# Find Leads
 
-Use this public command when the user asks to find or source prospects, build a lead list,
-watch the list fill in real time, review leads, or export the list.
-It works without an existing campaign.
+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.
 
-## Load the canonical workflow
+## Scope Boundary
 
-1. Call `mcp__sellable__get_auth_status({})` and complete login/workspace setup
-   if required.
-2. Load `mcp__sellable__get_subskill_prompt({ subskillName: "find-leads-v2" })`.
-   Continue chunks until `hasMore` is false.
-3. Load `mcp__sellable__get_subskill_asset({ subskillName: "find-leads-v2",
-   assetPath: "core/flow.v1.json" })`.
-4. Execute that prompt and flow as the operational source of truth.
+In scope:
 
-Do not emulate the workflow from memory or local files. If prompt or asset
-loading fails, use `search_subskill_prompts({ query: "find-leads-v2",
-includePublic: true, includeInternal: true })`, retry once, then give the
-workflow's reinstall/reload guidance.
+- 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
 
-Keep approval questions in the current chat. A source-plan approval allows only
-the bounded provider search. A later import approval is required before rows
-are materialized. Export uses the source list directly.
+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