@sellable/install 0.1.255 → 0.1.257

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.255",
+  "version": "0.1.257",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-evergreen-campaigns.md

@@ -1,7 +1,7 @@
 ---
 name: create-evergreen-campaigns
 description: Reconcile a sender team's evergreen campaigns — create-or-reuse the standing campaigns (per-sender post engagers + shared signal/cold lanes) idempotently, and when asked for customer-ready/full setup, complete each customer-visible campaign to paused send review with brief, rows, generated review messages, one approval gate row, and sequence. Never duplicates, never launches.
-visibility: internal
+visibility: public
 ---
 
 # Create Evergreen Campaigns
@@ -396,6 +396,14 @@ Use a compact worker prompt: include lane packet JSON, original selectedActionId
 original planRevision, parent postEngagerSenderIds, parent sharedSenderIds,
 receiptArtifactPath, workspace id, sender ids, side-effect caps, and the
 instruction to load packaged prompts through MCP.
+The worker prompt must include the exact filter status rule:
+`filterDecisionReceipt.status:"applied"` only; never `completed`, `confirmed`,
+`done`, or any other alias.
+The worker prompt must include the generated-message write rule: `update_cell`
+is allowed only for the semantic Approved checkbox, never for generated message
+text/body/sample copy. Bad copy requires `revise_message_template_and_rerun` or
+brief/template revision plus Generate Message rerun; any generated-message cell
+override is `blocked: generated_message_cell_override`.
 Do not paste the entire wrapper skill into worker prompts. If the parent cannot
 launch at least one visible/durable worker immediately after directory setup,
 stop with `blocked: worker_dispatch_stalled` before any mutation.
@@ -435,6 +443,8 @@ Worker lane packet JSON:
 Load `$sellable:create-campaign` and nested prompts/assets through Sellable MCP loaders.
 Use mcp__sellable only. Do not use admin tools, direct DB, Prisma, SQL, web search, or browser search.
 Do not launch, start, schedule, send, or use paid InMail.
+For filter proof, durable receipt status must be `filterDecisionReceipt.status:"applied"` only; never `completed`, `confirmed`, `done`, or aliases.
+For generated messages, `update_cell` is allowed only for the semantic Approved checkbox. Never use `update_cell` for generated message text/body/sample copy. Bad copy requires `revise_message_template_and_rerun` or brief/template revision plus Generate Message rerun. Any generated-message cell override is `blocked: generated_message_cell_override`.
 Complete only this lane, write the required durable receipt JSON, and stop.
 WORKER_PROMPT
 
@@ -585,10 +595,11 @@ not a parent-thread summary. The receipt must include:
   `filterDecisionReceipt.savedRubricCount`, or
   `filterDecisionReceipt.headlineICPCriteria`.
   The exact status string is contractual: use `status:"applied"` only.
-  Do not write `status:"confirmed"`, `status:"saved"`, `status:"done"`, or
-  any other alias after saving filters; the parent verifier rejects those
-  aliases even when saved rubric proof exists.
+  Do not write `status:"completed"`, `status:"confirmed"`, `status:"saved"`,
+  `status:"done"`, or any other alias after saving filters; the parent verifier
+  rejects those aliases even when saved rubric proof exists.
   Short form: Filter receipt status must be exactly `applied`.
+  Short form: Do not write `filterDecisionReceipt.status:"completed"`.
   Short form: Do not write `filterDecisionReceipt.status:"confirmed"`.
 - `messageDraftingReceipt`: the Message Drafting proof described below,
   including packaged `generate-messages` prompt/assets and validation. Raw
@@ -826,6 +837,12 @@ path itself in the worker thread:
    brief/template rerun, not from hand-edited message cell overrides. If a lane
    used a generated-message body override, report
    `blocked: generated_message_cell_override` instead of success.
+   Do not repair by overwriting bad generated message cells and then calling the
+   overwritten cells `sampleMessages`.
+   `messageDraftingReceipt.qualityReview.repairNote`,
+   `messageDraftingReceipt.toolsUsed`, or any proof mentioning generated
+   message cell repair through `update_cell` is self-incriminating and must be
+   `blocked: generated_message_cell_override`.
    Short form: `update_cell` is allowed only for the semantic Approved checkbox.
    Short form: Do not use `update_cell` to edit generated message text.
    Short form: Bad copy requires brief/template revision plus Generate Message rerun.
@@ -1072,16 +1089,19 @@ Message, and verify current-revision sample messages before final completion.
      Do not use low-confidence relevance hedges such as "hope this is
      relevant" in Shared Signal Discovery samples. Translate source/tool terms
      into prospect-facing business language; do not put internal workflow
-     vocabulary such as "Codex-style workflow", "MCP", "agent workflows", or
-     "Claude-style agent workflows" in customer-facing message one. Also avoid
-     generic product-process nouns such as "dashboard", "workflow", "source",
-     "send-ready copy", "reviewed prospect lists", and "sequence" unless the
-     recipient's own product/category makes that exact word buyer-native.
+     vocabulary such as "Codex-style workflow", "MCP", "agent workflows",
+     "Claude Code", or "Claude-style agent workflows" in customer-facing
+     message one. Also avoid generic product-process nouns such as "dashboard",
+     "workflow", "source", "send-ready copy", "reviewed prospect lists",
+     "reviewed pipeline", "leads, filters, messages", "review-ready LinkedIn
+     sequence", "plain-language campaign idea into leads/filters/messages",
+     and "sequence" unless the recipient's own product/category makes that
+     exact word buyer-native.
      Short form: Shared Signal Discovery uses no self-intro such as "I'm building Sellable".
      Short form: Shared Signal Discovery uses no self-intro such as "We're building Sellable".
      Short form: Shared Signal Discovery uses no "I've put together".
      Short form: no low-confidence relevance hedge such as "hope this is relevant".
-     Short form: no internal workflow vocabulary such as "Codex-style workflow", "MCP", "agent workflows", or "Claude-style agent workflows".
+     Short form: no internal workflow vocabulary such as "Codex-style workflow", "MCP", "agent workflows", "Claude Code", or "Claude-style agent workflows".
    - **Shared Cold Fallback** first-message style: cold, direct, and cohesive.
      It must not pretend there was engagement, must not say "saw you pop up",
      and must not use a standalone name line followed by "Hey there" or other
@@ -1285,7 +1305,7 @@ Message, and verify current-revision sample messages before final completion.
    **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. **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. Extract samples from nested `createCampaignStepReceipt.messageDraftingReceipt.sampleMessages`, not from top-level summaries; extract samples from nested `createCampaignStepReceipt.messageDraftingReceipt.sampleMessages` when building the final answer. Prefer the approved route-proof row when it is quality-valid; otherwise use the best reviewed generated row from the verified receipt. A final `passed` sample must have `issues:[]`; if every reviewed sample has issues, report the lane as needing message revision instead of presenting a passed sample. 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.
+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. Extract samples from nested `createCampaignStepReceipt.messageDraftingReceipt.sampleMessages`, not from top-level summaries; extract samples from nested `createCampaignStepReceipt.messageDraftingReceipt.sampleMessages` when building the final answer. Prefer the approved route-proof row when it is quality-valid; otherwise use the best reviewed generated row from the verified receipt. A final `passed` sample must have `issues:[]`; if every reviewed sample has issues, report the lane as needing message revision instead of presenting a passed sample. Never approve or final-report sample text produced by manual `update_cell` body edits. 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.
    If the `Sample Messaging Review` section is omitted, the command is incomplete even when the structural campaign setup succeeded.
 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: