@sellable/mcp 0.1.20 → 0.1.22

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.20",
+  "version": "0.1.22",
   "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,28 @@ 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: ...`,
+  `Bad token fill: ...`, `Why bad: ...`, `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, one bad fill example,
+  why the bad fill is wrong, 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 +891,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,18 +899,33 @@ 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
   be a complete rendered subject + body, not a bullet list of token names or a
   single bridge-line fragment. Do not use bracketed instructions, deferred row
   notes, or phrases like `approve the selected winner above`.
+- `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
+  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.
 - 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
@@ -936,12 +956,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
@@ -999,8 +1019,9 @@ proof:`, `p.s. useful proof:`, `p.s. proof:`, or `p.s. social proof:`.
   standalone commit-gate question. Include a clear `## Message Review` section
   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:`, and `Recommendation:`
-  labels.
+  same literal `My take:`, `Suggested adjustment:`, `Good token fill:`,
+  `Good omit:`, `Bad token fill:`, `Why bad:`, `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.
@@ -1015,8 +1036,16 @@ proof:`, `p.s. useful proof:`, `p.s. proof:`, or `p.s. social proof:`.
 - the live body under `## Approved Message Template` must be sender-ready copy.
   Do not include bracketed instruction placeholders such as `[ROW BRIDGE ...]`,
   `[insert ...]`, `[generated ...]`, or prose that tells a later step to
-  paraphrase/fill a line. Put per-row generation rules in `### Token Fill Rules`
-  with concrete enriched-row fields, or route to `revise-messaging`.
+  paraphrase/fill a line. Put per-row generation rules in `## Token Fill Rules`
+  with concrete enriched-row fields, and copy approved good/bad examples into
+  `## Token Fill Examples`, or route to `revise-messaging`.
+- `approval-packet.md` and the live campaign brief passed to `create_campaign`
+  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.
 - `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.
@@ -1086,11 +1115,16 @@ 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
   row signal is omitted cleanly
+- `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
 - `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
@@ -1220,11 +1254,14 @@ 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,
+  `Bad token fill:`, `Why bad:`, `Token notes:`, `My take:`,
+  `Suggested adjustment:`, `Question:
+approve-message or revise-messaging?`, and
   `Recommendation: approve-message`
 - `message-review-decision.md` is exactly `approve-message`
 
@@ -1324,7 +1361,7 @@ Exact sequence:
    The live template body must contain only sender-ready copy plus supported
    `{{tokens}}`; no bracketed instructions or placeholder prose may appear in
    the body.
-   Include `### Token Fill Rules` for every enriched-prospect-row token in the
+   Include `## Token Fill Rules` for every enriched-prospect-row token in the
    template. Tokens may be row fields such as `{{first_name}}`,
    `{{company}}`, `{{role}}`, `{{headline}}`, `{{profile_summary}}`,
    `{{post_context}}`, `{{comment_summary}}`, `{{source_post_topic}}`, or
@@ -1333,6 +1370,13 @@ Exact sequence:
    proof points, casing style, `{{recent_signal_quote}}`, or abstract slot
    tokens such as `{{hookLine}}`, `{{painLine}}`, `{{productLine}}`,
    `{{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
+   `## 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
    `safeToProceed`; on blocking errors, surface and stop.
 4. Call

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

@@ -65,8 +65,17 @@ 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, good fill example, good omit example, bad fill example, why
+the bad fill is wrong, 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, and understand exactly how
+the tokens should and should not be filled.
+
+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.
 
 ## Progress Updates
 

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

@@ -603,8 +603,10 @@
           "requiredInlineMarker": "Status: message-review",
           "panels": [
             "subject",
-            "message",
+            "tokenized template",
+            "sample prospect fill",
             "rendered examples",
+            "bad token examples",
             "token notes",
             "my take",
             "suggested adjustment",
@@ -620,10 +622,13 @@
           "artifactLinkTiming": "before_approval_question",
           "requiredLabels": [
             "Subject:",
-            "Message:",
+            "Tokenized template:",
+            "Sample prospect fill:",
             "Rendered examples:",
             "Good token fill:",
             "Good omit:",
+            "Bad token fill:",
+            "Why bad:",
             "Token notes:",
             "My take:",
             "Suggested adjustment:",
@@ -640,6 +645,8 @@
             "no generic signal tokens",
             "no bracketed or deferred row instructions",
             "tokenized template with rendered examples",
+            "tokenized template plus filled sample prospect",
+            "good and bad token-fill examples",
             "complete rendered subject plus body examples",
             "message-review hard-fail preflight",
             "A + B + C subject quality",
@@ -658,10 +665,13 @@
           "questionPrerequisiteVisibleLabels": [
             "Status: message-review",
             "Subject:",
-            "Message:",
+            "Tokenized template:",
+            "Sample prospect fill:",
             "Rendered examples:",
             "Good token fill:",
             "Good omit:",
+            "Bad token fill:",
+            "Why bad:",
             "Token notes:",
             "My take:",
             "Suggested adjustment:",
@@ -924,6 +934,22 @@
           "requiredValues": {
             "currentStep": "auto-execute-leads"
           },
+          "requiredCampaignBriefSections": [
+            "Approved Message Template",
+            "Token Fill Rules",
+            "Token Fill Examples"
+          ],
+          "preserveTokenGuidanceFromArtifacts": [
+            "message-review.md",
+            "message-validation.md"
+          ],
+          "requiredTokenGuidanceLabels": [
+            "Good token fill:",
+            "Good omit:",
+            "Bad token fill:",
+            "Why bad:",
+            "Token fill basis:"
+          ],
           "capture": ["campaignId", "watchUrl"],
           "onMissingWatchUrl": "recoverable_failure_abort_before_rubric_save"
         },