@sellable/mcp 0.1.20 → 0.1.21

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

package/package.json

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

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

@@ -324,7 +324,7 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   strategic choice or the user has not already made the direction obvious. The
   user-facing choice should be approve/revise language, not "looks good".
   Approval options should refer to what the user just read, e.g. `Approve this
-  brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
+brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
   Include `Open artifacts:` links to `brief-v1.md` and `brief.md` before the
   approval question.
 
@@ -861,23 +861,26 @@ Orchestration requirements:
   with `Status: message-review` as the first visible line. Do not put a
   markdown heading, preface, or summary before that status line. This is a
   customer checkpoint, not an audit report: show the approved campaign message
-  template first, then show rendered examples that prove the tokens fill well
-  and can be omitted cleanly when row data is weak. Keep the detailed
+  template first, then show one filled sample prospect version immediately after
+  it so the user can judge whether the tokens are being used correctly. Then
+  show rendered examples that prove the tokens fill well and can be omitted
+  cleanly when row data is weak. Keep the detailed
   gold-standard/rule audit inside `message-validation.md`, not in the
   user-facing review. The review must use this exact label shape so the gate can
-  be parsed: `Subject: ...`, `Message: ...`, `Rendered examples: ...`,
-  `Good token fill: ...`, `Good omit: ...`, `Token notes: ...`,
-  `My take: ...`, `Suggested adjustment: ...`,
+  be parsed: `Subject: ...`, `Tokenized template: ...`, `Sample prospect fill:
+  ...`, `Rendered examples: ...`, `Good token fill: ...`, `Good omit: ...`,
+  `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
   visible in the chat. A summary like `Message review is ready` or `the draft
-  avoids a generic pitch` is not enough. The user must see the actual subject,
-  the actual tokenized message template, at least one good filled example, one
-  good omit example, 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`.
+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, 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`.
   Include `Open artifacts:` links to `message-review.md` and
   `message-validation.md` before the approval question.
 - `My take:` and `Suggested adjustment:` are mandatory customer-facing decision
@@ -886,7 +889,7 @@ approve-message|revise-messaging`.
   non-empty, specific to the current message, and useful for one last manual
   feedback pass. Never render a message review that jumps straight from token
   notes to `Question:` or `Recommendation:`.
-- `Message:` in `message-review.md` must be a tokenized template with supported
+- `Tokenized template:` in `message-review.md` must be a tokenized template with supported
   enriched-row tokens such as `{{first_name}}`, `{{company}}`,
   `{{workflow_context}}`, `{{headline}}`, `{{source_post_topic}}`, or
   `{{row_proof_note}}`. It must not be a one-row-only raw sample. It must
@@ -894,12 +897,20 @@ approve-message|revise-messaging`.
   enriched rows can actually fill or safely omit. If you cannot produce a
   tokenized template from supported enriched-row fields, stop with
   `Recommendation: revise-messaging`.
+- `Sample prospect fill:` must render the same template for one named sample
+  prospect from `lead-sample.json` or the selected row used in
+  `message-validation.md`. It must show the complete subject and body the
+  prospect would receive, plus a one-line `Token fill basis:` naming which row
+  fields filled each token. This is the user-facing proof that the template
+  works. Do not ask for approval if the user cannot compare the template to a
+  concrete filled message.
 - `{{profile_signal}}` is never a supported customer-facing token. It is an
-  internal enrichment label and must not appear in `Subject:`, `Message:`,
-  rendered examples, `Token notes:`, `message-validation.md` selected copy, or
-  `approval-packet.md`. If a profile-derived signal matters, translate it into
-  a buyer-readable derived token with a clear fill rule, such as
-  `{{workflow_context}}` or `{{row_proof_note}}`; otherwise omit the line.
+  internal enrichment label and must not appear in `Subject:`, `Tokenized
+  template:`, `Sample prospect fill:`, rendered examples, `Token notes:`,
+  `message-validation.md` selected copy, or `approval-packet.md`. If a
+  profile-derived signal matters, translate it into a buyer-readable derived
+  token with a clear fill rule, such as `{{workflow_context}}` or
+  `{{row_proof_note}}`; otherwise omit the line.
 - `Rendered examples:` must include at least one `Good token fill:` rendered
   message where the row has a clean signal and one `Good omit:` rendered message
   where an optional token line is omitted instead of forced. Each example must
