@sellable/install 0.1.133 → 0.1.135

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 problem].
+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,7 +741,8 @@ 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",
+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
@@ -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
@@ -945,48 +954,44 @@ explicit client prospect identity in the invocation, do one lightweight lookup
 first:
 
 - LinkedIn profile: call \`mcp__sellable__fetch_linkedin_profile\`.
-- Website/domain/company: call \`mcp__sellable__fetch_company\` when possible,
-  otherwise one web lookup.
+- Non-profile URLs or company-page inputs are not enough to start this flow; ask
+  again for the person's LinkedIn profile URL.
 - Existing client prospect id: use it directly and do one company/profile lookup
-  only if a URL/domain is also available.
+  only if a LinkedIn profile URL is also available.
 
 Then summarize what you found in one or two lines and ask the user to confirm
-the current company/focus before continuing, especially if public website data
-may be stale. Do not mention connected sender availability in this confirmation.
+the current company/focus before continuing. Do not mention connected sender
+availability in this confirmation.
 
 If the user did not provide the launch identity, ask in normal chat for the
-LinkedIn profile URL first, with the company website as the fallback. Do not ask
-them to choose an input type with the structured question tool:
+LinkedIn profile URL. Do not ask them to choose an input type with the structured
+question tool:
 
 \`\`\`text
-I’m ready to build this in {workspace}.
-
-What is your LinkedIn profile URL? If you do not have it handy, send your
-company website instead. I’ll research the person and company from that, then
-ask you to correct anything stale before we pick the target, offer, proof, and
-lead source.
+What is your LinkedIn profile URL?
 \`\`\`
 
-After the user pastes a URL/domain, do the lightweight lookup. For a LinkedIn
-profile, call \`mcp__sellable__fetch_linkedin_profile\` and infer the current or
-most recent company from the profile. For a company website, call
-\`mcp__sellable__fetch_company\` when possible, otherwise one web lookup. If a
-LinkedIn profile URL is available, retain it as \`senderLinkedinUrl\` for
-\`create_campaign\`; if a \`clientProspectId\` is available, pass that instead.
+After the user pastes a LinkedIn profile URL, call
+\`mcp__sellable__fetch_linkedin_profile\` and infer the current or most recent
+company from the profile. If they paste a non-profile URL or company page
+instead, ask again for the person's LinkedIn profile URL. Retain the profile URL as
+\`senderLinkedinUrl\` for \`create_campaign\`; if a \`clientProspectId\` is available,
+pass that instead.
 
-After the user confirms the company/focus, run one lightweight company lookup
-if it has not already run, then ask an offer-readiness question before inferred
-strategy hardens:
+After the user confirms the company/focus, ask the full setup intake before
+inferred strategy hardens:
 
 \`\`\`text
-Do you already know the offer for this campaign, should I use the researched
-recommendation, or should we shape the offer together? If the website is stale,
-tell me what is current before I build the brief.
+Who should we target first?
+What offer should this campaign lead with?
+What is the strongest credibility signal we can lead with?
+How should we find prospects: find prospects for me, use a CSV of LinkedIn
+profiles, or use a CSV of company domains?
 \`\`\`
 
 The setup questions should use the confirmed company context so they do not feel
-generic. When you present a recommendation, introduce it as based on the
-research you just did and keep it editable.
+generic. When you present a researched recommendation, introduce it as based on
+the research you just did and keep it editable.
 
 Before the identity gate, use this customer-facing shape:
 
@@ -1371,9 +1376,8 @@ any leads are imported or anything can send.
 Good identity setup:
 
 \`\`\`text
-I’ll ask for the LinkedIn profile URL first, with the company website as a
-fallback. Then I’ll show the researched recommendation and you can correct
-anything stale before we pick the target, offer, proof, and lead source.
+I’ll ask for the LinkedIn profile URL first. Then we’ll confirm who to target,
+what to offer, what proof to lead with, and how to find prospects.
 \`\`\`
 
 Bad:
@@ -1386,8 +1390,8 @@ Better:
 
 \`\`\`text
 I found Christian Reyes connected here. Is that you, and is this campaign for
-Sellable? If not, choose LinkedIn profile or company domain and I’ll ask you to
-paste it in chat.
+Sellable? If not, send the LinkedIn profile URL for the person this campaign is
+for.
 \`\`\`
 
 Bad:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.133",
+  "version": "0.1.135",
   "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 problem].
+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,7 +170,8 @@ 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",
+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
@@ -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
@@ -445,48 +451,44 @@ explicit client prospect identity in the invocation, do one lightweight lookup
 first:
 
 - LinkedIn profile: call `mcp__sellable__fetch_linkedin_profile`.
-- Website/domain/company: call `mcp__sellable__fetch_company` when possible,
-  otherwise one web lookup.
+- Non-profile URLs or company-page inputs are not enough to start this flow; ask
+  again for the person's LinkedIn profile URL.
 - Existing client prospect id: use it directly and do one company/profile lookup
-  only if a URL/domain is also available.
+  only if a LinkedIn profile URL is also available.
 
 Then summarize what you found in one or two lines and ask the user to confirm
-the current company/focus before continuing, especially if public website data
-may be stale. Do not mention connected sender availability in this confirmation.
+the current company/focus before continuing. Do not mention connected sender
+availability in this confirmation.
 
 If the user did not provide the launch identity, ask in normal chat for the
-LinkedIn profile URL first, with the company website as the fallback. Do not ask
-them to choose an input type with the structured question tool:
+LinkedIn profile URL. Do not ask them to choose an input type with the structured
+question tool:
 
 ```text
