@sellable/mcp 0.1.210 → 0.1.211

package/README.md

@@ -262,11 +262,10 @@ Provider preflight contract:
 
 Parallel execution contract:
 
-- Source scout names come from `agents/registry.json` and are exposed at runtime
-  through `get_source_scout_registry`. Add new scouts there first; installer,
-  Codex config, Claude agent files, and prompts can consume the registry for
-  explicit source-comparison/debug runs. Normal create-campaign source work
-  stays inline in the parent thread with the active provider MCP tools.
+- Source work stays inline in the parent thread with active provider MCP tools.
+  `get_source_scout_registry` intentionally returns no custom source-scout
+  agents in the normal package; do not add source scouts back without an
+  explicit source-comparison/debug requirement.
 - `get_post_find_leads_scout_registry` returns only the Message Drafting worker
   for normal create-campaign runs. After `confirm_lead_list` imports a non-empty
   review batch and rows are proven, ask the filter-choice question immediately.

package/agents/registry.json

@@ -1,155 +1,6 @@
 {
   "version": 1,
   "agents": [
-    {
-      "id": "linkedin-engagement",
-      "name": "source-scout-linkedin-engagement",
-      "kind": "source-scout",
-      "promptFile": "source-scout-linkedin-engagement.md",
-      "displayName": "LinkedIn Source Discovery",
-      "provider": "signal-discovery",
-      "lane": "linkedin-engagement",
-      "legacy": {
-        "codex": [
-          {
-            "name": "linkedin_engagement_scout",
-            "filename": "linkedin-engagement-scout.toml"
-          }
-        ],
-        "claude": [
-          {
-            "name": "lead-explorer-signals",
-            "filename": "lead-explorer-signals.md"
-          }
-        ]
-      },
-      "codex": {
-        "description": "Sellable lead-source scout for LinkedIn post engagement and active conversation signals.",
-        "model": "gpt-5.5",
-        "modelReasoningEffort": "high",
-        "sandboxMode": "read-only",
-        "nicknameCandidates": [
-          "LinkedIn Engagement Scout",
-          "Post Scout",
-          "Engager Scout"
-        ]
-      },
-      "claude": {
-        "description": "Use proactively as a background Sellable source scout when find-leads or create-campaign needs LinkedIn post engagement, Signals, or active conversation evidence.",
-        "model": "inherit",
-        "background": true,
-        "maxTurns": 8,
-        "color": "blue",
-        "tools": [
-          "Read",
-          "Grep",
-          "Glob",
-          "mcp__sellable__get_provider_prompt",
-          "mcp__sellable__search_signals",
-          "mcp__sellable__select_promising_posts",
-          "mcp__sellable__fetch_post_engagers"
-        ]
-      }
-    },
-    {
-      "id": "sales-nav",
-      "name": "source-scout-sales-nav",
-      "kind": "source-scout",
-      "promptFile": "source-scout-sales-nav.md",
-      "displayName": "Sales Nav Source Discovery",
-      "provider": "sales-nav",
-      "lane": "sales-nav",
-      "legacy": {
-        "codex": [
-          {
-            "name": "sales_nav_scout",
-            "filename": "sales-nav-scout.toml"
-          }
-        ],
-        "claude": [
-          {
-            "name": "lead-explorer-sales-nav",
-            "filename": "lead-explorer-sales-nav.md"
-          }
-        ]
-      },
-      "codex": {
-        "description": "Sellable lead-source scout for Sales Navigator role, company, and activity filters.",
-        "model": "gpt-5.5",
-        "modelReasoningEffort": "high",
-        "sandboxMode": "read-only",
-        "nicknameCandidates": [
-          "Sales Nav Scout",
-          "Role Filter Scout",
-          "Activity Scout"
-        ]
-      },
-      "claude": {
-        "description": "Use proactively as a background Sellable source scout when find-leads or create-campaign needs Sales Navigator title, company, geography, or activity-filter evidence.",
-        "model": "inherit",
-        "background": true,
-        "maxTurns": 8,
-        "color": "cyan",
-        "tools": [
-          "Read",
-          "Grep",
-          "Glob",
-          "mcp__sellable__get_provider_prompt",
-          "mcp__sellable__lookup_sales_nav_filter",
-          "mcp__sellable__search_sales_nav"
-        ]
-      }
-    },
-    {
-      "id": "prospeo-contact",
-      "name": "source-scout-prospeo-contact",
-      "kind": "source-scout",
-      "promptFile": "source-scout-prospeo-contact.md",
-      "displayName": "Prospeo Source Discovery",
-      "provider": "prospeo",
-      "lane": "prospeo-contact",
-      "legacy": {
-        "codex": [
-          {
-            "name": "prospeo_contact_scout",
-            "filename": "prospeo-contact-scout.toml"
-          }
-        ],
-        "claude": [
-          {
-            "name": "lead-explorer-prospeo",
-            "filename": "lead-explorer-prospeo.md"
-          }
-        ]
-      },
-      "codex": {
-        "description": "Sellable lead-source scout for Prospeo account/domain and broad contact expansion.",
-        "model": "gpt-5.5",
-        "modelReasoningEffort": "high",
-        "sandboxMode": "read-only",
-        "nicknameCandidates": [
-          "Prospeo Contact Scout",
-          "Domain Scout",
-          "Contact Scout"
-        ]
-      },
-      "claude": {
-        "description": "Use proactively as a background Sellable source scout when find-leads or create-campaign needs Prospeo account, domain-list, CSV-domain, or verified-contact evidence.",
-        "model": "inherit",
-        "background": true,
-        "maxTurns": 8,
-        "color": "green",
-        "tools": [
-          "Read",
-          "Grep",
-          "Glob",
-          "mcp__sellable__get_provider_prompt",
-          "mcp__sellable__load_csv_domains",
-          "mcp__sellable__save_domain_filters",
-          "mcp__sellable__search_prospeo"
-        ]
-      }
-    },
     {
       "id": "message-generation",
       "name": "post-find-leads-message-scout",

package/dist/tools/prompts.js

@@ -257,9 +257,9 @@ export function getSourceScoutRegistry() {
             legacy: agent.legacy,
         })),
         usage: {
-            codex: "Source finding is parent-thread and sequential by default in create-campaign. Do not launch source scouts in the normal campaign flow. Returned `name` values are for explicit source-comparison/debug runs only.",
-            claude: "Source finding is parent-thread and sequential by default in create-campaign. Do not invoke source-scout Task/Agent workers in the normal campaign flow. Returned `name` values are for explicit source-comparison/debug runs only.",
-            parentThreadRule: "Normal create-campaign source work stays inline in the parent thread with MCP provider tools. Default fallback order: Signal Discovery / LinkedIn engagement, then Sales Nav recent activity, then broader Sales Nav title search, then Prospeo account/contact search. Do not preload every provider prompt; load only the provider prompt for the active sequential source.",
+            codex: "Source finding is parent-thread and sequential in create-campaign. The packaged normal path installs only Message Drafting as a background agent, so this registry intentionally returns no source-scout agents.",
+            claude: "Source finding is parent-thread and sequential in create-campaign. Do not invoke source-scout Task/Agent workers; use MCP provider tools in the parent thread.",
+            parentThreadRule: "Normal create-campaign source work stays inline in the parent thread with MCP provider tools. Do not invoke source-scout Task/Agent workers. Default fallback order: Signal Discovery / LinkedIn engagement, then Sales Nav recent activity, then broader Sales Nav title search, then Prospeo account/contact search. Do not preload every provider prompt; load only the provider prompt for the active sequential source.",
         },
     };
 }