@@ -936,12 +947,12 @@ approve-message|revise-messaging`.
   `thought this was relevant enough`, `seemed close
 enough`, `{{profile_signal}}`, `profile signal`, `is why I thought this might
   be relevant`, `Austin's`, a sender/founder name in the subject, a one-row raw
-  sample under `Message:`, rendered examples without full copy, a
+  sample under `Tokenized template:`, rendered examples without full copy, a
   mail-merge-sounding tokenized opener, missing or empty `My take:`, missing or
   empty `Suggested adjustment:`, `My take:` that only says `looks good`,
   `strong`, or `approved`, `Suggested adjustment:` that only says `none`, or no
-  literal `{{...}}` token in `Message:`, revise the message before showing it.
-  Do not output
+  literal `{{...}}` token in `Tokenized template:`, revise the message before
+  showing it. Do not output
   `Recommendation: approve-message` when any hard-fail preflight item is
   present.
 - `My take` must be 1-3 short bullets or sentences, focused on what a founder
@@ -1086,7 +1097,9 @@ Do not:
 
 - `Status: message-review`
 - `Subject:` using the approved tokenized A + B + C subject shape
-- `Message:` followed by the tokenized approved message template
+- `Tokenized template:` followed by the tokenized approved message template
+- `Sample prospect fill:` with one concrete sample prospect's complete rendered
+  subject + body and a `Token fill basis:` line
 - `Rendered examples:`
 - `Good token fill:` with a complete concrete rendered subject + body
 - `Good omit:` with a complete concrete rendered subject + body where optional
@@ -1220,11 +1233,13 @@ Anchor validation (block `approve` when empty):
   `Pass Rate`, `Recommendation`, and `Implementation Details`
 - `message-validation.md` has `Status: confirmed`, `Mode: DRY MODE (no DB
 mutation)`, a `Selected Winner`, and a non-empty `Token Adherence Table`
-- `message-review.md` has `Status: message-review`, `Subject:`, `Message:`
-  with at least one literal `{{...}}` token, `Rendered examples:`,
-  `Good token fill:` with a complete rendered subject + body, `Good omit:` with
-  a complete rendered subject + body, `Token notes:`, `My take:`, `Suggested
-adjustment:`, `Question: approve-message or revise-messaging?`, and
+- `message-review.md` has `Status: message-review`, `Subject:`,
+  `Tokenized template:` with at least one literal `{{...}}` token,
+  `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,
+  `Token notes:`, `My take:`, `Suggested adjustment:`, `Question:
+  approve-message or revise-messaging?`, and
   `Recommendation: approve-message`
 - `message-review-decision.md` is exactly `approve-message`
 

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

@@ -65,8 +65,10 @@ or plain paths to the files behind the decision. The artifact links are a backup
 for inspection, not a replacement for showing the content in chat.
 
 This applies especially to message approvals. Never ask someone to approve a
-message they cannot see. Show the subject, message body/template, filled example,
-omit example, token notes, your take, and suggested adjustment first.
+message they cannot see. Show the subject, tokenized template, a filled sample
+prospect version, omit example, token notes, your take, and suggested adjustment
+first. The user should be able to compare "here is the template" against "here
+is what one real prospect would receive" before approving.
 
 ## Progress Updates
 

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

@@ -603,7 +603,8 @@
           "requiredInlineMarker": "Status: message-review",
           "panels": [
             "subject",
-            "message",
+            "tokenized template",
+            "sample prospect fill",
             "rendered examples",
             "token notes",
             "my take",
@@ -620,7 +621,8 @@
           "artifactLinkTiming": "before_approval_question",
           "requiredLabels": [
             "Subject:",
-            "Message:",
+            "Tokenized template:",
+            "Sample prospect fill:",
             "Rendered examples:",
             "Good token fill:",
             "Good omit:",
@@ -640,6 +642,7 @@
             "no generic signal tokens",
             "no bracketed or deferred row instructions",
             "tokenized template with rendered examples",
+            "tokenized template plus filled sample prospect",
             "complete rendered subject plus body examples",
             "message-review hard-fail preflight",
             "A + B + C subject quality",
@@ -658,7 +661,8 @@
           "questionPrerequisiteVisibleLabels": [
             "Status: message-review",
             "Subject:",
-            "Message:",
+            "Tokenized template:",
+            "Sample prospect fill:",
             "Rendered examples:",
             "Good token fill:",
             "Good omit:",