@sellable/mcp 0.1.22 → 0.1.24

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.22 --host codex --token skt_live_your_token_here --workspace-id your_workspace_id
+npx -y @sellable/install@0.1.24 --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.22 --host codex
+npx -y @sellable/install@0.1.24 --host codex
 sellable --verify-only --host codex
 ```
 

package/package.json

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

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

@@ -869,8 +869,8 @@ Orchestration requirements:
   user-facing review. The review must use this exact label shape so the gate can
   be parsed: `Subject: ...`, `Tokenized template: ...`, `Sample prospect fill:
   ...`, `Rendered examples: ...`, `Good token fill: ...`, `Good omit: ...`,
-  `Bad token fill: ...`, `Why bad: ...`, `Token notes: ...`, `My take: ...`,
-  `Suggested adjustment: ...`,
+  `Bad token fill: ...`, `Why bad: ...`, `Fallback if missing: ...`,
+  `Token notes: ...`, `My take: ...`, `Suggested adjustment: ...`,
   `Question: approve-message or revise-messaging?`, `Recommendation:
 approve-message|revise-messaging`.
 - Never ask the message approval question until the full message review is
@@ -878,8 +878,8 @@ approve-message|revise-messaging`.
 avoids a generic pitch` is not enough. The user must see the actual subject,
   the actual tokenized message template, one filled sample prospect version, at
   least one good filled example, one good omit example, one bad fill example,
-  why the bad fill is wrong, token notes, your take, and the suggested
-  adjustment before any `approve-message` /
+  why the bad fill is wrong, fallback rules for missing row data, token notes,
+  your take, and the suggested adjustment before any `approve-message` /
   `revise-messaging` question appears. If you catch yourself wanting to offer
   `show me message` as a choice, stop: render the message review first, then ask
   only `approve-message` or `revise-messaging`.
@@ -922,10 +922,16 @@ template:`, `Sample prospect fill:`, rendered examples, `Token notes:`,
 - `Bad token fill:` must show at least one realistic wrong fill for the current
   campaign, followed by `Why bad:`. This teaches the user and the live campaign
   runtime what not to do. Examples: overclaiming signal intent (`you are
-  evaluating Clay` when the only evidence is a post reaction), using forbidden
+evaluating Clay` when the only evidence is a post reaction), using forbidden
   phrasing (`you engaged with content...` when the approved voice is `raised
   your hand in a conversation around...`), forcing a weak optional token,
   lowercasing proper nouns, or making row signal sound like AI mail merge.
+- `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
+  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`,
   `lead-review.md`, `lead-filter.md`, or the selected winner's documented
   supported-token plan. Do not invent example values to make the template look
@@ -1020,8 +1026,8 @@ proof:`, `p.s. useful proof:`, `p.s. proof:`, or `p.s. social proof:`.
   inside the approval packet before `## Approved Message Template`. It should
   summarize the customer checkpoint from `message-review.md` and preserve the
   same literal `My take:`, `Suggested adjustment:`, `Good token fill:`,
-  `Good omit:`, `Bad token fill:`, `Why bad:`, `Token fill basis:`, and
-  `Recommendation:` labels.
+  `Good omit:`, `Bad token fill:`, `Why bad:`, `Fallback if missing:`,
+  `Token fill basis:`, and `Recommendation:` labels.
   Include `Open artifacts:` links to `approval-packet.md`,
   `message-review.md`, `lead-review.md`, and `brief.md` before the commit-gate
   question.
@@ -1043,9 +1049,9 @@ proof:`, `p.s. useful proof:`, `p.s. proof:`, or `p.s. social proof:`.
   must include `## Approved Message Template`, `## Token Fill Rules`, and
   `## Token Fill Examples`. `## Token Fill Examples` must copy the approved
   examples from `message-review.md` / `message-validation.md`, including
-  `Good token fill:`, `Good omit:`, `Bad token fill:`, `Why bad:`, and
-  `Token fill basis:`. Do not call `create_campaign` if these sections are
-  missing from the campaign brief.
+  `Good token fill:`, `Good omit:`, `Bad token fill:`, `Why bad:`,
+  `Fallback if missing:`, and `Token fill basis:`. Do not call
+  `create_campaign` if these sections are missing from the campaign brief.
 - `message-validation.md` must not call the winner a canonical template or
   hide per-row generation in bracketed body text. `## Selected Winner` must
   be a real sendable message that could be approved as-is.
@@ -1125,6 +1131,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
 - `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
@@ -1259,8 +1267,8 @@ mutation)`, a `Selected Winner`, and a non-empty `Token Adherence Table`
   `Sample prospect fill:` with a complete rendered subject + body and
   `Token fill basis:`, `Rendered examples:`, `Good token fill:` with a complete
   rendered subject + body, `Good omit:` with a complete rendered subject + body,
-  `Bad token fill:`, `Why bad:`, `Token notes:`, `My take:`,
-  `Suggested adjustment:`, `Question:
+  `Bad token fill:`, `Why bad:`, `Fallback if missing:`, `Token notes:`,
+  `My take:`, `Suggested adjustment:`, `Question:
 approve-message or revise-messaging?`, and
   `Recommendation: approve-message`
 - `message-review-decision.md` is exactly `approve-message`
@@ -1372,9 +1380,10 @@ Exact sequence:
    `{{closeLine}}`, or `{{psLine}}`.
    Include `## Token Fill Examples` copied from the approved message review and
    validation artifacts. It must preserve `Good token fill:`, `Good omit:`,
-   `Bad token fill:`, `Why bad:`, and `Token fill basis:` so the minted campaign
-   brief teaches future row generation how to fill tokens and what fills are
-   blocked. If the brief does not contain `## Token Fill Rules` and
+   `Bad token fill:`, `Why bad:`, `Fallback if missing:`, and
+   `Token fill basis:` so the minted campaign brief teaches future row
+   generation how to fill tokens, what fills are blocked, and what to do when
+   row data is missing. If the brief does not contain `## Token Fill Rules` and
    `## Token Fill Examples`, do not call `create_campaign`; route back to
    message review or approval packet generation.
 3. Call `bootstrap_create_campaign({ flowVersion: "v2" })`. Respect

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

@@ -72,10 +72,15 @@ The user should be able to compare "here is the template" against "here is what
 one real prospect would receive" before approving, and understand exactly how
 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.
+
 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
-rules and examples: good fills, good omits, bad fills, and why the bad fills are
-blocked.
+rules and examples: good fills, good omits, bad fills, fallback rules, and why
+the bad fills are blocked.
 
 ## Progress Updates
 

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

@@ -629,6 +629,7 @@
             "Good omit:",
             "Bad token fill:",
             "Why bad:",
+            "Fallback if missing:",
             "Token notes:",
             "My take:",
             "Suggested adjustment:",
@@ -647,6 +648,7 @@
             "tokenized template with rendered examples",
             "tokenized template plus filled sample prospect",
             "good and bad token-fill examples",
+            "per-token fallback rules for missing row data",
             "complete rendered subject plus body examples",
             "message-review hard-fail preflight",
             "A + B + C subject quality",
@@ -672,6 +674,7 @@
             "Good omit:",
             "Bad token fill:",
             "Why bad:",
+            "Fallback if missing:",
             "Token notes:",
             "My take:",
             "Suggested adjustment:",
@@ -948,6 +951,7 @@
             "Good omit:",
             "Bad token fill:",
             "Why bad:",
+            "Fallback if missing:",
             "Token fill basis:"
           ],
           "capture": ["campaignId", "watchUrl"],