@sellable/mcp 0.1.388 → 0.1.390

package/package.json

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

package/skills/create-campaign-v2/references/gold-standard-message-examples.md

@@ -418,7 +418,7 @@ Tokenized shape:
 
 Hey there
 
-Saw you pop up on my post about {{post_topic_line}}
+Thanks for the support on my post about {{post_topic_line}}
 
 Curious, is this something you're dealing with right now?
 ```
@@ -429,6 +429,10 @@ Transfer rules:
   selected sender-authored post or use a safer source-specific phrase.
 - Do not use "showing some love"; it reads too casual for executive/VP/director
   contacts.
+- Keep the thank-you line. The point of this motion is acknowledging real
+  sender-owned support before asking a light relevance question. Do not flatten
+  it back to "saw you pop up" unless the sender specifically asks for that
+  wording.
 - Do not copy this shape into shared lanes, third-party thread sources, or cold
   fallback campaigns.
 - Keep the question closed and problem-oriented; do not pitch, ask for a

package/skills/create-evergreen-campaigns/SKILL.md

@@ -775,7 +775,7 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
 
      Hey there
 
-     Saw you pop up on my post about {{post_topic_line}}
+     Thanks for the support on my post about {{post_topic_line}}
      ```
 
    - **Shared Signal Discovery** first-message style: short, casual, references
@@ -797,9 +797,18 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      generic greeting. It should open with a light role/company/problem
      observation, avoid awkward phrases like "looks like a team where", avoid
      founder-only first person unless every attached sender can credibly say it,
-     and ask one clear problem question. This is a single-message
-     cold path unless the approved create-campaign message workflow proves a
-     better delivery format.
+     and ask one clear problem question. It must not pass just because the
+     receipt says `generate-messages` loaded; the reviewed samples must sound
+     like final cold output from the create-campaign/generate-messages workflow.
+     Use no self-intro such as "We're building", no opt-out shrug such as "If
+     this isn't relevant, ignore me", and no product-stack dump that repeats
+     Sellable/Codex/Claude-Code feature summary
+     across prospects. This is a single-message cold path unless the approved
+     create-campaign message workflow proves a better delivery format.
+     Short form: Shared Cold Fallback must not pass just because the receipt says `generate-messages` loaded.
+     Short form: Shared Cold Fallback uses no self-intro such as "We're building".
+     Short form: Shared Cold Fallback uses no opt-out shrug such as "If this isn't relevant, ignore me".
+     Short form: Shared Cold Fallback uses no product-stack dump.
    - Every customer-visible lane must run Message Drafting from the current
      campaign/table basis after source rows exist. The worker must load the full
      packaged `generate-messages` prompt, every required asset, and
@@ -854,10 +863,14 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
       `validationResult:"passed"`, a passed quality review, and at least 3
       reviewed sample messages. For Shared Cold Fallback, reject samples that
       open with a standalone name followed by "Hey there" or a similarly generic
-      greeting. For all shared lanes, reject generic product-summary samples,
-      repeated near-identical samples, and any preserved Post Engagers opener;
-      revise or rerun the packaged create-campaign/generate-messages path before
-      reporting completion.
+      greeting. For Shared Cold Fallback, also reject samples with a self-intro
+      such as "We're building", an opt-out shrug such as "If this isn't
+      relevant, ignore me", or a product-stack dump that repeats the same
+      Sellable/Codex/Claude-Code feature summary across prospects. For all
+      shared lanes, reject generic product-summary samples, repeated
+      near-identical samples, and any preserved Post Engagers opener; revise or
+      rerun the packaged create-campaign/generate-messages path before reporting
+      completion.
    - The first review batch exists and at least 3 review rows have generated
      messages from the approved brief. If fewer than 3 usable rows exist, report
      the actual count and why.
@@ -931,7 +944,8 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
    **Also confirm the delivery format and keep config in sync.** Ask the user whether DM lanes should send multiline (paragraph-per-message) or as a single message. Record the answer as the brief's `Delivery format:` line, and when multiline is chosen, set `actionConfig.sendEachParagraphAsMessage: true` on that campaign's `send_dm` column via `update_column` (config edits run no cells and nothing sends from unlaunched campaigns). Never set the paragraph-split flag on InMail columns — the option does not apply to InMail.
 6. **Interactive polish mode only: prove the template on one real row.** For ONE campaign that has at least one lead row (add one via `add_on_demand_leads` if every lane is empty and the user provides/approves a test lead), generate a message for exactly one row (`queue_campaign_cells` with `columnRole: "generateMessage"`, `rowSelector: { type: "reviewBatch", limit: 1 }` or the single row's ID), wait for it, then show the user the generated message next to the template — AND show how it would split if paragraph-per-message sending is enabled (list each paragraph as `msg 1:`, `msg 2:`, …) so the user confirms each one reads like a real typed message. Check alignment: tone, structure, no internal vocabulary, correct token substitution, no letter punctuation. Do NOT approve the row or generate for more rows — one sample only.
 7. **Automation mode template/config audit**: inspect existing send-lane briefs for a `Delivery format:` line and chat-native warm template. If a send lane is missing the line and the prompt allows cleanup, update only the campaign brief metadata with the safest default for that lane (`Delivery format: single message (LinkedIn DM; line breaks remain inside one generated message; no follow-up until reply)`). If cleanup is not allowed, flag it. Do not generate a sample row in automation mode unless the invocation explicitly asks for sample proof. In structure-only automation, do not generate a sample row unless the invocation explicitly asks for sample proof. In customer-visible completion, follow the Customer-Visible Completion Contract instead.
-8. **Report the reconcile plan and result** — every slot tagged `reused`, `created`, `repaired`, `flagged`, or `blocked`, plus template/sample details only when that mode ran:
+8. **Final customer-facing completion must include sample messaging**: after customer-visible verify and the idempotency rerun pass, add a `Sample Messaging Review` section to the final answer. For every completed lane, show at least one full generated first message for every completed lane with campaign name, campaign id, row id, and verdict. Prefer the approved route-proof row when it is quality-valid; otherwise use the best reviewed generated row from the verified receipt. Do not summarize the sample into a copy theme. Show the actual message text so the user can inspect tone and specificity. If any sample is not quite right, tell the user they can ask the AI to update the campaign brief/message template and rerun Generate Message before launch. Never suggest launching, scheduling, or sending as the next step from this command.
+9. **Report the reconcile plan and result** — every slot tagged `reused`, `created`, `repaired`, `flagged`, or `blocked`, plus template/sample details only when that mode ran:
 
 ```
 Evergreen Reconcile — {date}
@@ -940,6 +954,17 @@ Evergreen Reconcile — {date}
 • Sellable.dev - Shared Signal Discovery: repaired (send review ready; 50 rows, 3 generated, 1 approved gate row, sequence attached, paused)
 • Sellable.dev - Shared Cold Fallback: created (send review ready; 50 rows, 3 generated, 1 approved gate row, sequence attached, paused)
 All campaigns remain unlaunched. Next: enrich/approve more rows when you want more items ready to schedule.
+
+Sample Messaging Review
+• Christian Reyes - Post Engagers (`cmp_...`, row `row_...`, verdict: passed)
+  ```
+  {{full generated first message}}
+  ```
+• Sellable.dev - Shared Cold Fallback (`cmp_...`, row `row_...`, verdict: passed)
+  ```
+  {{full generated first message}}
+  ```
+If any sample is not quite right, ask the AI to update the campaign brief/message template and rerun Generate Message before launch.
 ```
 </objective>
 

package/skills/generate-messages/SKILL.md

@@ -227,9 +227,31 @@ when those shared lanes were sourced from engagement-like signals. Shared lanes
 must choose a signal-led, event-led, job-post-led, or proof-led motion from the
 current brief and row evidence instead of inheriting a preset first-message
 template.
+Post-engager first messages should thank the prospect for the support on the
+sender-owned post before asking the light relevance question. Prefer the gold
+shape `Thanks for the support on my post about {{post_topic_line}}` over
+surveillance-flavored wording like `saw you pop up`, unless the sender explicitly
+asks for that older wording.
 Short form: use the CXConnect Post-Engager Warm Reply-Rate Pattern only when the source is sender-owned Post Engagers.
 Short form: Never use that warm post-engager pattern for Shared Signal Discovery or Shared Cold Fallback.
 
+### Shared Cold Fallback quality bar
+
+Shared Cold Fallback is a true cold lane. It must not pass just because a receipt
+says `generate-messages` loaded or because generated cells exist. The samples
+must read like final create-campaign/generate-messages output.
+
+- Start from a concrete row-supported role/company/problem observation.
+- Ask one clear buyer problem question.
+- Keep the product line minimal and buyer-readable; do not turn the note into a
+  product-stack dump.
+- Use no self-intro such as "We're building" or "We're working on a way" in the
+  reviewed samples.
+- Use no opt-out shrug such as "If this isn't relevant, ignore me."
+- Do not repeat the same Sellable/Codex/Claude-Code product summary across
+  samples. If two samples would still read the same after replacing names and
+  companies, revise or rerun.
+
 ### Rich Personalization Contract
 
 The `create-campaign` asset `references/ai-native-tokens.md` is the canonical