@sellable/mcp 0.1.82 → 0.1.84

package/dist/tools/senders.js

@@ -28,7 +28,7 @@ function computeLinkedinProfileUrl(sender) {
 export const senderToolDefinitions = [
     {
         name: "list_senders",
-        description: "List outbound sender identities available in the active workspace. Use this instead of asking for a LinkedIn URL.",
+        description: "List outbound sender identities available in the active workspace. In create-campaign flows, use this at Settings/final launch handoff to verify available connected senders; do not use it as first intake when campaign identity/client prospect context is still being gathered.",
         inputSchema: {
             type: "object",
             properties: {},

package/dist/update-check.js

@@ -77,12 +77,14 @@ function isVersionOutdated(currentVersion, latestVersion) {
     }
     return false;
 }
-function readCache(ttlMs) {
+function readCache(ttlMs, currentVersion) {
     const file = cachePath();
     try {
         const raw = JSON.parse(fs.readFileSync(file, "utf8"));
         if (!raw.checkedAtMs || Date.now() - raw.checkedAtMs > ttlMs)
             return null;
+        if (raw.mcp?.currentVersion !== currentVersion)
+            return null;
         return {
             ...raw,
             cachePath: file,
@@ -157,7 +159,7 @@ export async function checkForUpdates(options) {
         return disabledStatus(currentVersion);
     }
     if (!options?.force) {
-        const cached = readCache(ttlMs);
+        const cached = readCache(ttlMs, currentVersion);
         if (cached)
             return cached;
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.82",
+  "version": "0.1.84",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign/SKILL.md

@@ -81,9 +81,9 @@ instruction loading, file lookup, plugin cache versions, missing linked files,
 or tool discovery. Start in product language:
 
 ```text
-I’ll help you launch this as a Sellable campaign. First I’ll confirm who we’re
-sending from and which company this is for, then I’ll turn that into a campaign
-brief before any leads are imported or anything can send.
+I’ll help you launch this as a Sellable campaign. First I’ll resolve the
+client/company this campaign is for, then I’ll turn that into a campaign brief
+before any leads are imported or anything can send.
 ```
 
 If a linked/local skill file is stale or missing, silently use the installed
@@ -108,6 +108,13 @@ 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,
 denominator, and sample basis.
 
+Do not forecast LinkedIn connection acceptance rates, reply rates, meetings,
+pipeline, revenue, or ROI in customer-facing source reviews unless the user
+supplied verified benchmark data for this exact workspace/sender. Without that
+data, compare sources by source volume, sampled ICP fit, activity/warmth
+signals, cleanup risk, and confidence basis. If a user asks for a forecast,
+label it explicitly as not estimated from this run.
+
 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`
@@ -235,106 +242,56 @@ customer-facing progress copy.
 
 Do not treat the active Sellable workspace as the campaign subject. The
 workspace only tells you where the campaign will be saved. Before buyer, CTA,
-proof, or source questions, identify two things:
-
-1. who/what company this campaign is for, and
-2. who the LinkedIn messages should send from.
+proof, or source questions, identify the campaign identity: the person/profile
+or company this campaign is for, plus enough company/product context to build
+the brief. This is only the client-prospect/bootstrap identity for
+`clientProspectId` or `senderLinkedinUrl`; it is not a connected-sender check.
+
+Do not call `mcp__sellable__list_senders`, `mcp__sellable__get_sender`, or
+surface connected/missing sender state during setup, brief, source, filter, or
+message review. Sender availability belongs only to the Settings/final launch
+handoff after message approval and the 10-lead validation sample.
+
+If the invocation or user answer includes an existing `clientProspectId`, keep
+it as the preferred `create_campaign` identity input. If it includes a LinkedIn
+profile URL, keep that URL as `senderLinkedinUrl` so the backend can
+resolve/materialize the sender prospect when the watchable campaign shell is
+created. Do not require a connected sender before shell creation.
 
 If the user supplied a LinkedIn profile, website, domain, company name, or
-sender name in the invocation, do one lightweight lookup first:
+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.
-- Workspace sender id or known sender: call `mcp__sellable__get_sender` or
-  `mcp__sellable__enrich_sender`.
+- Existing client prospect id: use it directly and do one company/profile lookup
+  only if a URL/domain is also available.
 
 Then summarize what you found in one or two lines and ask the user to confirm
-the campaign subject and sender before continuing.
-
-If the user did not provide the launch identity, quietly call
-`mcp__sellable__list_senders` once if available. This is a shortcut to deduce
-who the user might be from their Sellable API token and connected LinkedIn
-accounts. Do not ask the user to pick an input type before checking connected
-senders. If there is any likely connected sender, use
-`mcp__sellable__enrich_sender` on the best match to infer their current or most
-recent company, then ask a structured confirmation question:
-
-```text
-I’m ready to build this in {workspace}. I found {matched sender} connected here.
-
-Is that you, and is this campaign for {company}?
-```
-
-The structured options must be no more than three choices:
-
-1. `Yes — use {matched sender} for {company}`
-2. `No — I'll paste a LinkedIn profile`
-3. `Use a company domain instead`
-
-If there are multiple likely connected senders, mention the best one in the
-question and use option 2 for either a different connected sender or a pasted
-LinkedIn profile.
-
-Use the structured question tool only for the choice. Do not use
-`request_user_input`/`AskUserQuestion` to collect a LinkedIn URL, company
-domain, or freeform text. If the user chooses option 2, ask in normal chat:
-`Paste the LinkedIn URL I should use, and I’ll look it up.` Then call
-`mcp__sellable__fetch_linkedin_profile`, infer their current or most recent
-company, and confirm company and sender again. If the user chooses option 3, ask
-in normal chat: `Paste the company domain, and I’ll do a quick lookup before we
-keep going.` Then call `mcp__sellable__fetch_company` when possible, otherwise
-one web lookup, and ask who the LinkedIn messages should send from.
-
-If `mcp__sellable__list_senders` returns zero connected senders, avoid the
-sender-confirmation branch entirely. Do not ask the user to choose an input type
-with the structured question tool. Ask in normal chat for the user's LinkedIn
-URL or the company they want to send on behalf of so you can research context:
-
-```text
-I’m ready to build this in {workspace}.
-
-First, paste your LinkedIn URL or the company website you want to send on
-behalf of. I’ll use that to understand the company before we pick the target,
-offer, proof, and lead source.
-```
+the campaign identity/focus before continuing. Do not mention connected sender
+availability in this confirmation.
 
-If there is no strong sender match, do not show a structured choice that says
-"LinkedIn profile" vs "Company website". The point of this gate is not "pick a
-sender" or "pick an input type"; it is to learn who the user is, infer the
-current or most recent company, and then confirm who we are sending from. The
-customer-facing shape should be:
+If the user did not provide the launch identity, ask in normal chat for the
+LinkedIn profile or company website to use as the campaign identity. Do not ask
+them to choose an input type with the structured question tool:
 
 ```text
 I’m ready to build this in {workspace}.
 
-First, what’s your LinkedIn URL? If you’d rather start from the company, paste
-the company website instead.
-```
-
-After the user pastes a URL/domain, do the lightweight lookup. For a LinkedIn profile, call
-`mcp__sellable__fetch_linkedin_profile` and infer the user's current or most
-recent company from the profile. For a company website, call
-`mcp__sellable__fetch_company` when possible, otherwise one web lookup.
-
-If `mcp__sellable__list_senders` did not already run, call it once after the
-lookup to see whether the fetched user appears to match a connected sender. If
-there is a likely match, ask:
-
-```text
-Cool — are you {matched sender}, and is this campaign for {company}?
-```
-
-If there is no likely sender match, ask:
-
-```text
-Cool — I have this campaign as {company}. Who should the LinkedIn messages send from?
+First, paste the LinkedIn profile or company website for the client/company this
+campaign is for. I’ll use that to resolve the campaign identity before we pick
+the target, offer, proof, and lead source.
 ```
 
-Sender options should include connected sender names if available, `same as
-me`, `I’ll paste a different sender profile`, and `Other / custom`.
+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 confirms the subject and sender, run one lightweight company
+After the user confirms the campaign identity, run one lightweight company
 lookup if it has not already run, then ask the campaign setup questions. The
 setup questions should use the confirmed company context so they do not feel
 generic.
@@ -344,12 +301,11 @@ Before the identity gate, use this customer-facing shape:
 ```text
 I’m ready to build the campaign in {workspace}.
 
-First I’ll check whether you already have a connected LinkedIn account here. If
-I can’t confirm it, I’ll ask for your LinkedIn URL or company website and use
-that to understand the company before we choose the target, offer, proof, and
-lead source.
+First I’ll resolve the client/company this campaign is for. I’ll use that
+context to choose the target, offer, proof, and lead source.
 
-Then I’ll turn that into a campaign brief for you to approve before any leads are imported or anything can send.
+Then I’ll turn that into a campaign brief for you to approve before any leads
+are imported or anything can send.
 ```
 
 Do not silently ask Codex intake or approval questions as plain chat when

package/skills/create-campaign-v2/SKILL.md

@@ -9,9 +9,9 @@ visibility: internal
 <role>
 You are the create-campaign-v2 orchestrator. Your job is to execute the
 configured `core/flow.v2.json` state machine from scratch: (1) interview the
-user, resolve sender/company context, and create a watchable campaign shell
-with the v1 brief already attached, (2) use that campaign id for source
-selection, (3) import/confirm the first 10-row review batch to establish
+user, resolve campaign identity/client-prospect context, and create a watchable
+campaign shell with the v1 brief already attached, (2) use that campaign id for
+source selection, (3) import/confirm the first 10-row review batch to establish
 `workflowTableId`, (4) create rubrics and message artifacts from that campaign
 table sample, (5) sync the approved message set into the campaign brief, and
 (6) queue/observe the bounded cascade before settings, sequence, and start.
@@ -20,7 +20,7 @@ table sample, (5) sync the approved message set into the campaign brief, and
 <objective>
 Run the configured JSON flow in durable stages:
 
-0. identity/source intake + watchable campaign shell with v1 brief
+0. client identity/source intake + watchable campaign shell with v1 brief
 1. create-campaign-brief
 2. find leads with the campaign id
 3. import/confirm the first 10-row review batch
@@ -81,8 +81,9 @@ Validated draft directory:
 - Net-new runs start at `bootstrap` -> `brief-interview` in
   `core/flow.v2.json`. Do not start at `validate-artifacts` unless resuming a
   compatibility run where all upstream artifacts already exist.
-- New runs create a watchable campaign shell after sender/company identity,
-  campaign focus, source intake, and the v1 brief are known. The shell is a
+- New runs create a watchable campaign shell after campaign identity/client
+  prospect context, campaign focus, source intake, and the v1 brief are known.
+  The shell is a
   `CampaignOffer` at `currentStep: "create-offer"` with a real v1 brief and a
   `watchUrl`; when the user opens it they should see the brief, not an empty
   campaign. If shell creation fails, stop and surface the error. There is no
@@ -175,104 +176,51 @@ Validated draft directory:
   blocks for review surfaces.
 - Do not treat the active Sellable workspace as the campaign subject. The
   workspace only tells you where the campaign will be saved. Before buyer, CTA,
-  proof, or source questions, identify two things:
-  1. who/what company this campaign is for, and
-  2. who the LinkedIn messages should send from.
+  proof, or source questions, identify the campaign identity: the person/profile
+  or company this campaign is for, plus enough company/product context to build
+  the brief. This is only the client-prospect/bootstrap identity for
+  `clientProspectId` or `senderLinkedinUrl`; it is not a connected-sender check.
+- Do not call `list_senders`, `get_sender`, or surface connected/missing sender
+  state during setup, brief, source, filter, or message review. Sender
+  availability belongs only to the Settings/final launch handoff after
+  `approve-message` and the 10-lead validation sample. The first user-visible
+  sender blocker should be at `awaiting-user-greenlight`/Settings.
+- If the invocation or user answer includes an existing `clientProspectId`, keep
+  it as the preferred `create_campaign` identity input. If it includes a
+  LinkedIn profile URL, keep that URL as `senderLinkedinUrl` so the backend can
+  resolve/materialize the sender prospect when the watchable campaign shell is
+  created. Do not require a connected sender before shell creation.
 - If the user supplied a LinkedIn profile, website, domain, company name, or
-  sender name in the invocation, do one lightweight lookup first:
+  explicit client prospect identity in the invocation, do one lightweight lookup
+  first:
   - LinkedIn profile: call `fetch_linkedin_profile`.
   - Website/domain/company: call `fetch_company` when possible, otherwise one
     web lookup.
-  - Workspace sender id or known sender: call `get_sender` or `enrich_sender`.
+  - Existing client prospect id: use it directly and do one company/profile
+    lookup only if a URL/domain is also available.
     Then summarize what you found in one or two lines and ask the user to confirm
-    the campaign subject and sender before continuing.
-- If the user did not provide the launch identity, quietly call `list_senders`
-  once if available. This is a shortcut to deduce who the user might be from
-  their Sellable API token and connected LinkedIn accounts. Do not ask the user
-  to pick an input type before checking connected senders. If there is any likely
-  connected sender, use `enrich_sender` on the best match to infer their current
-  or most recent company, then ask a structured confirmation question:
-
-  ```text
-  I’m ready to build this in {workspace}. I found {matched sender} connected here.
-
-  Is that you, and is this campaign for {company}?
-  ```
-
-  The structured options must be no more than three choices:
-
-  1. `Yes — use {matched sender} for {company}`
-  2. `No — I'll paste a LinkedIn profile`
-  3. `Use a company domain instead`
-
-  If there are multiple likely connected senders, mention the best one in the
-  question and use option 2 for either a different connected sender or a pasted
-  LinkedIn profile.
-
-  Use the structured question tool only for the choice. Do not use
-  `request_user_input`/`AskUserQuestion` to collect a LinkedIn URL, company
-  domain, or freeform text. If the user chooses option 2, ask in normal chat:
-  `Paste the LinkedIn URL I should use, and I’ll look it up.` Then call
-  `fetch_linkedin_profile`, infer their current or most recent company, and
-  confirm company and sender again. If the user chooses option 3, ask in normal
-  chat: `Paste the company domain, and I’ll do a quick lookup before we keep
-  going.` Then call `fetch_company` when possible, otherwise one web lookup, and
-  ask who the LinkedIn messages should send from.
-
-  If `list_senders` returns zero connected senders, avoid the sender-confirmation
-  branch entirely. Do not ask the user to choose an input type with the
-  structured question tool. Ask in normal chat for the user's LinkedIn URL or the
-  company they want to send on behalf of so you can research context:
-
-  ```text
-  I’m ready to build this in {workspace}.
-
-  First, paste your LinkedIn URL or the company website you want to send on
-  behalf of. I’ll use that to understand the company before we pick the target,
-  offer, proof, and lead source.
-  ```
-
-  If there is no strong sender match, do not show a structured choice that says
-  "LinkedIn profile" vs "Company website". The point of this gate is not "pick a
-  sender" or "pick an input type"; it is to learn who the user is, infer the
-  current or most recent company, and then confirm who we are sending from. The
-  customer-facing shape should be:
+    the campaign identity/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 or company website to use as the campaign identity. Do not ask
+  them to choose an input type with the structured question tool:
 
   ```text
   I’m ready to build this in {workspace}.
 
-  First, what’s your LinkedIn URL? If you’d rather start from the company, paste
-  the company website instead.
-  ```
-
-  After the user pastes a URL/domain, do the lightweight lookup. For a LinkedIn profile, call
-  `fetch_linkedin_profile` and infer the user's current or most recent company
-  from the profile. For a company website, call `fetch_company` when possible,
-  otherwise one web lookup.
-
-  If `list_senders` did not already run, call it once after the lookup to see
-  whether the fetched user appears to match a connected sender. If there is a
-  likely match, ask:
-
-  ```text
-  Cool — are you {matched sender}, and is this campaign for {company}?
-  ```
-
-  If there is no likely sender match, ask:
-
-  ```text
-  Cool — I have this campaign as {company}. Who should the LinkedIn messages send from?
+  First, paste the LinkedIn profile or company website for the client/company
+  this campaign is for. I’ll use that to resolve the campaign identity before we
+  choose the target, offer, proof, and lead source.
   ```
 
-  Sender options should include connected sender names if available, `same as
-me`, `I’ll paste a different sender profile`, and `Other / custom`.
-  When the answer can be represented as choices, ask it with the host-native
-  structured question gate. Do not render sender or campaign-focus choices as a
-  numbered plain-chat list in interactive Claude Code or Codex. Plain chat is
-  only for free-text values like a pasted LinkedIn URL, company domain, CSV
-  path, or custom explanation.
+  After the user pastes a URL/domain, do the lightweight lookup. For a LinkedIn
+  profile, call `fetch_linkedin_profile` and infer the current or most recent
+  company from the profile. For a company website, call `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 confirms the subject and sender, check whether the company
+  After the user confirms the campaign identity, check whether the company
   context implies more than one campaignable product line, service, or offer.
   If so, ask one structured campaign-focus question before the setup packet
   (for example, "Which Sellable offer is this campaign for?") with no more than
@@ -296,12 +244,11 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   ```text
   I’m ready to build the campaign in {workspace}.
 
-  First I’ll check whether you already have a connected LinkedIn account here.
-  If I can’t confirm it, I’ll ask for your LinkedIn URL or company website and
-  use that to understand the company before we choose the target, offer, proof,
-  and lead source.
+  First I’ll resolve the client/company this campaign is for. I’ll use that
+  context to choose the target, offer, proof, and lead source.
 
-  Then I’ll turn that into a campaign brief for you to approve before anything is created.
+  Then I’ll turn that into a campaign brief for you to approve before any leads
+  are imported or anything can send.
   ```
 
 - Fast Intake Mode is mandatory for hosted/rehearsal net-new runs. Ask the
@@ -315,15 +262,15 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   generating setup options. If the user supplied a LinkedIn profile URL, call
   `fetch_linkedin_profile` before generating setup options. Do not infer the
   product category from the company name alone. If no domain, website, LinkedIn
-  profile, or sender identity is supplied, the first structured question gate
-  must ask for the launch identity before buyer/offer/source. Before that first
+  profile, or client identity is supplied, ask in normal chat for that identity
+  before buyer/offer/source. Before the first strategy/source packet,
+  `list_senders` is forbidden; sender availability is checked only at Settings.
+  Before that first
   structured question gate, do not run source discovery, Sales Nav, Prospeo,
   Signals, Bash, Read, Write, Edit, Glob, Grep, full company research, or
-  draft-directory inspection/creation. `list_senders` is allowed once before the
-  first identity gate as a quiet token/sender inference shortcut, and once means
-  once: do not call it again after a LinkedIn lookup if it already ran. Do
-  draft-directory setup only after the founder answers. After launch identity,
-  sender, and any ambiguous campaign focus are confirmed, the setup packet must
+  draft-directory inspection/creation. Do draft-directory setup only after the
+  founder answers. After launch identity and any ambiguous campaign focus are
+  confirmed, the setup packet must
   use the structured question gate and ask buyer, offer/CTA, proof, and lead
   source. All four questions must include an `Other / custom` option.
 - After the founder answers the first strategy/source packet, explain the next
@@ -433,11 +380,11 @@ brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
   finish the write synchronously at that boundary.
 
 - After the brief is approved or auto-confirmed, show the next progress line:
-  `Cool. Now I'm going to find people who are both a good fit and likely to
-reply on LinkedIn. I'll compare source paths by expected volume, likely
-connection acceptance rate, likely reply rate, signal quality, and tradeoffs.
-This usually takes ~3-5 min, and I'll show you the source decision + sample
-before anything goes live.`
+  `Cool. Now I'm going to find people who are both a good fit and active enough
+to be worth a LinkedIn test. I'll compare source paths by expected volume,
+sampled ICP fit, activity/warmth signal, cleanup risk, and tradeoffs. This
+usually takes ~3-5 min, and I'll show you the source decision + sample before
+anything goes live.`
 - After the lead sample/source decision is ready and approved or auto-confirmed,
   show the next progress line:
   `Lead source is set. I'll import the first 10-row review batch into the
@@ -828,9 +775,13 @@ usable leads`.
 - preview count
 - ICP match rate with numerator/denominator and sample basis; never percent-only
 - volume comparison
-- expected LinkedIn funnel: likely connection acceptance range, likely reply
-  range, and whether the estimate is sample-backed, historical, founder-supplied,
-  or directional
+- source viability: expected source volume, expected usable leads after
+  filtering, source activity/warmth indicators, cleanup risk, and confidence
+  basis
+- do not forecast connection acceptance, reply rate, meetings, pipeline,
+  revenue, or ROI unless the user supplied verified benchmark data for this
+  exact workspace/sender. If no verified benchmark exists, state that
+  performance is not estimated from this source review.
 - for Signals-first paths: top candidate posts reviewed, selected post URLs,
   post author, post topic/excerpt, post age or posted date, engagement count,
   sampled engager count per selected post, sampled fit count per selected post,
@@ -854,7 +805,7 @@ customer-visible sections with literal headings:
 - `## Source Decision`
 - `## Evidence Snapshot`
 - `## Selected Signal Posts` for Signals-first campaigns
-- `## Expected LinkedIn Funnel`
+- `## Source Viability`
 - `## Sample Leads` for Signals-first campaigns
 - `## Pros`
 - `## Tradeoffs`
@@ -888,10 +839,11 @@ For Signals-first campaigns, `## Sample Leads` must group representative sample
 rows by source post when possible, so the user can see not just that the search
 found posts, but which posts produce believable prospects.
 
-`## Expected LinkedIn Funnel` must include expected source volume, expected
-usable leads after filtering, likely connection acceptance range, likely reply
-range, and estimate basis. If exact performance data is unavailable, use a
-directional range and label it `directional`, not definitive.
+`## Source Viability` must include expected source volume, expected usable
+leads after filtering, source activity/warmth indicators, cleanup risk, and
+estimate basis. Do not include likely connection acceptance or reply-rate
+ranges unless verified benchmark data was supplied by the user for this exact
+workspace/sender.
 
 When showing `lead-review.md` to the user, render a slim decision summary in
 chat, not the full evidence table. Use rendered Markdown directly with short
@@ -911,7 +863,8 @@ user-facing lead review. The visible response must include:
 - `Why it won`
 - `Quick numbers` as bullet points, with one provider/source angle per bullet.
   Each bullet must include raw volume, sampled fit rate as `n/N`, estimated
-  good-fit range after cleanup, and expected reply-rate range when available.
+  good-fit range after cleanup, source activity/warmth basis, and confidence
+  note.
 - If Signals was searched or considered, `Signal keyword lanes` as a compact
   table with keyword lane, timeframe, posts found, and finalist posts reviewed.
 - If Signals was searched or considered, `LinkedIn posts sampled` as a compact

package/skills/create-campaign-v2/core/flow.v2.json

@@ -475,13 +475,13 @@
         {
           "action": "render_find_leads_progress",
           "requiredVisibleContent": [
-            "good fit and likely to reply on LinkedIn",
+            "good fit and active enough to be worth a LinkedIn test",
             "campaign source step",
             "primary source",
             "expected volume",
-            "likely connection acceptance rate",
-            "likely reply rate",
-            "signal quality",
+            "sampled ICP fit",
+            "activity/warmth signal",
+            "cleanup risk",
             "tradeoffs",
             "search lanes",
             "timeframe",
@@ -639,7 +639,6 @@
             "sampled fits as n/N (%)",
             "estimated usable people",
             "estimated good-fit range after cleanup",
-            "expected reply-rate range",
             "confidence note"
           ],
           "sourceDecisionRequiredFields": [
@@ -668,7 +667,7 @@
           "artifactLinkTiming": "before_next_step_or_revision_question",
           "doNotCompressToSummaryOnly": false,
           "doNotRenderArtifactLinksOnly": true,
-          "chatRenderRule": "Show a slim rendered-Markdown decision summary only, never a fenced code block. The first sentence must make the decision explicit: 'I recommend {primary source} using {exact filter/source recipe}. The runner-up is {source} because {reason}.' Use indexed sections and short bullets: recommendation, Primary source and filters, Runner-up sources, why it won, Quick numbers with one provider/source angle per bullet, raw volume, sampled fit rate as n/N, estimated good-fit range after cleanup, expected reply rate range, 3-5 representative sample leads, and one tradeoff. If Signals was searched or considered, include two compact inline Markdown tables before the recommendation is treated as final: Signal keyword lanes with keyword lane, timeframe, posts found, and finalist posts reviewed; and LinkedIn posts sampled with post URL/title, author/topic, age, engagers, sampled engagers, good fits as n/N, estimated usable prospects per post, and use/discard decision. Default to selecting a few promising Signals posts for the first sample instead of trying to prove full Signals scale up front; if the sample is good but volume is low, say how many more posts to add/scrape next. Do not skip or discard Signals based only on raw post count or vibes; show the post-level math first, or explicitly say no engagers could be fetched and lower confidence. Keep discarded paths, full sample rows, and lead-sample.json details in lead-review.md. Do not show plain filesystem paths unless links cannot be created."
+          "chatRenderRule": "Show a slim rendered-Markdown decision summary only, never a fenced code block. The first sentence must make the decision explicit: 'I recommend {primary source} using {exact filter/source recipe}. The runner-up is {source} because {reason}.' Use indexed sections and short bullets: recommendation, Primary source and filters, Runner-up sources, why it won, Quick numbers with one provider/source angle per bullet, raw volume, sampled fit rate as n/N, estimated good-fit range after cleanup, activity/warmth basis, confidence note, 3-5 representative sample leads, and one tradeoff. Do not forecast connection acceptance rates, reply rates, meetings, pipeline, revenue, or ROI unless the user supplied verified benchmark data for this exact workspace/sender. If Signals was searched or considered, include two compact inline Markdown tables before the recommendation is treated as final: Signal keyword lanes with keyword lane, timeframe, posts found, and finalist posts reviewed; and LinkedIn posts sampled with post URL/title, author/topic, age, engagers, sampled engagers, good fits as n/N, estimated usable prospects per post, and use/discard decision. Default to selecting a few promising Signals posts for the first sample instead of trying to prove full Signals scale up front; if the sample is good but volume is low, say how many more posts to add/scrape next. Do not skip or discard Signals based only on raw post count or vibes; show the post-level math first, or explicitly say no engagers could be fetched and lower confidence. Keep discarded paths, full sample rows, and lead-sample.json details in lead-review.md. Do not show plain filesystem paths unless links cannot be created."
         },
         {
           "action": "render_post_lead_parallel_progress",

package/skills/create-campaign-v2/references/lead-validation-preview.md

@@ -95,7 +95,7 @@ Use a compact markdown report with these sections:
 - Preview Count: {n}
 - ICP Match Rate: {x/y or % if supportable}
 - Volume Comparison: above target | in range | below target
-- Expected LinkedIn Funnel: connection acceptance {range}, reply {range}, estimate basis {sample-backed | historical | founder-supplied | directional}
+- Source Viability: source volume {n or range}, usable leads after filtering {n or range}, activity/warmth basis {sample-backed | directional | needs more sample}, cleanup risk {low | medium | high}
 
 ## Source Decision
 
@@ -108,13 +108,13 @@ Use a compact markdown report with these sections:
 - Approval Meaning: approving this source means {what will be sampled/imported
   next}
 
-## Expected LinkedIn Funnel
+## Source Viability
 
 - Source Volume: {n or range}
 - Expected Usable Leads After Filtering: {n or range}
-- Likely Connection Acceptance: {range}
-- Likely Reply Rate: {range}
-- Estimate Basis: sample-backed | historical | founder-supplied | directional
+- Activity/Warmth Basis: sample-backed | directional | needs more sample
+- Cleanup Risk: low | medium | high
+- Performance Forecast: not estimated unless the user supplied verified benchmark data for this exact workspace/sender
 
 ## Signal Keyword Lanes
 

package/skills/create-campaign-v2/references/validation-criteria.md

@@ -114,9 +114,12 @@ Lead preview must:
 - preview count
 - ICP match rate
 - volume comparison
-- expected LinkedIn funnel: likely connection acceptance range, likely reply
-  range, and whether the estimate is sample-backed, historical, founder-supplied,
-  or directional
+- source viability: expected source volume, expected usable leads after
+  filtering, source activity/warmth indicators, cleanup risk, and confidence
+  basis
+- no connection acceptance, reply-rate, meeting, pipeline, revenue, or ROI
+  forecast unless the user supplied verified benchmark data for this exact
+  workspace/sender
 - source decision: best path, why it won, pros, cons/tradeoffs, and discarded
   source paths with the reason each lost
 - false-positive patterns
@@ -126,15 +129,16 @@ For normal LinkedIn discovery, `lead-review.md` must include literal
 customer-visible headings:
 
 - `## Source Decision`
-- `## Expected LinkedIn Funnel`
+- `## Source Viability`
 - `## Pros`
 - `## Tradeoffs`
 - `## Discarded Paths`
 
-`## Expected LinkedIn Funnel` must include expected source volume, expected
-usable leads after filtering, likely connection acceptance range, likely reply
-range, and estimate basis. If exact performance data is unavailable, use a
-directional range and label it `directional`, not definitive.
+`## Source Viability` must include expected source volume, expected usable
+leads after filtering, source activity/warmth indicators, cleanup risk, and
+estimate basis. Do not include likely connection acceptance or reply-rate
+ranges unless verified benchmark data was supplied by the user for this exact
+workspace/sender.
 
 `lead-sample.json` must include enough structured lead data for downstream
 filtering:

package/skills/find-leads/SKILL.md

@@ -343,10 +343,13 @@ Use first when LinkedIn activity plus tighter role / company filters matter.
 - For InMail or LinkedIn-send motions, establish the baseline TAM first, then test a `POSTED_ON_LINKEDIN` slice when the pool can still sustain a campaign.
 - Treat recent posters as a preferred first-send slice, not just a nice-to-have proxy. When the recently-posted slice still yields enough projected good fits, prefer it because reply / acceptance performance is usually materially better than the cold full-TAM pool.
 - When explaining a LinkedIn source decision, make the buying logic obvious:
-  pick people who are both good fits and likely to reply. Compare source paths
-  by expected volume, likely connection acceptance, likely reply rate, signal
-  quality, and tradeoffs. Use sample-backed or historical numbers when
-  available; otherwise label ranges as directional.
+  pick people who are good fits and active enough to be worth a LinkedIn test.
+  Compare source paths by expected volume, sampled ICP fit, activity/warmth
+  signal, cleanup risk, and tradeoffs.
+- Do not forecast connection acceptance rates, reply rates, meetings, pipeline,
+  revenue, or ROI unless the user supplied verified benchmark data for this
+  exact workspace/sender. Without that data, say performance is not estimated
+  from the source review.
 - Use these rough planning bands only as directional defaults when better
   workspace/founder data is not available: Signals/recent engagers = lower
   volume, higher reply upside; Sales Nav with recent LinkedIn activity = medium