@sellable/mcp 0.1.21 → 0.1.23

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.21",
+  "version": "0.1.23",
   "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,15 +869,17 @@ 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: ...`,
-  `Token notes: ...`, `My take: ...`, `Suggested adjustment: ...`,
+  `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, 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` /
+  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`.
@@ -906,7 +908,7 @@ avoids a generic pitch` is not enough. The user must see the actual subject,
   concrete filled message.
 - `{{profile_signal}}` is never a supported customer-facing token. It is an
   internal enrichment label and must not appear in `Subject:`, `Tokenized
-  template:`, `Sample prospect fill:`, rendered examples, `Token notes:`,
+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
@@ -917,6 +919,13 @@ avoids a generic pitch` is not enough. The user must see the actual subject,
   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
@@ -1010,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.
@@ -1026,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.
@@ -1104,6 +1122,9 @@ Do not:
 - `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
@@ -1238,8 +1259,9 @@ 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,
-  `Token notes:`, `My take:`, `Suggested adjustment:`, `Question:
-  approve-message or revise-messaging?`, and
+  `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`
 
@@ -1339,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
@@ -1348,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

@@ -66,9 +66,16 @@ 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, 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.
+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

@@ -606,6 +606,7 @@
             "tokenized template",
             "sample prospect fill",
             "rendered examples",
+            "bad token examples",
             "token notes",
             "my take",
             "suggested adjustment",
@@ -626,6 +627,8 @@
             "Rendered examples:",
             "Good token fill:",
             "Good omit:",
+            "Bad token fill:",
+            "Why bad:",
             "Token notes:",
             "My take:",
             "Suggested adjustment:",
@@ -643,6 +646,7 @@
             "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",
@@ -666,6 +670,8 @@
             "Rendered examples:",
             "Good token fill:",
             "Good omit:",
+            "Bad token fill:",
+            "Why bad:",
             "Token notes:",
             "My take:",
             "Suggested adjustment:",
@@ -928,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"
         },