@sellable/install 0.1.132 → 0.1.134

package/bin/sellable-install.mjs

@@ -714,15 +714,23 @@ to the campaign yet. The gate should say:
   approves me to look for the best places to find buyers. I won't add anyone
   yet."
 
+After brief approval, introduce the step in plain customer language: "Brief
+approved. Next, we'll choose where to find buyers. I won't add anyone yet."
+Do not say "lead-source scouting", "source scouting", or "not importing leads"
+in the customer-facing transition.
+Use this vocabulary ladder: "buyers" means the target market; "people to
+check" means raw reactions/comments before fit is known; "prospects" means
+likely usable people after fit; "leads" means campaign rows.
+
 Use a customer-facing shape like:
 
 \`\`\`text
 ## Find Buyers Plan
 
 I recommend starting with people already talking on LinkedIn about [plain
-topic]. That should help us find buyers who already care about [plain pain].
+topic]. That should help us find people who already care about [plain problem].
 
-I'll check whether there are enough good-fit people there. If not, I'll try
+I'll check whether there are enough likely prospects there. If not, I'll try
 [plain fallback] next.
 
 Approving this means I can look for the best places to find buyers. I won't add
@@ -733,9 +741,10 @@ Do not surface blanket source heuristics as product copy. Make the
 recommendation specific to the campaign. If LinkedIn engagement is recommended,
 name the exact post themes you will search in plain language, such as "Power BI
 dashboards they don't trust" or "teams trying to agree on the right KPIs."
-Avoid using "Signal Discovery", "source scouting", "lane", "provider",
-"precision/scale tradeoff", "evidence quality", "pilot volume", or "ICP" in
-customer-facing chat; those are internal labels. If relevant public
+Avoid using "Signal Discovery", "lead-source scouting", "source scouting",
+"lane", "provider",
+"precision/scale tradeoff", "evidence quality", "pilot volume", "workflow
+pain", or "ICP" in customer-facing chat; those are internal labels. If relevant public
 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\`,
@@ -758,12 +767,12 @@ 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
-LinkedIn engagement (\`signal-discovery\` internally), name how many recommended
-posts will be scraped, the target engager/source-candidate volume, and the
-internal campaign-table execution-slice size. N must be the smallest
+LinkedIn engagement (\`signal-discovery\` internally), use plain language:
+selected posts, people we can check, likely prospects, what the first
+review will inspect, cleanup risk, and fallback. N must be the smallest
 right-content post set that clears the source target, not the default 3
 promoted sample posts. For Sales Nav or Prospeo, name the specific approved
-import lane and source lead count.
+import path and source lead count.
 Do not call \`import_leads\` or \`confirm_lead_list\` until this second approval is
 granted.
 
@@ -782,7 +791,7 @@ the campaign table and return the initial campaign-table execution slice rows.
 For campaign-attached Signal Discovery sampling, promote/select the exact posts
 with \`select_promising_posts\` before \`fetch_post_engagers\` so the user can see
 which posts are being sampled in the watched app. The watch guide should say
-that we are pulling sample engagers from these posts to confirm the ICP is
+that we are checking people from these posts to confirm the right people are
 actually engaging and the source is viable.
 
 Every approval gate must include live campaign access after the readable inline

package/package.json

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

package/skill-templates/create-campaign.md

@@ -110,8 +110,8 @@ clear business decisions, tradeoffs, and approval gates. Use product language:
 Approval and safety copy should be tasteful. State what the current approval
 covers once, in one short sentence, then move on. Do not append repeated
 "nothing starts / no leads import / no sending" disclaimers to routine progress
-updates. Use customer-facing gate language like "Next, we'll find where the
-right buyers are already talking" or "Next gate: selected-post scrape" instead
+updates. Use customer-facing gate language like "Next, we'll choose where to
+find buyers" or "Next gate: selected-post scrape" instead
 of internal terms like "source scouting" or long negative lists.
 
 When explaining source decisions, show the concrete counts behind the
@@ -143,15 +143,23 @@ to the campaign yet. The gate should say:
   approves me to look for the best places to find buyers. I won't add anyone
   yet."
 
+After brief approval, introduce the step in plain customer language: "Brief
+approved. Next, we'll choose where to find buyers. I won't add anyone yet."
+Do not say "lead-source scouting", "source scouting", or "not importing leads"
+in the customer-facing transition.
+Use this vocabulary ladder: "buyers" means the target market; "people to
+check" means raw reactions/comments before fit is known; "prospects" means
+likely usable people after fit; "leads" means campaign rows.
+
 Use a customer-facing shape like:
 
 ```text
 ## Find Buyers Plan
 
 I recommend starting with people already talking on LinkedIn about [plain
-topic]. That should help us find buyers who already care about [plain pain].
+topic]. That should help us find people who already care about [plain problem].
 
