@sellable/mcp 0.1.145 → 0.1.147

package/agents/post-find-leads-message-scout.md

@@ -137,8 +137,12 @@ Return a concise status with:
 - quality-gate pass/fail summary
 - whether final template review is ready or needs revision
 
-When the parent will show the recommendation in chat, format the customer-facing
-message review as Markdown with distinct copy blocks:
+When the parent will show the recommendation in chat, keep the customer-facing
+message review lightweight. Format only the approval target and one strong
+good-fill example as Markdown with distinct copy blocks. Keep token rules,
+omit/fallback examples, and bad-fill avoidance notes in your internal
+recommendation so the parent can persist them to the campaign brief after
+approval; do not print them in the default chat approval packet.
 
 ````markdown
 ## Message Template
@@ -155,19 +159,9 @@ message review as Markdown with distinct copy blocks:
 {{tokenized_message_body}}
 ```
 
-## Rendered Examples
+## Rendered Example
 
-### Good token fill
-
-```text
-Subject: ...
-
-Hey First,
-
-...
-```
-
-### Good omit / fallback
+Good token fill:
 
 ```text
 Subject: ...

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

@@ -57,7 +57,8 @@ currentStep: "signal-discovery" })` before sampling so the watched Signal
    leads per 100 engagers before and after a conservative dedupe/cleanup
    factor, required engagers to scrape (`source target / fit rate`), average
    reachable engagers per right-content post, expected usable leads per
-   right-content post after dedupe/cleanup, and posts needed to hit the target.
+   right-content post after dedupe/cleanup, posts needed to hit the target, and
+   whether sampled/projected fit clears the 10% planning floor.
 8. Select/promote enough right-content posts to plausibly hit the target. 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.
@@ -74,8 +75,9 @@ Return a concise structured result with:
   engagers, ICP-fit rate as `n/N` plus percentage/range, good-fit prospects per
   100 engagers, required engagers to scrape, average reachable engagers per
   post, expected usable prospects per post after cleanup, posts needed for
-  target, selected post count, review-batch import limit, expected usable lead
-  range, and scale fallback
+  target, whether the 10% planning floor clears after cleanup, selected post
+  count, review-batch import limit, expected usable lead range, and scale
+  fallback
 - `estimated_good_fit_range`
 - `message_context_strength`, directional and source-specific
 - `false_positive_patterns`
@@ -99,3 +101,5 @@ Evidence standards:
   bounded review batch.
 - 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 150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable.
+- If sampled/projected fit after cleanup 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

@@ -27,7 +27,7 @@ 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 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. Run the narrowest useful Prospeo people preview and 1-2 refinements if quality or scale is unclear. Check scale against a default 300+ good-fit target, capped at 2,500 source candidates unless the parent supplies a different target.
+4. Run the narrowest useful Prospeo people preview and 1-2 refinements if quality or scale is unclear. Check scale against a default 300+ good-fit target, capped at 2,500 source candidates unless the parent supplies a different target, and require at least 10% projected good-fit after cleanup.
 5. Call out that Prospeo gives contact/account coverage but usually weaker LinkedIn intent than LinkedIn Engagement or Sales Nav activity slices.
 
 Return a concise structured result with:
@@ -50,4 +50,7 @@ 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.
 - Treat Prospeo as an account/contact coverage lane, not as proof of fresh LinkedIn intent.

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

@@ -35,6 +35,9 @@ Process:
    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.
@@ -69,5 +72,7 @@ Evidence standards:
   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.
 - 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.

package/dist/tools/leads.js

@@ -31,6 +31,9 @@ const defaultCampaignSourceDefaults = {
         defaultSize: 25,
         minProjectedPass: 5,
     },
+    planning: {
+        minFitRate: 0.1,
+    },
     providers: {
         "signal-discovery": {
             targetGoodFitLeads: 150,
@@ -280,6 +283,10 @@ function loadCampaignSourceDefaults() {
                 ...defaultCampaignSourceDefaults.reviewBatch,
                 ...(parsed.reviewBatch ?? {}),
             },
+            planning: {
+                ...defaultCampaignSourceDefaults.planning,
+                ...(parsed.planning ?? {}),
+            },
             providers: {
                 ...defaultCampaignSourceDefaults.providers,
                 ...(parsed.providers ?? {}),
@@ -297,6 +304,7 @@ function getSignalDiscoverySourcePlanDefaults() {
     return {
         targetGoodFitLeads: signalDefaults.targetGoodFitLeads,
         defaultFitRate: signalDefaults.defaultFitRate,
+        minPlanningFitRate: defaults.planning.minFitRate,
         sourceCandidateTarget,
         reviewBatchSize: defaults.reviewBatch.defaultSize,
     };
@@ -499,17 +507,18 @@ function buildSourceImportWatchNarration({ provider, selectedPostCount, estimate
             : ""}`
         : `the approved ${providerLabel} source`;
     const targetDetail = typeof targetLeadCount === "number"