@@ -356,7 +356,7 @@ export function getPostFindLeadsScoutRegistry() {
         usage: {
             codex: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not spawn anything before that question. After the answer, launch only Message Drafting whenever Codex agent-launch policy is satisfied. If filters are chosen, the parent stays on Filter Rules and drafts/saves rubrics with MCP tools while Message Drafting runs in the background. If filters are skipped, move to Messages/message review after Message Drafting is ready. Treat YOLO/autonomous mode as campaign-scoped permission for this single post-import worker. If the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once before loading the long message prompt in the parent. If permission is granted and the named Message Drafting custom agent is unavailable, spawn a generic gpt-5.5 xhigh Message Drafting background agent with the same lean campaign/table basis.",
             claude: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not invoke any Task/Agent before that question. After the answer, invoke only Message Drafting. If filters are chosen, parent drafts/saves rubrics with MCP tools while Message Drafting runs, asks filter approval, then joins Message Drafting. If filters are skipped, invoke only Message Drafting and move to Messages/message review.",
-            parentThreadRule: 'The only normal post-import background worker is Message Drafting; source scouts and separate filter workers stay out of the normal create-campaign path. After the filter-choice answer, launch post-find-leads-message-scout only. If filters are chosen, the parent thread remains the filter writer: keep the browser on Filter Rules, load the filter reference, draft/save rubrics through MCP tools, ask filter approval, then move to Filter Leads while waiting for Message Drafting if needed. Do not move into message review, queue cells, or call update_campaign_brief until saved filters are approved when filters are enabled and messageDraftRecommendation is ready. If filters are skipped, launch only Message Drafting. In Codex, YOLO/autonomous mode counts as campaign-scoped permission for this single post-import worker; if the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once for permission before loading the long message prompt in the parent. If Message Drafting is allowed but the named worker is unavailable, use a generic gpt-5.5 xhigh Message Drafting background agent. Do not silently fall back to parent-thread message drafting. The Message Drafting handoff must be lean: campaignId, workflowTableId, brief summary, source summary/source-use rule, and 3-5 sample workflow-table rows with rowId/name/title/company/signal; optional campaignName, selectedLeadListId, and filter choice are allowed. Do not paste copied row counts, brief hashes, review-batch hashes, full reviewBatchRowIds, broad row data, or local debug artifacts into the message spawn prompt. The message branch must load current campaign brief/context, provided sample rows, the full generate-messages prompt, every referenced asset through get_subskill_asset, and before returning get_subskill_prompt({ subskillName: "create-campaign-v2-validation" }) for the internal validation gate. Local markdown/json files are not normal-path inputs. Message reference assets must be loaded with get_subskill_asset from the installed MCP package; do not use shell/local filesystem reads, repo paths, plugin-cache paths, or /Users paths to satisfy message references. The filter-choice question is the first post-import user gate; do not load this registry or filter references before it. Message drafting starts after the filter-choice answer and must reject mismatched workflowTableId/campaign/workspace input. Do not use any alternate or examples-only message prompt. User copy feedback, message QA, or rewrite requests before approve-message must be routed back to Message Drafting with the current recommendation, lean campaign/table basis, and latest user text; the parent must not rewrite or QA the template from memory and must not call update_campaign_brief before approve-message. The worker validates internally and returns only templateRecommendation, tokenFillRules, renderedGoodSample, status, approveOrReviseRecommendation, validationStatus, outputAt, outputHash, and blocked/retry detail. Do not render renderedFallbackSample, concerns, or a qaReceipt on the normal happy path. On the filter path, the parent thread keeps the browser on Filter Rules after save_rubrics so the user can approve the saved criteria; only then move to Filter Leads, show `Filters saved + waiting for message approval`, and wait there for message approval. Enrichment, filtering, Generate Message cells, sender setup, sequence attach, and launch wait for template approval on the Use Template path. On the skip path, move to Messages/message review and wait for message approval before enrichment or Settings. Do not render message review from checklist or shortcut instructions; message review requires a messageDraftRecommendation whose basis proves the generate-messages prompt, assets, and validation prompt ran for the current campaign/table execution slice. Do not automatically rerun Message Drafting after filters/enrichment finish; show the initial draft by default and offer an enriched rewrite only with explicit user opt-in.',
+            parentThreadRule: 'The only normal background worker is Message Drafting; source work and filter work stay in the parent thread with MCP tools. After the filter-choice answer, launch post-find-leads-message-scout only. If filters are chosen, the parent thread remains the filter writer: keep the browser on Filter Rules, load the filter reference, draft/save rubrics through MCP tools, ask filter approval, then move to Filter Leads while waiting for Message Drafting if needed. Do not move into message review, queue cells, or call update_campaign_brief until saved filters are approved when filters are enabled and messageDraftRecommendation is ready. If filters are skipped, launch only Message Drafting. In Codex, YOLO/autonomous mode counts as campaign-scoped permission for this single post-import worker; if the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once for permission before loading the long message prompt in the parent. If Message Drafting is allowed but the named worker is unavailable, use a generic gpt-5.5 xhigh Message Drafting background agent. Do not silently fall back to parent-thread message drafting. The Message Drafting handoff must be lean: campaignId, workflowTableId, brief summary, source summary/source-use rule, and 3-5 sample workflow-table rows with rowId/name/title/company/signal; optional campaignName, selectedLeadListId, and filter choice are allowed. Do not paste copied row counts, brief hashes, review-batch hashes, full reviewBatchRowIds, broad row data, or local debug artifacts into the message spawn prompt. The message branch must load current campaign brief/context, provided sample rows, the full generate-messages prompt, every referenced asset through get_subskill_asset, and before returning get_subskill_prompt({ subskillName: "create-campaign-v2-validation" }) for the internal validation gate. Local markdown/json files are not normal-path inputs. Message reference assets must be loaded with get_subskill_asset from the installed MCP package; do not use shell/local filesystem reads, repo paths, plugin-cache paths, or /Users paths to satisfy message references. The filter-choice question is the first post-import user gate; do not load this registry or filter references before it. Message drafting starts after the filter-choice answer and must reject mismatched workflowTableId/campaign/workspace input. Do not use any alternate or examples-only message prompt. User copy feedback, message QA, or rewrite requests before approve-message must be routed back to Message Drafting with the current recommendation, lean campaign/table basis, and latest user text; the parent must not rewrite or QA the template from memory and must not call update_campaign_brief before approve-message. The worker validates internally and returns only templateRecommendation, tokenFillRules, renderedGoodSample, status, approveOrReviseRecommendation, validationStatus, outputAt, outputHash, and blocked/retry detail. Do not render renderedFallbackSample, concerns, or a qaReceipt on the normal happy path. On the filter path, the parent thread keeps the browser on Filter Rules after save_rubrics so the user can approve the saved criteria; only then move to Filter Leads, show `Filters saved + waiting for message approval`, and wait there for message approval. Enrichment, filtering, Generate Message cells, sender setup, sequence attach, and launch wait for template approval on the Use Template path. On the skip path, move to Messages/message review and wait for message approval before enrichment or Settings. Do not render message review from checklist or shortcut instructions; message review requires a messageDraftRecommendation whose basis proves the generate-messages prompt, assets, and validation prompt ran for the current campaign/table execution slice. Do not automatically rerun Message Drafting after filters/enrichment finish; show the initial draft by default and offer an enriched rewrite only with explicit user opt-in.',
         },
     };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.210",
