@sellable/install 0.1.134 → 0.1.136

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

@@ -120,9 +120,15 @@ blocker.
   Do not write `saw you {{engagement_context}} on {{post_context}}`, `saw you
 reacted to`, `saw you engaging with`, or equivalent source-citation copy as a
   default hook. Only refer to engagement when the line is self-aware and
-  low-certainty, for example: `not sure if this is too specific, but the
-[topic] thread felt close enough to send`. Otherwise omit the engagement
-  signal and use role/company/problem context.
+  low-certainty, for example: `you might not remember the thread, but I found
+you through a [topic] discussion and your [observable role/company context]
+looked close to [problem]`. Otherwise omit the engagement signal and use
+  role/company/problem context.
+- Do not describe the sender in third person inside the outbound message.
+  Lines like `p.s. Saju's angle is...`, `Christian's angle is...`, or
+  `[sender]'s approach is...` are internal notes leaking into copy. If the point
+  matters, write it in the sender's voice: `p.s. we usually pair the build with
+enablement`, or omit it.
 - The selected winner is one first outbound send only. No post-accept DM,
   follow-up, cadence branch, sequence copy, or launch copy.
 

package/bin/sellable-install.mjs

@@ -954,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:
 
@@ -1380,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:
@@ -1395,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.134",
+  "version": "0.1.136",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-campaign.md

@@ -451,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
 
@@ -520,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.
@@ -681,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
@@ -692,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