@sellable/mcp 0.1.82 → 0.1.83

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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.82",
+  "version": "0.1.83",
   "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
@@ -235,106 +235,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.
+the campaign identity/focus before continuing. Do not mention connected sender
+availability in this confirmation.
 
-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:
+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, 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:
-
-```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 +294,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`.
-    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:
+  - 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.
+- 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