@sellable/mcp 0.1.0

package/skills/enrich-prospects/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: enrich-prospects
+description: Research prospects or clients using parallel sonnet subagents. Returns structured enrichment for personalization.
+visibility: internal
+---
+
+# Enrich Prospects
+
+<role>
+You are a research coordinator that spawns sonnet agents to gather prospect intelligence in parallel. Your job is to orchestrate the research and synthesize results into actionable hooks for outreach.
+</role>
+
+<objective>
+Enrich one or more prospects with:
+1. LinkedIn profile context (role, experience, company)
+2. Recent posts analysis (themes, engagement, hooks)
+3. Company research (news, case studies, differentiators)
+4. Synthesized enrichment notes for personalization
+
+**Output:** Structured enrichment notes ready for message generation.
+</objective>
+
+<tools>
+
+## Direct Tools (Main Context)
+
+- `mcp__sellable__get_linkedin_profile` - Fetch LinkedIn profile (use first to get basic info)
+- `mcp__sellable__get_rows` - Get prospect data from campaign table
+- `mcp__sellable__get_subskill_prompt` - Load shared research protocol
+
+## Subagent Research (Sonnet - parallel)
+
+- `Task` with `model="sonnet-4.5"` - Spawn research agents
+- Subagents can use: `get_user_posts`, `WebSearch`, `WebFetch`
+
+</tools>
+
+<shared_protocol>
+
+This skill uses dedicated research subskills:
+
+- `mcp/sellable/skills/research-prospect/SKILL.md`
+- `mcp/sellable/skills/research-sender/SKILL.md`
+
+Before starting, choose one:
+
+- Prospect/lead enrichment:
+  - `get_subskill_prompt({ subskillName: "research-prospect" })`
+- Client/sender enrichment:
+  - `get_subskill_prompt({ subskillName: "research-sender" })`
+
+Then follow the selected subskill directly.
+If the prospect/client data includes a company LinkedIn URL, pass it as `companyLinkedinUrl`.
+
+Override rules:
+
+1. If the user provides custom research instructions, follow them.
+2. If `mcp/sellable/skills/research/override.md` exists, follow it.
+
+</shared_protocol>
+
+<critical_rules>
+
+## Critical Rules
+
+1. **Always use sonnet-4.5 for research agents** - Keeps costs low, runs fast
+2. **Run agents in parallel** - Send all Task calls in one message
+3. **Limit to 10 posts** - More than enough for pattern detection
+4. **150 words max per agent** - Forces concise, actionable output
+5. **Exact format responses** - Makes synthesis predictable
+6. **No hallucinated quotes** - Only use actual content from posts
+7. **Handle missing data** - Say "None found" not make things up
+8. **Batch large lists** - Max 3 prospects in parallel at once
+
+</critical_rules>
+
+<usage>
+
+## How Other Skills Use This
+
+### From create-campaign (client enrichment):
+
+```
+/sellable:enrich-prospects with client's LinkedIn URL
+→ Returns: Client positioning, post themes, company context
+→ Used to: Generate smart defaults for onboarding questions
+```
+
+### From generate-messages (prospect enrichment):
+
+```
+/sellable:enrich-prospects with prospect LinkedIn URLs
+→ Returns: Hooks, pain points, conversation starters
+→ Used to: Craft personalized opening lines
+```
+
+</usage>

package/skills/find-leads/SKILL.md

@@ -0,0 +1,467 @@
+---
+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
+
+- If `Task` is available, deep exploration uses the file-backed explorer agents:
+  - `./.claude/agents/lead-explorer-signals.md`
+  - `./.claude/agents/lead-explorer-sales-nav.md`
+  - `./.claude/agents/lead-explorer-prospeo.md`
+- Else if `multi_tool_use.parallel` is available, run independent discovery calls in parallel and synthesize locally.
+- Else run sequentially.
+- Never claim agents were used when they were not.
+
+## 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__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.
+- 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.
+- 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 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.
+3. If the user has a CSV of company domains on disk, call `load_csv_domains` first.
+   - Use the returned `domainFilterId` in a provider search, then continue with `import_leads`.
+4. Otherwise run the appropriate search tool and collect a `searchId` if relevant.
+5. Call `import_leads` with:
+   - `campaignOfferId`
+   - `currentStep`
+   - `sourceLeadListId` OR `searchId`
+6. Call `wait_for_lead_list_ready` only for provider-imported lead lists (pass jobId/targetLeadCount from `import_leads` if available).
+7. Ask the user to review and confirm the list looks good.
+8. 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)
+   - `targetLeadCount` (from `import_leads` when available)
+9. For campaign-builder flows, run post-confirm routing in this order:
+   - `update_campaign({ campaignId, currentStep: "filter-choice" })`
+   - `wait_for_campaign_table_ready({ campaignId })`
+   - `get_campaign_context({ campaignId, refresh: true })`
+   - `get_rows_minimal({ tableId: workflowTableId, limit: 10, page: 1 })`
+10. 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`                                       |
+| 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.
+
+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 1-2 promising posts, then call `fetch_post_engagers` on those posts.
+- 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.
+- 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.
+- 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 both good fits and likely to reply. Compare source paths
+  by expected volume, likely connection acceptance, likely reply rate, signal
+  quality, and tradeoffs. Use sample-backed or historical numbers when
+  available; otherwise label ranges as directional.
+- 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.
+- 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 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.
+- 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
+
+Spawn only the validated paths from Gate 1.
+
+- `lead-explorer-signals`
+- `lead-explorer-sales-nav`
+- `lead-explorer-prospeo`
+
+Each explorer 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