@sellable/mcp 0.1.83 → 0.1.85

package/dist/tools/campaigns.js

@@ -124,8 +124,8 @@ export const campaignToolDefinitions = [
     {
         name: "create_campaign",
         description: 'Create a new campaign offer OR resume an existing one. Low-level write tool: load create-campaign workflow instructions first via get_subskill_prompt({ subskillName: "create-campaign" }) (or bootstrap_create_campaign + nextStep). If campaignId is provided, this tool returns the watchUrl + state for that campaign instead of creating a new campaign.\n\n' +
-            "INPUTS:\n- Pass either `clientProspectId` (preferred) or `senderLinkedinUrl` for net-new campaigns.\n- `clientProspectId` is the EnrichedProspect row ID for the campaign sender, used by ICP scoring, message generation, and brief rendering.\n- `senderLinkedinUrl` may be passed when `clientProspectId` is not yet materialized; the backend will attempt to resolve a sender prospect from it.\n\n" +
-            "PREREQUISITES:\n- If you provide `senderLinkedinUrl`, it is used as a sender bootstrap signal.\n- `clientProspectId` is optional when sender URL is available and allows a direct materialized sender context.\n- `clientProspectId` is preferred for deterministic sender resolution.",
+            "INPUTS:\n- Pass either `clientProspectId` (preferred) or `senderLinkedinUrl` for net-new campaigns.\n- `clientProspectId` is the EnrichedProspect row ID for the campaign identity/client prospect, used by ICP scoring, message generation, and brief rendering.\n- `senderLinkedinUrl` may be passed when `clientProspectId` is not yet materialized; the backend will attempt to resolve a campaign identity prospect from it.\n\n" +
+            "PREREQUISITES:\n- If you provide `senderLinkedinUrl`, it is used as a campaign identity bootstrap signal, not as a connected-sender availability check.\n- `clientProspectId` is optional when sender URL is available and allows a direct materialized campaign identity context.\n- `clientProspectId` is preferred for deterministic campaign identity resolution.",
         inputSchema: {
             type: "object",
             properties: {
@@ -139,13 +139,13 @@ export const campaignToolDefinitions = [
                 },
                 clientProspectId: {
                     type: "string",
-                    description: "Use this for existing sender prospects. For brand-new senders, pass `senderLinkedinUrl` and the backend will attempt sender lookup/creation during campaign creation.",
+                    description: "Use this for existing campaign identity/client prospect rows. For brand-new campaign identities, pass `senderLinkedinUrl` and the backend will attempt prospect lookup/creation during campaign creation.",
                 },
                 // `senderLinkedinUrl` (not `linkedinUrl`) to disambiguate from
                 // prospect-side `linkedinUrl` fields used in other tools (research-prospect etc.).
                 senderLinkedinUrl: {
                     type: "string",
-                    description: "Optional sender LinkedIn profile URL. Use when sender prospect ID is not yet materialized and backend bootstrap should be used.",
+                    description: "Optional campaign identity LinkedIn profile URL. Use when the client prospect ID is not yet materialized and backend bootstrap should be used.",
                 },
                 offerPositioning: {
                     type: "object",
@@ -623,7 +623,7 @@ export async function createCampaign(input) {
             `or all create fields. Missing: ${missing.join(", ")}.\n\n` +
             "Remediation:\n" +
             '- For full workflow, call get_subskill_prompt({ subskillName: "create-campaign" }) and follow it.\n' +
-            "- For net-new campaign creation: run the `research-sender` flow first, call `complete_sender_research`, then pass either `clientProspectId` (preferred) or `senderLinkedinUrl` and let the backend resolve sender context at campaign creation time.\n" +
+            "- For net-new campaign creation: run the `research-sender` flow first as campaign identity/client prospect research, call `complete_sender_research`, then pass either `clientProspectId` (preferred) or `senderLinkedinUrl` and let the backend resolve campaign identity context at campaign creation time.\n" +
             "- For resume, call create_campaign with campaignId only.");
     }
     assertNetNewCreateCampaignResearchReady();

package/dist/tools/flow-preflight.js

@@ -88,21 +88,21 @@ export function assertResearchPromptLoaded(mode = "any") {
         };
     }
     if (mode === "sender") {
-        throw new Error('FLOW_PRECONDITION: net-new create_campaign requires sender research preload. Call get_subskill_prompt({ subskillName: "research-sender" }) and run sender research before create_campaign.');
+        throw new Error('FLOW_PRECONDITION: net-new create_campaign requires campaign identity research preload. Call get_subskill_prompt({ subskillName: "research-sender" }) and run client/company prospect research before create_campaign.');
     }
     throw new Error("FLOW_PRECONDITION: research preload missing. Call get_subskill_prompt with the matching research wrapper (research-sender or research-prospect), then run research before continuing.");
 }
 export function assertNetNewCreateCampaignResearchReady() {
     const senderResearchPromptState = researchPromptStates.sender;
     if (!senderResearchPromptState) {
-        throw new Error('FLOW_PRECONDITION: net-new create_campaign requires sender research preload. Call get_subskill_prompt({ subskillName: "research-sender" }) and run sender research before create_campaign.');
+        throw new Error('FLOW_PRECONDITION: net-new create_campaign requires campaign identity research preload. Call get_subskill_prompt({ subskillName: "research-sender" }) and run client/company prospect research before create_campaign.');
     }
     if (!senderResearchCompletionState) {
-        throw new Error("FLOW_PRECONDITION: completed sender research is required before create_campaign. After running research-sender (parallel batch of fetch_linkedin_profile + fetch_company + WebSearches), call complete_sender_research({ depth, proofItemsFound, caseStudyItemsFound, credibilitySignalsFound, notes? }).");
+        throw new Error("FLOW_PRECONDITION: completed campaign identity research is required before create_campaign. After running research-sender for client/company prospect context (parallel batch of fetch_linkedin_profile + fetch_company + WebSearches), call complete_sender_research({ depth, proofItemsFound, caseStudyItemsFound, credibilitySignalsFound, notes? }).");
     }
     if (new Date(senderResearchCompletionState.completedAt).getTime() <
         new Date(senderResearchPromptState.loadedAt).getTime()) {
-        throw new Error("FLOW_PRECONDITION: sender research completion is older than the latest research-sender prompt load. Re-run sender research and call complete_sender_research again.");
+        throw new Error("FLOW_PRECONDITION: campaign identity research completion is older than the latest research-sender prompt load. Re-run client/company prospect research and call complete_sender_research again.");
     }
     return {
         ok: true,

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.83",
+  "version": "0.1.85",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign/SKILL.md

@@ -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`

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

@@ -198,9 +198,9 @@ Validated draft directory:
     web lookup.
   - 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 identity/focus before continuing. Do not mention connected sender
-  availability in this confirmation.
+    Then summarize what you found in one or two lines and ask the user to confirm
+    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:
@@ -227,17 +227,19 @@ Validated draft directory:
   three specific options plus `Other / custom`. Do not ask this as plain
   numbered chat.
 
-  Then run one lightweight sender/company research pass before asking buyer,
-  offer, proof, or source questions. Prefer loading
+  Then run one lightweight campaign identity research pass before campaign
+  shell creation. The legacy subskill/tool names are `research-sender` and
+  `complete_sender_research`, but treat them as client/company prospect research
+  for the campaign, not as a connected-sender availability check. Prefer loading
   `get_subskill_prompt({ subskillName: "research-sender" })`, running its
   fetch/profile/company/WebSearch batch when those tools are exposed, and
   calling `complete_sender_research`. If WebSearch is unavailable, use the
   available MCP profile/company/post tools, call `complete_sender_research`
-  with the evidence counts found, and continue with explicit gaps. The setup
-  questions should use the confirmed company context and researched proof /
-  positioning options so they do not feel generic. If identity is still
-  unavailable, use neutral/custom intake options instead of guessed
-  vertical-specific options.
+  with the evidence counts found, and continue with explicit gaps. Setup
+  questions and the campaign brief should use the confirmed company context and
+  researched proof / positioning options so they do not feel generic. If
+  identity is still unavailable, use neutral/custom intake options instead of
+  guessed vertical-specific options.
 
 - Before the identity gate, use this customer-facing shape:
 
@@ -299,6 +301,14 @@ Validated draft directory:
   Do not mention internal artifact names, local folders, shell commands, or
   persistence in this preamble.
 
+  Before calling `create_campaign` for the watchable shell, make sure the
+  campaign identity research marker is satisfied: load `research-sender` if it
+  has not already been loaded, do the lightweight profile/company lookup, and
+  call `complete_sender_research`. This is still client/company prospect context
+  for the campaign brief. Do not call `list_senders`, do not ask the user to
+  connect a sender, and do not surface sender availability until
+  Settings/final handoff.
+
 - Before asking for brief approval, render a slim approval brief in the chat and
   keep the rich current brief in `brief.md`. Use rendered Markdown directly:
   `##` heading, bold field labels, numbered section labels, and short bullets.
@@ -380,11 +390,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
@@ -775,9 +785,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,
@@ -801,7 +815,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`
@@ -835,10 +849,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
@@ -858,7 +873,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

@@ -112,23 +112,20 @@
       "label": "Campaign brief interview",
       "onEnter": [
         {
-          "action": "resolve_company_identity_before_strategy_packet",
+          "action": "resolve_campaign_identity_before_strategy_packet",
           "optional": false,
           "when": "before_founder_strategy_source_packet",
           "allowedTools": [
-            "list_senders",
-            "get_sender",
             "fetch_company",
             "fetch_linkedin_profile",
             "WebFetch",
             "WebSearch"
           ],
           "maxCalls": {
-            "list_senders": 1,
             "identityLookup": 1,
             "companyLookupAfterIdentityConfirm": 1
           },
-          "quietlyCheckConnectedSendersFirst": true,
+          "quietlyCheckConnectedSendersFirst": false,
           "preferUserLinkedInWhenSenderInferenceIsWeak": true,
           "doNotPresentSenderPickerBeforeIdentityInference": true,
           "confirmCompanyBeforeStrategyQuestions": true,
@@ -149,7 +146,7 @@
           "chatRenderRule": "If the sender/company context has multiple campaignable product lines, services, or offers, ask exactly one single-choice structured campaign-focus question before buyer/offer/proof/source. Do not ask numbered plain-chat choices when the structured question tool is available. Do not use checkbox or multi-select wording."
         },
         {
-          "action": "run_sender_company_research_before_strategy_packet",
+          "action": "run_campaign_identity_research_before_strategy_packet",
           "target": "research-sender",
           "when": "after_identity_and_campaign_focus_before_founder_strategy_source_packet",
           "allowedTools": [
@@ -316,8 +313,6 @@
         "get_subskill_asset",
         "get_auth_status",
         "get_active_workspace",
-        "list_senders",
-        "get_sender",
         "complete_sender_research",
         "fetch_company",
         "fetch_company_posts",
@@ -475,13 +470,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 +634,6 @@
             "sampled fits as n/N (%)",
             "estimated usable people",
             "estimated good-fit range after cleanup",
-            "expected reply-rate range",
             "confidence note"
           ],
           "sourceDecisionRequiredFields": [
@@ -668,7 +662,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