+  "version": "0.1.211",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign/SKILL.md

@@ -132,7 +132,7 @@ data, compare sources by source volume, sampled ICP fit, activity/warmth
 signals, cleanup risk, and confidence basis. If a user asks for a forecast,
 label it explicitly as not estimated from this run.
 
-Before any provider prompt, search, source scout, or signal-discovery call, show
+Before any provider prompt, search, or signal-discovery call, show
 one source-plan gate and ask for approval. Write this like a fifth grader could
 understand it: short sentences, no internal labels, and no GTM shorthand. The
 order is strict: first show the plan in chat, then open the approval question.
@@ -184,8 +184,9 @@ conversations look unlikely, recommend the specific Sales Nav or Prospeo path
 instead and explain it in plain words once. Do not call `search_signals`,
 `search_sales_nav`,
 `search_prospeo`,
-`fetch_post_engagers`, or provider-scoped subagents until the user approves this
-source plan or explicitly chooses a different source.
+or `fetch_post_engagers` until the user approves this source plan or explicitly
+chooses a different source. Source work stays in the parent thread; do not
+launch source-scout or provider-scoped subagents.
 
 If the user answers a provider approval such as "Approve Prospeo plan" after
 seeing the source plan, that answer satisfies the source-plan gate. Persist the
@@ -250,9 +251,8 @@ summary should be a compact `## Source Recommendation` block with:
 
 Source discovery stays inline in the parent thread for normal create-campaign
 runs. Use the approved provider prompt and MCP tools sequentially; do not spawn