-I'll check whether there are enough good-fit people there. If not, I'll try
+I'll check whether there are enough likely prospects there. If not, I'll try
 [plain fallback] next.
 
 Approving this means I can look for the best places to find buyers. I won't add
@@ -162,9 +170,10 @@ Do not surface blanket source heuristics as product copy. Make the
 recommendation specific to the campaign. If LinkedIn engagement is recommended,
 name the exact post themes you will search in plain language, such as "Power BI
 dashboards they don't trust" or "teams trying to agree on the right KPIs."
-Avoid using "Signal Discovery", "source scouting", "lane", "provider",
-"precision/scale tradeoff", "evidence quality", "pilot volume", or "ICP" in
-customer-facing chat; those are internal labels. If relevant public
+Avoid using "Signal Discovery", "lead-source scouting", "source scouting",
+"lane", "provider",
+"precision/scale tradeoff", "evidence quality", "pilot volume", "workflow
+pain", or "ICP" in customer-facing chat; those are internal labels. If relevant public
 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`,
@@ -214,29 +223,26 @@ For LinkedIn engagement, the customer-facing approval card must use the exact
 action shape "Approve scraping N recommended LinkedIn posts?" and the chat
 summary should be a compact `## Source Recommendation` block with:
 
-- 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
+- goal: about 300 likely prospects
+- people to check: use sample math first. If there is no stronger sample, use
+  about 1,500 people who reacted or commented from the 20% starting estimate.
+- good-sign floor: keep LinkedIn posts only when at least 10% of the first
+  sample looks like real prospects; below that, move to active LinkedIn profiles
+  instead of scraping noisy reactions. 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 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
-  headline-fit rate falls below 10%, or if the source sample is vendor-heavy,
-  agency-heavy, or off-ICP
+- first review: after the source list exists, add confirmed source rows to the
+  campaign and review the first 15 leads before scaling
+- a selected-post table with post author/topic, why it fits, public activity,
+  and people we can check
+- total public activity and likely prospect pool
+- next step: build the source list, add it to the campaign, and review the
+  first 15 leads before scaling
+- fallback: switch to active LinkedIn profiles if the first sample is too noisy
+  or has too few prospects
 
 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:
-LinkedIn Engagement / active post engagers (internal `signal-discovery`
+LinkedIn posts / people reacting or commenting (internal `signal-discovery`
 provider prompt), Sales Nav / title + company filters, and Prospeo Contact /
 domains, hiring filters, or broad verified-contact expansion when relevant. In
 Codex, explicitly spawn the named custom scouts
@@ -257,7 +263,7 @@ only an internal approval proof.
 For campaign-attached Signal Discovery sampling, promote/select the exact posts
 with `select_promising_posts` before `fetch_post_engagers` so the user can see
 which posts are being sampled in the watched app. The watch guide should say
-that we are pulling sample engagers from these posts to confirm the ICP is
+that we are checking people from these posts to confirm the right people are
 actually engaging and the source is viable.
 
     After confirmed source rows exist in the campaign table, use the same registry pattern for