-I’m ready to build this in {workspace}.
-
-What is your LinkedIn profile URL? If you do not have it handy, send your
-company website instead. I’ll research the person and company from that, then
-ask you to correct anything stale before we pick the target, offer, proof, and
-lead source.
+What is your LinkedIn profile URL?
 ```
 
-After the user pastes a URL/domain, do the lightweight lookup. For a LinkedIn
-profile, call `mcp__sellable__fetch_linkedin_profile` and infer the current or
-most recent company from the profile. For a company website, call
-`mcp__sellable__fetch_company` when possible, otherwise one web lookup. If a
-LinkedIn profile URL is available, retain it as `senderLinkedinUrl` for
-`create_campaign`; if a `clientProspectId` is available, pass that instead.
+After the user pastes a LinkedIn profile URL, call
+`mcp__sellable__fetch_linkedin_profile` and infer the current or most recent
+company from the profile. If they paste a non-profile URL or company page
+instead, ask again for the person's LinkedIn profile URL. Retain the profile URL as
+`senderLinkedinUrl` for `create_campaign`; if a `clientProspectId` is available,
+pass that instead.
 
-After the user confirms the company/focus, run one lightweight company lookup
-if it has not already run, then ask an offer-readiness question before inferred
-strategy hardens:
+After the user confirms the company/focus, ask the full setup intake before
+inferred strategy hardens:
 
 ```text
-Do you already know the offer for this campaign, should I use the researched
-recommendation, or should we shape the offer together? If the website is stale,
-tell me what is current before I build the brief.
+Who should we target first?
+What offer should this campaign lead with?
+What is the strongest credibility signal we can lead with?
+How should we find prospects: find prospects for me, use a CSV of LinkedIn
+profiles, or use a CSV of company domains?
 ```
 
 The setup questions should use the confirmed company context so they do not feel
-generic. When you present a recommendation, introduce it as based on the
-research you just did and keep it editable.
+generic. When you present a researched recommendation, introduce it as based on
+the research you just did and keep it editable.
 
 ### Sufficient Intake Bypass
 
@@ -514,9 +516,9 @@ If the invocation or any later user message explicitly asks for "yolo mode",
 me", "use best estimates", or "just run it", enable YOLO mode for the rest of
 the run. Treat YOLO as `interactionMode: "autonomous"` plus an intake policy:
 
-- If the campaign subject is missing, ask only for the LinkedIn profile URL
-  first, with company website as the fallback, in normal chat; do not ask buyer,
-  offer, proof, source, or filter setup questions before that.
+- If the campaign subject is missing, ask only for the LinkedIn profile URL in
+  normal chat; do not continue from a non-profile URL and do not ask buyer, offer,
+  proof, source, or filter setup questions before the LinkedIn URL.
 - Treat any freeform directions already provided, or added later by the user, as
   operator directions for the rest of the run. If directions conflict, the newest
   user direction wins.
@@ -675,9 +677,7 @@ updates.
        ```text
        You're in — {activeWorkspaceName} workspace, ready to roll.
 
-      Now — what is your LinkedIn profile URL? If you do not have it handy, send your company website instead. I’ll research the person and company from that, then ask you to correct anything stale before we pick the target, offer, proof, and lead source.
-
-      e.g. https://www.linkedin.com/in/client-handle or https://example.com
+      What is your LinkedIn profile URL?
        ```
 
      - If `isReturningUser === false`, prepend ONE line confirming the new
@@ -686,17 +686,14 @@ updates.
        ```text
        You're set up — your {activeWorkspaceName} workspace is ready.
 
-      Now — what is your LinkedIn profile URL? If you do not have it handy, send your company website instead. I’ll research the person and company from that, then ask you to correct anything stale before we pick the target, offer, proof, and lead source.
-
-      e.g. https://www.linkedin.com/in/client-handle or https://example.com
+      What is your LinkedIn profile URL?
        ```
 
      No other lines. No "all set", no "signed in", no other acknowledgement.
 
-     After the user pastes the URL, proceed with the identity-first campaign
-     setup in the v2 subskill prompt. Resolve a LinkedIn profile with
-     `fetch_linkedin_profile`, a company website/domain with `fetch_company`
-     when possible, and mark the client/company research gate with
+     After the user pastes the LinkedIn profile URL, proceed with the
+     identity-first campaign setup in the v2 subskill prompt. Resolve it with
+     `fetch_linkedin_profile` and mark the client/company research gate with
      `complete_sender_research` when that protocol is required.
 
 3. If auth is not OK with `error.type === "workspace"` (token valid, no active