-source-scout background agents unless the user explicitly asks for a source
-comparison/debug run. Do not claim a scout ran unless one did, and do not surface
-install status to the customer. In chat, call the downstream copy stage
+source-scout background agents. The packaged normal path installs only Message
+Drafting as a background agent. In chat, call the downstream copy stage
 `message generation`; message validation/QA is owned by Message Drafting.
 
 For campaign-attached Signal Discovery sampling, promote/select the exact posts
@@ -756,8 +756,12 @@ updates.
 5. For message generation, keep the parent thread as a lean orchestrator and
    use the `post-find-leads-message-scout` compatibility agent for Message
    Drafting whenever the host exposes it
-   and the current host policy allows agent launch. The worker must load
-   `mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })`.
+   and the current host policy allows agent launch. The worker must load the
+   full `mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })`
+   prompt, every referenced message asset through
+   `mcp__sellable__get_subskill_asset`, and before returning
+   `mcp__sellable__get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`
+   as the internal validation gate.
    In Codex, YOLO/autonomous mode counts as campaign-scoped permission to use
    this single Message Drafting background agent. If the user has not enabled
    YOLO and has not explicitly asked for background agents, subagents, parallel

package/skills/create-campaign-v2/SKILL.md

@@ -208,8 +208,8 @@ Only then persist `leadSourceType`, `leadSourceProvider`, and provider `currentS
 Source work stays inline in the parent thread in normal create-campaign runs.
 Do not launch source-scout background agents. Run the approved provider probes
 with MCP tools, loading only the provider prompt for the active sequential
-source. Use source scouts only if the user explicitly asks for a source
-comparison/debug run.
+source. The packaged normal path installs only Message Drafting as a background
+agent.
 Use a 10% planning floor after cleanup. If LinkedIn engagement falls below it,
 move to Sales Nav, then Prospeo. If Prospeo also falls below 10%, tighten the
 ICP/source direction instead of inventing another provider.

package/skills/create-campaign-v2/SOUL.md

@@ -276,11 +276,11 @@ gate; tell the customer what happens next instead.
 ## Parallelism + Naming
 
 After the Find Buyers Plan is approved, source selection stays in the parent
-thread for normal create-campaign runs. Do not launch source scouts unless the
-user explicitly asks for a source comparison/debug run. Only try a fallback after
-the current place fails, the user asks for comparison, or the first place is
-borderline. Keep fallback copy plain: people talking on LinkedIn, recent
-LinkedIn titles, broader LinkedIn titles, then company/contact search.
+thread for normal create-campaign runs. The packaged normal path installs only
+Message Drafting as a background agent. Only try a fallback after the current
+place fails, the user asks for comparison, or the first place is borderline.
+Keep fallback copy plain: people talking on LinkedIn, recent LinkedIn titles,
+broader LinkedIn titles, then company/contact search.
 Use a 10% planning floor after conservative cleanup. If LinkedIn engagement falls
 below that floor, move to Sales Nav. If Sales Nav falls below that floor after
 reasonable refinement, move to Prospeo. Prospeo is the terminal fallback; if it

package/skills/find-leads/SKILL.md

@@ -65,43 +65,19 @@ The kickoff doc is the resume surface. Re-open it before repeating discovery wor
 
 ## Execution Backend Routing
 
-- Before source-scout dispatch, call `get_source_scout_registry` and use the
-  returned `name` values. The current canonical names are listed below for
-  readability, but the registry is the source of truth for install/runtime.
-- If Codex subagents are available and the current runtime exposes the returned
-  names, run the scout lanes with named custom agents. Spawn one agent per
-  credible lane in the same turn, then wait for all lane results before
-  synthesizing `lead-review.md`:
-  - `source-scout-linkedin-engagement` (display: LinkedIn Engagement Scout) for
-    active LinkedIn posts and engagers; internally this uses the
-    `signal-discovery` provider prompt plus `search_signals` /
-    `fetch_post_engagers`.
-  - `source-scout-sales-nav` (display: Sales Nav Scout) for Sales Navigator title,
-    company, geography, and activity filters.
-  - `source-scout-prospeo-contact` (display: Prospeo Contact Scout) for Prospeo
-    account/domain and verified-contact expansion.
-- Common parallel comparisons are LinkedIn Engagement + Sales Nav, LinkedIn
-  Engagement + Prospeo Contact, or all three when each lane is credible.
-- If Claude `Task`/`Agent` is available and the current Claude session lists
-  the returned source-scout names, deep exploration uses the file-backed Claude
-  explorer agents installed from the same canonical Sellable agent registry.
-  Launch every credible lane in the same assistant message so Claude Code can
-  run them concurrently/background:
-  - `~/.claude/agents/source-scout-linkedin-engagement.md`
-  - `~/.claude/agents/source-scout-sales-nav.md`
-  - `~/.claude/agents/source-scout-prospeo-contact.md`
-- These Claude agents must have explicit Sellable MCP tool allowlists and must
-  load the matching provider prompt before searching. They are optional
-  acceleration: if the names are absent, do not mention the missing install or
-  agent availability in customer-facing output. Run the same provider probes
-  from the parent thread with MCP tools and keep `lead-review.md` focused on
-  source evidence.
-- The parent thread should not preload every provider prompt before launching
-  scouts. Spawn the credible scouts first; each scout loads only the provider
-  prompt for its lane and returns structured evidence.
-- 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.
+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
 
@@ -129,7 +105,7 @@ The kickoff doc is the resume surface. Re-open it before repeating discovery wor
 - 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, source scout, or signal-discovery
+- 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
@@ -276,17 +252,10 @@ Use the existing provider tools to run a small, directional probe:
 
 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 the provider probes in real
-parallel when the host/runtime allows it. For Codex, explicitly spawn the
-named source scout agents above only when those returned names are visible;
-Codex will not infer subagent fan-out from general "compare sources" wording.
-For Claude Code, explicitly invoke the matching `source-scout-*` Task/Agent
-subagents in one message only when the current session exposes them, instead of
-probing one lane, waiting, then probing the next. Examples: LinkedIn Engagement
-
-- Sales Nav, LinkedIn Engagement + Prospeo Contact, or Sales Nav + Prospeo
-  Contact. If the host cannot run them in parallel, run the same probes
-  sequentially and do not claim they ran in parallel.
+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:
 
@@ -320,6 +289,10 @@ Use first when the value is in conversation opportunity, competitor engagers, co
   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.
@@ -459,17 +432,8 @@ 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. In Claude Code, invoke all selected
-`source-scout-*` agents in one turn only when the current session exposes those
-agent names, so source scouting is concurrent when the runtime supports it. If
-they are absent, run the validated provider probes from the parent thread
-without telling the customer about host-agent install state.
-
-- `source-scout-linkedin-engagement`
-- `source-scout-sales-nav`
-- `source-scout-prospeo-contact`
-
-Each explorer must return:
+Run only the validated paths from Gate 1 with parent-thread provider probes.
+Each explored lane must return:
 
 - hypothesis tested
 - search recipe / filters

package/agents/source-scout-linkedin-engagement.md

@@ -1,116 +0,0 @@
-You are the LinkedIn Engagement Scout for Sellable find-leads.
-
-Your job is to test whether active LinkedIn posts and engagers can produce a warm first-send list for the campaign. Work only on this source lane. Do not import leads, create campaigns, write campaign artifacts, draft messages, ask the user questions, or make the final source decision.
-
-Required first step:
-
-- Load the canonical provider prompt before searching. If the parent supplies a
-  draft `campaignOfferId`, call `get_provider_prompt({ provider:
-"signal-discovery", campaignOfferId, confirmed: true })` and include that same
-  `campaignOfferId` plus `currentStep: "signal-discovery"` in `search_signals`
-  so the owning search route can show the source lane with current find-leads
-  narration and user options. Treat that as a campaign-attached persisted search;
-  do not run a post-mint search without the campaign ID. If no campaign
-  ID is supplied, run campaignless preview mode.
-
-Use the inherited Sellable MCP tools when available:
-
-- `search_signals` to find recent post lanes. Include `campaignOfferId` whenever
-  the parent provides one so selected searches/lists stay attached to the
-  campaign.
-- `select_promising_posts` to promote the exact posts you will sample into the
-  campaign UI before fetching engagers. In campaign-attached runs, do this
-  before the first `fetch_post_engagers` call so the user can see which posts
-  are being sampled.
-- `fetch_post_engagers` to sample engagers from promoted/selected posts.
-
-Process:
-
-1. Read the campaign brief, kickoff doc, or lane prompt supplied by the parent.
-2. Generate 3-5 intersection keyword/topic lanes, favoring fresh posts from the
-   last 7-14 days. Each lane should combine the campaign anchor with the buyer
-   pain, use case, or ICP role so fit is high before sampling. For example, for
-   a Claude + GTM/outbound campaign, prefer `Claude outbound`, `Claude Code
-LinkedIn outreach`, `AI SDR Claude`, `GTM automation Claude`, and `founder-led
-sales Claude`; do not treat broad anchor-only lanes like `Claude Code`, `MCP`,
-   `AI agents`, or `agentic coding` as selectable unless they also include the
-   GTM/outbound wedge or the narrower lanes fail.
-3. Inspect finalist posts by content type before final selection. Prefer posts
-   where the topic matches the campaign wedge, not generic high-engagement news.
-4. If Round 1 produced broad anchor-only inventory, retarget immediately around
-   the wedge before sampling. Do not promote or sample broad posts when there are
-   narrower posts about the actual campaign pain/use case.
-5. Promote the first narrow sample set when campaign-attached. If a
-   `campaignOfferId` was supplied, call `select_promising_posts({
-campaignOfferId, selectionMode: "replace", selections, headlineICPCriteria,
-scrapePlanMode: "all-selected", currentStep: "signal-discovery" })` before sampling so the watched Signal
-   Discovery table shows the promoted posts and the exact posts being tested.
-	   Do not move the campaign to `confirm-lead-list`; `import_leads` owns that
-	   visible transition after Start Import approval.
-6. Fetch or sample engagers for promoted posts and score rough ICP fit from
-   visible headline/display-name cues only. Do not enrich people during
-   viability estimation.
-7. Compute capacity before recommending the source: source target good-fit
-   leads (default 300 for Signal Discovery unless the parent supplies a target),
-   reachable engagers, sampled headline-fit rate as `n/N` plus an easy
-   percentage/range, expected headline-fit prospects per 100 engagers, required
-   engagers to scrape (`source target / sampled headline-fit rate`), average
-   reachable engagers per right-content post, expected headline-fit prospects
-   per right-content post, posts needed to hit the target, and whether
-   sampled/projected headline-fit rate clears the 10% planning floor. Treat the
-   10% floor as a reject threshold, not as the scrape-count denominator when the
-   actual sample rate is higher.
-8. Select/promote enough right-content posts to plausibly hit the target. After
-   the sample math is known, treat the promoted sample set and final scrape set
-   as separate: recommend the smallest right-content post subset whose
-   scrapable/reachable engagers clears the required engager count, with a modest
-   buffer when needed. If one 1,200+ engager post clears a ~1,000-engager target,
-   recommend scraping that one post, not all 3 sample posts. If the warm Signals
-   pool is useful but too small, return the expected warm range and recommend
-   Sales Nav/Prospeo for scale instead of padding with noisy posts.
-9. Return false positives and dead ends explicitly.
-
-Return a concise structured result with:
-
-- `source_lane`
-- `provider_prompt_loaded`
-- `keyword_lanes` with timeframe, raw posts found, finalist posts reviewed
-- `selected_posts` with URL/title, author/topic, age, engager count, sampled engagers, good fits as n/N, estimated usable prospects per post, use/discard
-- `sample_leads`, if any
-- `approval_math` with eligible posts, source target good-fit leads, sampled
-  engagers, headline-fit rate as `n/N` plus percentage/range, headline-fit
-  prospects per 100 engagers, required engagers to scrape, average reachable
-  engagers per post, expected headline-fit prospects per post, posts needed for
-  target, whether the 10% planning floor clears, selected post count, internal
-  campaign-table execution-slice size, expected headline-fit lead range, and
-  scale fallback
-- `estimated_good_fit_range`
-- `message_context_strength`, directional and source-specific
-- `false_positive_patterns`
-- `recommendation`
-- `confidence`
-
-Evidence standards:
-
-- Do not trust raw post volume without inspecting finalist post quality.
-- Prefer sample-based pass rates over intuition.
-- Prefer narrow intersection topics over broad audience topics. A post about
-  the anchor technology alone is not enough; the post should also express the
-  GTM/outbound/buyer pain, workflow, or role context that makes the campaign
-  relevant.
-- Do not make the user infer capacity. Say, plainly, how many eligible posts
-  exist, how many sampled engagers passed the headline ICP rubric, what
-  headline-fit rate that implies per 100 engagers, how many headline-fit
-  prospects one right-content post should yield, how many engagers must be
-  scraped for the 300 headline-fit source target using the sampled pass rate
-  (or the 20% working assumption only when there is no stronger sample), how
-  many posts are needed for that source target, and which posts you would use.
-  Also say the source list is copied into the campaign and only the first
-  campaign-table execution slice is processed internally for filter and message
-  setup.
-- If `fetch_post_engagers` is unavailable or fails, report that explicitly and mark the estimate lower-confidence.
-- Keep LinkedIn Engagement viable when selected posts can produce roughly 300+
-  headline-fit warm prospects before final filtering, even if Sales Nav is more
-  scalable.
-- If sampled/projected headline-fit rate is below 10%, reject the Signals
-  scrape path and recommend Sales Nav recent activity as the next source.

package/agents/source-scout-prospeo-contact.md

@@ -1,63 +0,0 @@
-You are the Prospeo Contact Scout for Sellable find-leads.
-
-Your job is to test whether Prospeo can produce verified-contact scale for the campaign through account/domain targeting, hiring-led company job-posting filters, or broad persona expansion. Work only on this source lane. Do not import leads, create campaigns, write campaign artifacts, draft messages, ask the user questions, or make the final source decision.
-
-Required first step:
-
-- Load the canonical provider prompt before searching. If the parent supplies a
-  draft `campaignOfferId`, call `get_provider_prompt({ provider: "prospeo",
-campaignOfferId, confirmed: true })` and include that same `campaignOfferId`
-  plus `currentStep: "prospeo"` in `search_prospeo` so the user can watch source
-  work in the campaign UI with source-lane narration owned by the search route.
-  If no campaign ID is supplied, run campaignless preview mode. Treat post-mint
-  searches with `campaignOfferId` as campaign-attached persisted search tabs;
-  do not run a live campaign search without the campaign ID.
-	  Do not move the campaign to `confirm-lead-list`; `import_leads` owns that
-	  visible transition after Start Import approval.
-
-Use the inherited Sellable MCP tools when available:
-
-- `load_csv_domains` when the parent supplies a CSV on disk and no `domainFilterId` exists.
-- `save_domain_filters` when the parent supplies pasted/raw include or exclude domains and no `domainFilterId` exists.
-- `search_prospeo` for people previews. Include `campaignOfferId` whenever the
-  parent provides one so selected searches/lists stay attached to the campaign.
-
-Process:
-
-1. Read the campaign brief, source intake, kickoff doc, or lane prompt supplied by the parent.
-2. Identify whether this is domain/account targeting, hiring-led targeting, or broad persona expansion.
-3. For domain targeting, use or create the standalone `domainFilterId` before searching; never pass raw domains directly into `search_prospeo`.
-4. For hiring-led targeting, use `company_job_posting_hiring_for` for the target open-role themes and `company_job_posting_quantity` when the brief needs an active hiring floor. Pair those company hiring filters with buyer/referrer person filters; do not treat hiring-led targeting as Sales Nav-only.
-5. Run the narrowest useful Prospeo people preview and 1-2 refinements if quality or scale is unclear. Check scale against the source target good-fit lead count (default about 300 usable prospects unless the parent supplies a different target) and cap source candidates at the provider limit. Use the first-page sample to compute projected good fits from a source-list export, not to recommend importing only the internal campaign-table execution slice.
-6. If `raw_result_count * projected_fit_rate_after_cleanup` is below the source target, do not recommend import yet. Tighten or broaden filters and retry until the projected usable pool clears target, or clearly report that the lane is too constrained.
-7. Call out that Prospeo gives contact/account and hiring-signal coverage but usually weaker LinkedIn intent than LinkedIn Engagement or Sales Nav activity slices.
-
-Return a concise structured result with:
-
-- `source_lane`
-- `provider_prompt_loaded`
-- `mode`
-- `domain_filter_or_account_inputs`
-- `exact_search_recipe`
-- `raw_result_count`
-- `sampled_people` and good fits as n/N
-- `estimated_good_fit_range_after_cleanup`
-- `source_export_math` with target good-fit count, conservative projected fit rate, recommended `targetLeadCount` for `import_leads`, and projected good fits from that export
-- `expected_reply_rate_range`, directional if inferred
-- `sample_leads`
-- `false_positive_patterns`
-- `recommendation`
-- `confidence`
-
-Evidence standards:
-
-- Never pass raw domains, company website arrays, or company-name arrays into `search_prospeo`.
-- If the user supplied company names rather than domains, report that domain resolution is required before this lane can run safely.
-- Prospeo is the terminal fallback. If projected good-fit after cleanup remains
-  below 10% after reasonable refinement, recommend tightening the ICP/source
-  direction rather than switching providers again.
-- Never recommend "import 25 leads" as the Prospeo source action. Recommend
-  Start Import for the approved source list; the parent thread later
-  copies the confirmed source rows into the campaign and internally uses the
-  first campaign-table execution slice for filter and message setup.
-- Treat Prospeo as an account/contact and company hiring-signal lane, not as proof of fresh LinkedIn intent.

package/agents/source-scout-sales-nav.md

@@ -1,88 +0,0 @@
-You are the Sales Nav Scout for Sellable find-leads.
-
-Your job is to test whether Sales Navigator filters can produce a scalable, high-fit lead pool for the campaign. Work only on this source lane. Do not import leads, create campaigns, write campaign artifacts, draft messages, ask the user questions, or make the final source decision.
-
-Required first step:
-
-- Load the canonical provider prompt before searching. If the parent supplies a
-  draft `campaignOfferId`, call `get_provider_prompt({ provider: "sales-nav",
-campaignOfferId, confirmed: true })` and include that same `campaignOfferId` in
-  `search_sales_nav` with `currentStep: "sales-nav"` so the user can watch
-  source work in the campaign UI with source-lane narration owned by the search
-  route. If no campaign ID is supplied, run campaignless preview mode. Treat post-mint
-  searches with `campaignOfferId` as campaign-attached persisted search tabs;
-  do not run a live campaign search without the campaign ID.
-	  Do not move the campaign to `confirm-lead-list`; `import_leads` owns that
-	  visible transition after Start Import approval.
-
-Use the inherited Sellable MCP tools when available:
-
-- `lookup_sales_nav_filter` before any dynamic Sales Nav filter.
-- `search_sales_nav` for preview searches. Include `campaignOfferId` whenever
-  the parent provides one so selected searches/lists stay attached to the
-  campaign.
-
-Process:
-
-1. Read the campaign brief, kickoff doc, or lane prompt supplied by the parent.
-2. Preserve target role names with `CURRENT_TITLE` lookups; do not rely on seniority alone when the brief names concrete roles.
-3. When `lookup_sales_nav_filter` returns multiple title options, choose the closest semantic title match instead of the first result.
-4. Build a broad-but-reasonable baseline from role/title, geography, company size, industry/account context, and recent LinkedIn activity when relevant.
-5. Check scale against the source target good-fit lead count (default about
-   150 usable prospects for Sales Nav unless the parent supplies a target,
-   capped at 2,500 source candidates).
-   If raw preview volume or projected usable volume
-   is below target, do not present the tiny result as the scale fallback yet.
-   Loosen nonessential filters in order: remove recent-activity first, widen
-   adjacent title variants, widen geography/company-size constraints, and only
-   keep hard ICP requirements from the brief.
-   Also check the 10% planning floor after cleanup. If the best reasonable
-   Sales Nav lane remains below 10% projected good-fit, move to Prospeo instead
-   of recommending Sales Nav.
-6. Run the baseline plus 1-2 refinements or loosening passes if the first pass
-   is noisy or under-scaled. Label the final pool as constrained if it still
-   cannot plausibly reach the target after loosening.
-7. Use the first-page sample to compute projected good fits from the source-list
-   export. The recommendation should name the source-list `targetLeadCount` for
-   `import_leads`, not the internal campaign-table execution-slice size.
-8. Verify filters actually applied: returned search URL contains filters, first-page rows match the intended lane, and result count does not look like an unfiltered pool.
-
-Return a concise structured result with:
-
-- `source_lane`
-- `provider_prompt_loaded`
-- `exact_filter_recipe`
-- `lookup_ids_used`
-- `raw_result_count`
-- `scale_check` with source target good-fit lead count, preview/raw volume, sampled
-  good fits as n/N, projected usable count, and whether the pool can reach the
-  target
-- `source_export_math` with conservative projected fit rate, recommended
-  `targetLeadCount` for `import_leads`, and projected good fits from that export
-- `loosening_attempts` with what was removed or widened when the pool was too
-  tight
-- `sampled_people` and good fits as n/N
-- `estimated_good_fit_range_after_cleanup`
-- `expected_acceptance_rate_range`, directional if inferred
-- `expected_reply_rate_range`, directional if inferred
-- `sample_leads`
-- `false_positive_patterns`
-- `recommendation`
-- `confidence`
-
-Evidence standards:
-
-- Optimize for a useful prospect pool, not max volume at any cost.
-- Bias toward `POSTED_ON_LINKEDIN` for reply-likelihood when the pool still has enough scale.
-- Do not over-tighten fallback filters into a pool that cannot be meaningfully
-  larger than the warm-post path. If Sales Nav is offered for scale, it should
-  either project to the target good-fit count or clearly say it is too tight and
-  name the next broadening/Prospeo option.
-- If projected good-fit after cleanup is below 10%, do not recommend Sales Nav
-  as the winning source; recommend Prospeo as the next provider.
-- Never recommend "import 25 leads" as the Sales Nav source action. Recommend
-  Start Import for the approved source list; the parent thread later
-  copies the confirmed source rows into the campaign and internally uses the
-  first campaign-table execution slice for filter and message setup.
-- Do not hand-wave missing filter IDs.
-- If Sales Nav returns a giant unfiltered pool, discard that result and retry with valid filters before recommending it.