@sellable/mcp 0.1.24 → 0.1.26

package/README.md

@@ -83,14 +83,14 @@ The token is provided when you generate it. Use `list_workspaces` +
 For customer/package installs, use the public installer:
 
 ```bash
-npx -y @sellable/install@0.1.24 --host codex --token skt_live_your_token_here --workspace-id your_workspace_id
+npx -y @sellable/install@0.1.26 --host codex --token skt_live_your_token_here --workspace-id your_workspace_id
 ```
 
 If you already have `~/.sellable/config.json`, rerun/verify without rewriting
 auth:
 
 ```bash
-npx -y @sellable/install@0.1.24 --host codex
+npx -y @sellable/install@0.1.26 --host codex
 sellable --verify-only --host codex
 ```
 

package/package.json

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

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

@@ -79,7 +79,11 @@ Validated draft directory:
   `request_user_input` (enabled in Default mode by
   `[features].default_mode_request_user_input = true`, not available in
   `codex exec`). Treat them as equivalent approval/intake gates and persist the
-  same draft artifacts after the user answers. If an interactive
+  same draft artifacts after the user answers. Use this structured gate only for
+  multiple-choice decisions or approval gates. Never use it to collect open text
+  input like LinkedIn URLs, company domains, notes, pasted context, campaign
+  ideas, or feedback. For open text, ask in normal chat and wait for the user to
+  paste the value. If an interactive
   Codex session does not expose `request_user_input`, do not silently degrade to
   a plain chat question; stop and tell the user:
 
@@ -141,10 +145,10 @@ Validated draft directory:
     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 present it as
-  a sender picker yet. If there is one strong likely sender, use `enrich_sender`
-  to infer their current or most recent company, then ask a structured
-  confirmation question:
+  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.
@@ -152,25 +156,30 @@ Validated draft directory:
   Is that you, and is this campaign for {company}?
   ```
 
-  The options must be:
+  The structured options must be no more than three choices:
 
-  1. `Yes, that's me and this is for {company}`
-  2. `That's me, but this is for a different company`
-  3. `No, I'll paste my LinkedIn URL so you can look me up`
-  4. `No, I'll paste the company website instead`
-  5. `Other / custom`
+  1. `Yes — use {matched sender} for {company}`
+  2. `No — I'll paste a LinkedIn profile`
+  3. `Use a company domain instead`
 
-  If the user chooses option 2, ask for the company website/domain and call
-  `fetch_company` when possible, otherwise one web lookup. If the user chooses
-  option 3, ask for their LinkedIn URL, call `fetch_linkedin_profile`, infer
-  their current or most recent company, then confirm company and sender again.
-  If the user chooses option 4, ask for the company website/domain, call
-  `fetch_company` when possible, otherwise one web lookup, then ask who the
-  LinkedIn messages should send from.
+  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. Ask for the user's LinkedIn URL or the company they want to
-  send on behalf of so you can research context:
+  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}.
@@ -180,11 +189,11 @@ Validated draft directory:
   offer, proof, and lead source.
   ```
 
-  If there is no strong sender match, make the first setup choice ask for the
-  user's LinkedIn URL or company website. The point of this gate is not "pick a
-  sender"; 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 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}.
@@ -193,12 +202,7 @@ Validated draft directory:
   the company website instead.
   ```
 
-  The LinkedIn/company identity gate should ask:
-
-  1. `What’s your LinkedIn URL?` Options: `I’ll paste my LinkedIn profile`,
-     `I’ll paste the company website instead`, `Other / custom`.
-
-  After that answer, do the lightweight lookup. For a LinkedIn profile, call
+  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.
@@ -929,7 +933,9 @@ evaluating Clay` when the only evidence is a post reaction), using forbidden
 - `Fallback if missing:` is required for every token in the template. Each
   fallback must say exactly what to do when the row lacks clean data: use a
   safe segment-level phrase, omit the sentence/line, or route to
-  `revise-messaging` if omission would break the message. Never leave a token
+  `revise-messaging` if omission would break the message. It must include a
+  concrete example of the fallback behavior, such as `omit the noticed... line`,
+  `use "operators"`, or `use "your outbound workflow"`. Never leave a token
   with "N/A", "unknown", empty braces, bracketed instructions, or a generic
   fill that sounds robotic or creepy.
 - rendered examples may only use token values that exist in `lead-sample.json`,
@@ -1131,8 +1137,8 @@ Do not:
 - `Bad token fill:` with a realistic wrong fill for the current campaign
 - `Why bad:` explaining the exact overclaim, unsupported token, weak signal,
   casing mistake, or mail-merge phrasing that makes the bad fill unacceptable
-- `Fallback if missing:` with one fallback or omit rule for every token in the
-  template
+- `Fallback if missing:` with one concrete fallback or omit example for every
+  token in the template
 - `Token notes:` naming which tokens are safe to fill, which optional token line
   should be omitted when absent, and whether the message uses standard sentence
   case or casual lowercase static words

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

@@ -74,8 +74,9 @@ the tokens should and should not be filled.
 
 Every token needs a fallback. If the row does not have clean data for a token,
 the approval view should say whether to use a safe segment-level phrase, omit
-the sentence, or revise the message. Missing data should never produce robotic
-or creepy copy.
+the sentence, or revise the message. It should include the exact fallback
+example, like `omit the noticed... line` or `use "operators"`. Missing data
+should never produce robotic or creepy copy.
 
 Approved token guidance is part of the campaign, not just the review. When a
 campaign is minted, the approved brief should carry forward the token fill
@@ -145,10 +146,10 @@ brief before anything is created.
 Good identity setup:
 
 ```text
-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.
+I’ll check whether you already have a connected sender here. If I find one, I’ll
+ask whether that’s you and whether this campaign is for that company. If not,
+just paste your LinkedIn URL or company domain and I’ll look it up before we
+keep going.
 ```
 
 Bad:
@@ -166,9 +167,15 @@ First I’ll check whether your Sellable token already tells me who you are.
 Better:
 
 ```text
-I’ll first check whether you already have a connected sender here. If not, I’ll
-ask for your LinkedIn URL or company website and use that to understand the
-campaign before we choose the audience and offer.
+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.
+```
+
+Bad:
+
+```text
+What should I use to confirm who this campaign is for?
 ```
 
 Bad:

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

@@ -649,6 +649,7 @@
             "tokenized template plus filled sample prospect",
             "good and bad token-fill examples",
             "per-token fallback rules for missing row data",
+            "concrete fallback examples, not abstract fallback advice",
             "complete rendered subject plus body examples",
             "message-review hard-fail preflight",
             "A + B + C subject quality",