@sellable/install 0.1.119 → 0.1.121

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

@@ -51,14 +51,15 @@ currentStep: "signal-discovery" })` before sampling so the watched Signal
    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 150 for Signal Discovery unless the parent supplies a target),
-   reachable engagers,
-   sampled ICP-fit rate as `n/N` plus an easy percentage/range, expected usable
-   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, posts needed to hit the target, and
-   whether sampled/projected fit clears the 10% planning floor.
+   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. 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.
@@ -72,12 +73,12 @@ Return a concise structured result with:
 - `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, 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, whether the 10% planning floor clears after cleanup, selected post
-  count, internal campaign-table execution-slice size, expected usable lead range, and scale
-  fallback
+  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`
@@ -93,14 +94,18 @@ Evidence standards:
   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 looked in-ICP, how many good-fit prospects
-  that implies per 100 engagers, how many usable prospects one right-content
-  post should yield after cleanup, how many engagers must be scraped for the
-  300-good-fit source target at the 20% working assumption, 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.
+  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+ 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.
+- 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/bin/sellable-install.mjs

@@ -655,10 +655,12 @@ should say:
 - that approval authorizes scouting/search only, not lead import or sending
 
 Do not surface blanket source heuristics as product copy. Make the
-recommendation specific to the campaign. If Signal Discovery is recommended,
-name the exact post themes you will search. If relevant public conversations
-look unlikely, recommend the specific Sales Nav or Prospeo lane instead and say
-why. Do not call \`search_signals\`, \`search_sales_nav\`, \`search_prospeo\`,
+recommendation specific to the campaign. If LinkedIn engagement is recommended,
+name the exact post themes you will search and avoid using "Signal Discovery" in
+customer-facing chat; that is the internal provider/app label. If relevant
+public conversations look unlikely, recommend the specific Sales Nav or Prospeo
+lane instead and say why. 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.
 
@@ -677,9 +679,10 @@ precision, and referral paths, but it does not provide hiring-by-role filters;
 say that distinction plainly in the source-plan gate.
 
 After scouting, ask for a second approval on the concrete source action. For
-Signal Discovery, name how many selected posts will be scraped, the target
-engager/source-candidate volume, and the internal campaign-table execution-slice
-size. For Sales Nav or Prospeo, name the specific approved import lane and source lead count.
+LinkedIn engagement (\`signal-discovery\` internally), name how many selected
+posts will be scraped, the target engager/source-candidate volume, and the
+internal campaign-table execution-slice size. For Sales Nav or Prospeo, name the
+specific approved import lane and source lead count.
 Do not call \`import_leads\` or \`confirm_lead_list\` until this second approval is
 granted.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.119",
+  "version": "0.1.121",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-campaign.md

@@ -139,10 +139,12 @@ should say:
 - what approval covers in one concise line
 
 Do not surface blanket source heuristics as product copy. Make the
-recommendation specific to the campaign. If Signal Discovery is recommended,
-name the exact post themes you will search. If relevant public conversations
-look unlikely, recommend the specific Sales Nav or Prospeo lane instead and say
-why. Do not call `search_signals`, `search_sales_nav`, `search_prospeo`,
+recommendation specific to the campaign. If LinkedIn engagement is recommended,
+name the exact post themes you will search and avoid using "Signal Discovery" in
+customer-facing chat; that is the internal provider/app label. If relevant
+public conversations look unlikely, recommend the specific Sales Nav or Prospeo
+lane instead and say why. 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.
 
@@ -161,10 +163,11 @@ precision, and referral paths, but it does not provide hiring-by-role filters;
 say that distinction plainly in the source-plan gate.
 
     After scouting, ask for a second approval on the concrete source action. For
-    Signal Discovery, name how many selected posts will be scraped and the
-    target engager/source-candidate volume. For Sales Nav or Prospeo, name the
-    specific approved import lane and source lead count. Keep the internal
-    15-row campaign-table execution slice separate from source sampling.
+    LinkedIn engagement (`signal-discovery` internally), name how many selected
+    posts will be scraped and the target engager/source-candidate volume. For
+    Sales Nav or Prospeo, name the specific approved import lane and source lead
+    count. Keep the internal 15-row campaign-table execution slice separate from
+    source sampling.
 
 Do not call `import_leads` or `confirm_lead_list` until this second approval is
 granted.
@@ -181,26 +184,29 @@ granted.
     should `confirm_lead_list({ reviewBatchLimit: 15 })` copy confirmed rows into
     the campaign table and return the initial campaign-table execution slice rows.
 
-For Signal Discovery, the customer-facing approval card must use the exact
-action shape "Approve scraping N Signal Discovery posts?" and the chat summary
+For LinkedIn engagement, the customer-facing approval card must use the exact
+action shape "Approve scraping N selected LinkedIn posts?" and the chat summary
 should be a compact `## Source Recommendation` block with:
 
-- goal: about 300 good-fit prospects after cleanup, enrichment, and filters
-- source-candidate plan: about 1,500 raw engagers using a 20% working 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
+- goal: about 300 headline-fit prospects from relevant LinkedIn engagement
+- source-candidate plan: use sample math first: target headline-fit prospects
+  divided by sampled headline-pass rate. If there is no stronger sample, use
+  about 1,500 raw engagers from the 20% working headline-pass assumption.
+- planning floor: continue with LinkedIn engagement only when sampled/projected
+  headline-fit rate is at least 10%; below that, move to Sales Nav recent
+  activity instead of scraping noisy engagers. Do not use the 10% floor as the
+  scrape-count denominator when the actual sample rate is higher.
 - campaign setup checkpoint: after the source list exists, copy confirmed source rows
   into the campaign and internally process the first execution slice for fit and message setup
 - a selected-post table with post author/topic, why it fits, and visible
   engagement
-- total visible pool and estimated good-fit pool
+- total visible pool and estimated headline-fit pool
 - first pass: build the source list and copy all confirmed source rows into the
   campaign; the campaign table then internally processes its first execution
   slice before scaling
-- fallback: switch to Sales Nav recent activity if sampled/projected fit falls
-  below 10%, or if the source sample is vendor-heavy, agency-heavy, or off-ICP
+- fallback: switch to Sales Nav recent activity if sampled/projected
+  headline-fit rate falls below 10%, or if the source sample 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: