@sellable/install 0.1.129 → 0.1.130

package/bin/sellable-install.mjs

@@ -685,7 +685,7 @@ clear business decisions, tradeoffs, and approval gates. Use product language:
 - "I can create a draft shell for you to watch with approval gates before
   sourcing", not mutation jargon
 
-When explaining lead-source decisions, show the concrete counts behind the
+When explaining source decisions, show the concrete counts behind the
 logic: lanes searched, timeframe, raw result counts, finalist posts or preview
 rows, sampled people, sampled fits as n/N (%), estimated usable people, and the
 confidence basis. Never show a percent like "73% match" without the numerator,
@@ -700,22 +700,27 @@ label it explicitly as not estimated from this run.
 
 Before any provider prompt, search, source scout, or signal-discovery call, show
 one source-plan gate and ask for approval. The plan must be visible before the
-question, and this first approval authorizes scouting/search only. The gate
-should say:
+question, and this first approval only authorizes finding the best places to
+look for buyers. It does not add anyone to the campaign yet. The gate should
+say:
 
 - given this campaign, the viable source options
 - the recommended first lane
 - why that lane fits the buyer, offer, and likely public activity
 - what will be tested next
 - the fallback lane if relevant posts or ICP engagement look thin
-- that approval authorizes scouting/search only, not lead import or sending
+- what approval covers in one concise customer-facing line, such as "This only
+  approves me to look for the best places to find buyers. I won't add leads
+  yet."
 
 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 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\`,
+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" or "source scouting" in customer-facing chat;
+those are internal labels. 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.
@@ -1323,7 +1328,7 @@ campaign is minted, the approved brief should carry forward the token fill
 rules and examples: good fills, good omits, bad fills, fallback rules, and why
 the bad fills are blocked.
 
-For lead-source decisions, confidence comes from concrete counts. Do not say
+For source decisions, confidence comes from concrete counts. Do not say
 "strong sample", "73% match", or "meaningful concentration" without showing the
 sample size and what was counted. Show lanes searched, timeframe, raw results,
 sampled people, sampled fits as n/N (%), estimated usable people, and whether

package/package.json

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

package/skill-templates/create-campaign.md

@@ -110,10 +110,11 @@ 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 positive gate language like "Next gate: selected-post scrape" or
-"Approval covers scouting/search only" instead of long negative lists.
+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
+of internal terms like "source scouting" or long negative lists.
 
-When explaining lead-source decisions, show the concrete counts behind the
+When explaining source decisions, show the concrete counts behind the
 logic: lanes searched, timeframe, raw result counts, finalist posts or preview
 rows, sampled people, sampled fits as n/N (%), estimated usable people, and the
 confidence basis. Never show a percent like "73% match" without the numerator,
@@ -128,22 +129,27 @@ label it explicitly as not estimated from this run.
 
 Before any provider prompt, search, source scout, or signal-discovery call, show
 one source-plan gate and ask for approval. The plan must be visible before the
-question, and this first approval authorizes scouting/search only. The gate
-should say:
+question, and this first approval only authorizes finding the best places to
+look for buyers. It does not add anyone to the campaign yet. The gate should
+say:
 
 - given this campaign, the viable source options
 - the recommended first lane
 - why that lane fits the buyer, offer, and likely public activity
 - what will be tested next
 - the fallback lane if relevant posts or ICP engagement look thin
-- what approval covers in one concise line
+- what approval covers in one concise customer-facing line, such as "This only
+  approves me to look for the best places to find buyers. I won't add leads
+  yet."
 
 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 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`,
+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" or "source scouting" in customer-facing chat;
+those are internal labels. 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.