@sellable/mcp 0.1.24 → 0.1.25

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.25 --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.25 --host codex
 sellable --verify-only --host codex
 ```
 

package/package.json

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

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

@@ -929,7 +929,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 +1133,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

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",