-        ? ` Targeting ${targetLeadCount.toLocaleString("en-US")} source candidates before the bounded review batch is cloned.`
+        ? ` Targeting ${targetLeadCount.toLocaleString("en-US")} source leads before the bounded review batch is cloned.`
         : "";
     return {
-        stage: "review-batch",
+        stage: "find-leads",
         headline: provider === "signal-discovery"
-            ? "Scraping source candidates from posts"
-            : "Importing source candidates",
+            ? "Scraping source leads from posts"
+            : "Importing source leads",
         visibleState: `The browser is showing ${providerLabel} import progress for ${sourceDetail}.${targetDetail}`,
         agentIntent: "Codex is materializing the approved source into a lead list before cloning only the bounded review batch into the campaign.",
-        nextAction: "Wait for source candidates, then import the review batch",
+        nextAction: "Wait for source leads, then import the 15-row review batch",
         safety: "Import is limited to the review batch.",
+        progressLabel: "Source scouting",
     };
 }
 function buildSourceImportRecoveryWatchNarration(args) {
@@ -601,7 +610,7 @@ function formatApproxInteger(value) {
     return `~${rounded.toLocaleString("en-US")}`;
 }
 function buildSignalDiscoverySourceRecommendation({ selectedPosts, }) {
-    const { targetGoodFitLeads, defaultFitRate, sourceCandidateTarget, reviewBatchSize, } = getSignalDiscoverySourcePlanDefaults();
+    const { targetGoodFitLeads, defaultFitRate, minPlanningFitRate, sourceCandidateTarget, reviewBatchSize, } = getSignalDiscoverySourcePlanDefaults();
     const selectedCount = selectedPosts.length;
     const totalEngagement = selectedPosts.reduce((sum, post) => sum + (post.likes ?? 0) + (post.comments ?? 0), 0);
     const tableRows = selectedPosts
@@ -617,6 +626,7 @@ Use Signal Discovery first.
 
 **Good-fit target:** ~${targetGoodFitLeads.toLocaleString("en-US")} prospects after cleanup, enrichment, and filters<br>
 **Source-candidate plan:** scrape ~${sourceCandidateTarget.toLocaleString("en-US")} raw engagers using a conservative ${Math.round(defaultFitRate * 100)}% fit-rate assumption<br>
+**Planning floor:** continue with Signal Discovery only when sampled/projected fit is at least ${Math.round(minPlanningFitRate * 100)}% after cleanup; below that, switch to Sales Nav recent activity<br>
 **Review checkpoint:** import the first ${reviewBatchSize.toLocaleString("en-US")} leads into the campaign for fit and message review before scaling
 
 ### Selected posts
@@ -636,7 +646,7 @@ This gives enough volume to work toward ~${targetGoodFitLeads.toLocaleString("en
 
 **First pass:** build the source list, then import only the ${reviewBatchSize.toLocaleString("en-US")}-lead review batch so we can inspect fit and messages before scaling.
 
-**Fallback:** if the review batch is too vendor-heavy, agency-heavy, or off-ICP, switch to Sales Nav recent activity.
+**Fallback:** if the sampled/projected fit rate is below ${Math.round(minPlanningFitRate * 100)}%, or if the review batch is too vendor-heavy, agency-heavy, or off-ICP, switch to Sales Nav recent activity.
 
 Approval card should say:
 
@@ -1222,7 +1232,7 @@ export const leadToolDefinitions = [
                 },
                 targetEngagerCount: {
                     type: "number",
-                    description: "Signal Discovery: target number of post engagers/source candidates to scrape. Compute from source target good-fit leads / sampled fit rate; e.g. 150 good fits at 15% fit requires about 1000 engagers. Limits selected posts before starting scrape.",
+                    description: "Signal Discovery: target number of post engagers/source candidates to scrape. Compute from source target good-fit leads / sampled fit rate; e.g. 150 good fits at 15% fit requires about 1000 engagers. If the sampled/projected fit rate is below the 10% planning floor after cleanup, switch to the next provider instead of scaling noisy engagers. Limits selected posts before starting scrape.",
                 },
                 maxPostsToScrape: {
                     type: "number",

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -155,14 +155,17 @@ should be a compact `## Source Recommendation` block with:
 - good-fit target: about 150 prospects after cleanup, enrichment, and filters
 - source-candidate plan: about 1,000 raw engagers using a conservative 15%
   fit-rate assumption unless sampled data supports a different number
+- planning floor: continue with Signal Discovery only when sampled/projected
+  fit is at least 10% after cleanup; below that, move to Sales Nav recent
+  activity instead of scraping noisy engagers
 - review checkpoint: import the first 25 leads for fit and message review
 - a selected-post table with post author/topic, why it fits, and visible
   engagement
 - total visible pool and estimated good-fit pool
 - first pass: build the source list, then import only the review
   batch
-- fallback: switch to Sales Nav recent activity if the review batch is
-  vendor-heavy, agency-heavy, or off-ICP
+- fallback: switch to Sales Nav recent activity if sampled/projected fit falls
+  below 10%, or if the review batch is vendor-heavy, agency-heavy, or off-ICP
 
 When the user has not supplied a source and multiple source angles are viable,
 scout those angles as independent branches when the host can actually do it:

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

@@ -149,6 +149,11 @@ sequential by default. Run `source-scout-linkedin-engagement`,
 `source-scout-sales-nav`, and `source-scout-prospeo-contact` in parallel only
 when the user explicitly requested source comparison, a prior lane failed, or
 the first viable lane is borderline and a cheap fallback check is needed.
+Use a 10% planning floor after conservative cleanup. If Signal Discovery 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
+also falls below 10%, tighten the ICP/source direction instead of inventing
+another provider.
 
 After scouting, show a second approval gate for the concrete source action. For
 Signal Discovery, this gate must say how many selected posts will be scraped,
@@ -158,6 +163,12 @@ approval label must describe the action with the count, such as "Approve
 scraping 3 Signal Discovery posts?" For Sales Nav or Prospeo, the label should
 name the specific search/import lane. Do not call `import_leads` or
 `confirm_lead_list` until this second source-action approval is granted.
+After the user approves this concrete source-action gate, do not show the
+Source Recommendation again and do not ask another source approval question.
+Acknowledge once, then call `import_leads` immediately with the approved source
+math. For Signal Discovery, pass `provider: "signal-discovery"`,
+`targetEngagerCount`, `maxPostsToScrape`, and `confirmed: true`; the tool owns
+moving the watch UI to source-list progress after a lead-list/job id exists.
 
 For Signal Discovery, use this compact source-action approval shape after
 selected posts exist:
@@ -169,6 +180,7 @@ Use Signal Discovery first.
 
 **Good-fit target:** ~150 prospects after cleanup, enrichment, and filters<br>
 **Source-candidate plan:** scrape ~1,000 raw engagers using a conservative 15% fit-rate assumption<br>
+**Planning floor:** continue only when sampled/projected fit is at least 10% after cleanup; below that, switch to Sales Nav recent activity<br>
 **Review checkpoint:** import the first 25 leads into the campaign for fit and message review before scaling<br>
 
 ### Selected posts
@@ -193,8 +205,9 @@ AI-native sales workflows.
 **First pass:** build the source list, then import only the 25-lead review
 batch so we can inspect fit and messages before scaling.
 
-**Fallback:** if the review batch is too vendor-heavy, agency-heavy, or
-off-ICP, switch to Sales Nav recent activity.
+**Fallback:** if sampled/projected fit falls below 10%, or if the review batch
+is too vendor-heavy, agency-heavy, or off-ICP, switch to Sales Nav recent
+activity.
 ```
 
 A source recommendation must show concrete evidence: source lane, filters or

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

@@ -239,9 +239,13 @@ for source approval before import.
 For Signal Discovery, the second gate is not "approve source" in the abstract.
 It is a concrete scrape approval: show a compact `## Source Recommendation`
 with the ~150 good-fit prospect goal, 15% raw-engager assumption, selected-post
-table, total visible pool, estimated good-fit pool, first-pass review
-batch, and fallback. The approval question should be "Approve scraping N Signal
-Discovery posts?"
+table, total visible pool, estimated good-fit pool, 10% planning floor,
+first-pass review batch, and fallback. The approval question should be "Approve
+scraping N Signal Discovery posts?"
+
+That scrape approval is single-use. Once the user approves it, do not replay
+the source card or ask for the same approval again. Acknowledge the approval in
+one sentence and call `import_leads` for the approved source immediately.
 
 ## Parallelism + Naming
 
@@ -253,6 +257,11 @@ borderline and needs a second source to avoid a bad recommendation. The fallback
 order must stay plain: use Sales Nav to find ICP people who are actively posting
 on LinkedIn; if that is not enough, search Sales Nav by titles; if that is still
 not enough, use Prospeo for a broader account/contact path.
+Use a 10% planning floor after conservative cleanup. If Signal Discovery 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
+also falls below 10%, tighten the ICP/source direction instead of inventing
+another provider.
 
 Source-angle comparison should be real, not implied. Call
 `get_source_scout_registry` before dispatching source scouts and use the

package/skills/create-campaign-v2/core/flow.v2.json

@@ -485,6 +485,16 @@
             "signal-discovery": "Approve scraping {selectedPostCount} Signal Discovery posts?",
             "sales-nav": "Import the approved Sales Nav review batch",
             "prospeo": "Import the approved Prospeo review batch"
+          },
+          "postApprovalContract": {
+            "singleUseApproval": true,
+            "doNotRepeatAfterApproval": [
+              "Source Recommendation",
+              "show_source_decision_card",
+              "ask_source_review_choice"
+            ],
+            "requiredNextActionAfterApproval": "acknowledge in one sentence, then call import_leads immediately",
+            "signalDiscoveryNextTool": "import_leads({ campaignOfferId, provider: \"signal-discovery\", targetEngagerCount, maxPostsToScrape, confirmed: true })"
           }
         }
       ],
@@ -925,12 +935,24 @@
             "messageDraftRecommendation"
           ],
           "requiredVisibleLabels": [
-            "Subject:",
-            "Sample prospect fill:",
+            "## Message Template",
+            "## Rendered Example",
+            "Good token fill:",
             "My take:",
-            "Concern:",
             "Question: approve-message or revise-messaging?",
             "Recommendation:"
+          ],
+          "doNotShowByDefault": [
+            "Token Notes",
+            "Good omit / fallback",
+            "Bad fill to avoid",
+            "Token Adherence Table"
+          ],
+          "internalPersistenceOnly": [
+            "Token Fill Rules",
+            "Token Fill Examples",
+            "fallback guidance",
+            "bad-fill avoidance notes"
           ]
         },
         {

package/skills/create-campaign-v2/references/message-review-safety-gate.md

@@ -31,8 +31,11 @@ instead of pulling the long prompt into the main thread.
    local markdown/json artifacts in normal customer runs; emit debug artifacts
    only when the parent explicitly asks for debug/UAT output.
 5. Render the customer-facing message review in chat before asking for approval.
-   After approval, the parent persists template and token rules into campaign
-   state with `update_campaign_brief`.
+   Keep chat lightweight: show the tokenized template and one strong rendered
+   good-fill example only. Do not print the token notes table, omit/fallback
+   example, or bad-fill analysis in chat unless the user explicitly asks.
+   After approval, the parent persists template, token rules, fallback guidance,
+   and bad-fill avoidance notes into campaign state with `update_campaign_brief`.
 6. Ask exactly `approve-message` or `revise-messaging`. Do not import, queue,
    attach sequence, or start before `approve-message`.
 
@@ -89,10 +92,17 @@ but the [topic] thread felt close enough to send`. Otherwise omit the
 - If the message is plausible but not ready to send, set
   `Recommendation: revise-messaging`.
 
+## Internal Message Recommendation
+
+The message scout or parent safety gate should still produce complete internal
+review data: token-fill rules, one rendered omit/fallback example, and bad-fill
+avoidance notes. This data is for campaign-brief persistence and safety checks,
+not for the default chat approval packet.
+
 ## Customer-Facing Message Review
 
 Render this in chat before asking. Use Markdown structure so the approval target
-is visually scannable:
+is visually scannable and low-overhead:
 
 ````markdown
 Status: message-review
@@ -111,33 +121,11 @@ Status: message-review
 {{tokenized_message_body}}
 ```
 
-## Rendered Examples
-
-### Good token fill
-
-Use when the row has a clean, supported fill.
-
-```text
-Subject: ...
-
-Hey First,
-
-...
-```
-
-### Good omit / fallback
-
-Use when a row signal or company context is missing, weak, or awkward.
-
-```text
-Subject: ...
-
-Hey First,
+## Rendered Example
 
-...
-```
+### Example
 
-### Bad fill to avoid
+Good token fill:
 
 ```text
 Subject: ...
@@ -147,14 +135,6 @@ Hey First,
 ...
 ```
 
-**Why this is wrong:** one sentence naming the exact token-fill failure.
-
-## Token Notes
-
-| Token            | Use when                 | Fallback |
-| ---------------- | ------------------------ | -------- |
-| `{{first_name}}` | Clean first name exists. | `there`  |
-
 ## Recommendation
 
 **My take:** ...
@@ -168,15 +148,13 @@ Hey First,
 
 Formatting requirements:
 
-- Put the tokenized template and every rendered example in fenced `text` blocks
+- Put the tokenized template and rendered example in fenced `text` blocks
   so chat gives them a distinct background.
-- `Good token fill` and `Good omit / fallback` must each contain a complete
-  rendered subject + body, not a bullet list of token names or a single
-  bridge-line fragment.
-- Include `Bad fill to avoid` when the row sample has a tempting but unsafe
-  source-mechanics or raw-headline fill; otherwise include `Bad fill to avoid:
-none found`.
-- Use a token notes table, not paragraph-only token notes.
+- The chat example must contain a complete rendered subject + body, not a
+  bullet list of token names or a single bridge-line fragment.
+- Do not show `Good omit / fallback`, `Bad fill to avoid`, or `Token Notes` in
+  the default chat approval packet. Keep those in the internal recommendation
+  and persist them to the campaign brief after approval.
 - Keep reasoning outside the code blocks so the blocks are easy to inspect and
   approve.
 

package/skills/create-campaign-v2/references/step-13-import-leads.md

@@ -57,7 +57,7 @@ Supported branches:
   list from the approved source-capacity plan; it is not the same target as the
   default 25-row campaign review batch.
 - **Supplied LinkedIn profile CSV** — confirm `load_csv_linkedin_leads` only
-  after rubrics and the approved message set are ready. Batch/materialize the
+  after the user approves that supplied-list source. Batch/materialize the
   uploaded CSV into a Sellable lead-list table. Persist the returned
   `leadListId`, then import the bounded review batch into the campaign table
   with
@@ -125,7 +125,9 @@ fallback fit rate is 15%, so the default source-candidate plan is about 1,000
 raw engagers. If the sampled fit rate is stronger or weaker, use the sampled
 rate with a conservative cleanup factor, cap the source candidates at the
 approved provider limit, and select only enough posts to reach that engager
-count. The subsequent
+count. The planning floor is 10% projected fit after cleanup; if Signal
+Discovery falls below that floor, do not import the source list. Route back to
+find-leads and move to Sales Nav recent activity instead. The subsequent
 `confirm_lead_list` call still uses `targetLeadCount: <importLimit>` so only the
 bounded review batch enters the campaign table.
 
@@ -219,8 +221,10 @@ cannot scale further without a new source lane.
 - Zero-imported + zero-skipped ⇒ hard-fail escalate.
 - Zero-imported + high-skipped ⇒ lane-exhausted operator notice (NOT a
   silent proceed).
-- `import_leads` is NOT called before rubrics are saved and the approved message
-  set is synced into the campaign brief.
+- `import_leads` is allowed immediately after the concrete source-action
+  approval. It materializes the source list and then `confirm_lead_list` imports
+  only the bounded review batch. Enrichment, fit scoring, and message cells wait
+  for saved rubrics plus the approved message set.
 - Step 13 MUST reuse an approved source already attached with `campaignOfferId`
   before `import_leads`; it does not replay provider searches.
 - `import_leads` is NOT called again in Step 14 (validate-sample). Full

package/skills/find-leads/SKILL.md

@@ -321,6 +321,9 @@ Use first when the value is in conversation opportunity, competitor engagers, co
 - 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
@@ -384,6 +387,9 @@ Use first when LinkedIn activity plus tighter role / company filters matter.
   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.
@@ -404,6 +410,9 @@ Use first for broad persona expansion, ABM/domain targeting, hiring-led targetin
 - 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.
+- 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.

package/skills/providers/prospeo.md

@@ -63,6 +63,10 @@ search_prospeo({
 - Use `import_leads` with `provider: \"prospeo\"` and the `searchId` to create a lead list and start import.
 - **IMPORTANT:** If `import_leads` returns `needsModeSelection: true`, use `AskUserQuestion` to ask "add to existing leads or replace?" Do NOT assume.
 - Default source target is 300+ good-fit leads, capped at 2,500 source candidates for now.
+- Apply the campaign source planning floor: the sampled/projected good-fit rate
+  after cleanup should be at least 10%. Prospeo is the terminal fallback; if the
+  best reasonable Prospeo lane is still below 10%, tighten the ICP/source
+  direction instead of switching to another provider.
 - After the list finishes and the user confirms it looks good, call `confirm_lead_list` with the `jobId` and the review-batch `targetLeadCount` from the active campaign defaults to import only the review batch into the campaign table.
 - `import_leads` owns the watched move to `confirm-lead-list` after a lead list/job exists.
 - `confirm_lead_list` owns the watched move to `filter-choice` after the bounded review batch exists.

package/skills/providers/sales-nav.md

@@ -96,6 +96,11 @@ Example search name: "Active CXOs at 201-500 companies"
    - < 1,000 = remove a filter or widen criteria
    - > 10,000 = add more filters
 
+   Also apply the campaign source planning floor: the sampled/projected good-fit
+   rate after cleanup should be at least 10%. If the best reasonable Sales Nav
+   lane remains below 10%, do not present it as the winning source; move to
+   Prospeo for broader account/contact coverage.
+
 4. FINAL SEARCH + CONFIRM - Execute winning strategy, ask before saving
 
    - Run the final search with the best filter combination

package/skills/providers/signal-discovery.md

@@ -24,7 +24,7 @@ When the user asks to find posts or start searching, **IMMEDIATELY begin Round 1
 
 <lead_target>
 
-- **Default: provider max import count** (use this unless user specifies otherwise; see `lead-import-limits.json`, currently 250)
+- **Default: provider max import count** (use this unless user specifies otherwise; see `lead-import-limits.json`, currently 2,500)
 - **Maximum: provider max import count**
 - Quality > Quantity: a few hundred active users > 1000 potentially inactive profiles
 - Focus on ACTIVE platform users who will actually see and respond to outreach
@@ -104,6 +104,9 @@ You must estimate:
   - `ceil(targetGoodFitLeads / sampledFitRate)`; for example 15 good-fit
     prospects per 100 engagers means a 150-good-fit source target needs about
     1,000 engagers scraped
+- `planningFloor`
+  - minimum acceptable sampled/projected fit rate after conservative cleanup;
+    default 10%. Below this, do not scale Signal Discovery.
 - `projectedRange`
   - the conservative range implied by the observed sample
 
@@ -130,7 +133,10 @@ Use conservative logic:
    - preferred: "`sampledCount`: 40, `passCount`: 9, `passRate`: ~22%, `goodFitPer100Engagers`: ~22 before cleanup / ~13-16 after cleanup, `requiredEngagersToScrape`: ~940-1,150 for a 150-good-fit target after cleanup, `avgReachableEngagersPerPost`: 240, `goodFitProspectsPerPost`: ~31-38, `postsNeededForTarget`: ~4-5, `recentStrongPostCount`: 15-25, `freshEnoughPostCount`: 8-12, `projectedRange`: 150-190 from selected posts"
    - fallback: "I could not fetch engagers, so this is inferred from post and author quality only"
 5. If the evidence is too weak, say so and return a low-confidence estimate instead of pretending precision.
-6. Do not manually enumerate dozens of engagers in the final answer. Summarize the sample by `sampledCount`, `passCount`, `passRate`, `projectedRange`, and 3-6 representative examples.
+6. If sampled/projected fit after cleanup is below the 10% planning floor,
+   reject the Signal Discovery scrape path and recommend Sales Nav recent
+   activity as the next source.
+7. Do not manually enumerate dozens of engagers in the final answer. Summarize the sample by `sampledCount`, `passCount`, `passRate`, `projectedRange`, and 3-6 representative examples.
 
 </yield_estimation>
 
@@ -389,12 +395,15 @@ recommendation, estimate source capacity from real sample math:
 - average reachable engagers per right-content post
 - expected good-fit leads per selected post after dedupe/cleanup
 - posts needed to reach the target
+- whether sampled/projected fit clears the 10% planning floor
 
 Then select the smallest right-content post set that plausibly hits the source
 target. Do not scrape every promoted sample post by default; promoted sampling
 state and final scrape plan are separate. If the math says the warm post lane
 only supports a smaller first batch, say that and name the Sales Nav or Prospeo
-scale fallback rather than padding the selection with noisy posts.
+scale fallback rather than padding the selection with noisy posts. If the
+sampled/projected fit rate is below 10% after cleanup, do not call
+`import_leads`; move to Sales Nav recent activity.
 
 ```json
 select_promising_posts({

package/skills/research/config.json

@@ -1,9 +0,0 @@
-{
-  "parallelMode": "wide",
-  "agentCount": 6,
-  "maxToolCallsPerAgent": 2,
-  "senderMaxAgents": 2,
-  "senderMaxToolCallsPerAgent": 3,
-  "progressMode": true,
-  "debugMode": true
-}