@sellable/install 0.1.276 → 0.1.278

package/package.json

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

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

@@ -43,7 +43,8 @@ In automation or `--yolo` customer-visible setup, use this path before the
 long-form contract below:
 
 1. Resolve the active workspace and explicit sender scopes, then call
-   `setup_evergreen_campaigns({ mode:"plan", yolo:true, postEngagerSenderIds,
+   `setup_evergreen_campaigns({ mode:"plan", yolo:true,
+   handoffMode:"create_campaign_goals", postEngagerSenderIds,
    sharedSenderIds })`. If the user did not name senders but
    `get_campaign_waterfall` returns an active managed evergreen/prod waterfall
    for the workspace, derive exact sender scopes from the waterfall `senderRefs`
@@ -60,12 +61,23 @@ long-form contract below:
    If shell execution is unavailable and no visible/durable thread surface is
    callable, return `blocked: missing_visible_or_durable_lane_worker_runtime`
    before mutation.
-4. Write one compact prompt file per selected lane packet, create the receipt
-   directory, and launch all lane workers in parallel with the literal Codex CLI
-   worker command shape below. The parent does not create campaign shells.
+4. Write one compact prompt file per selected lane using the matching
+   `createCampaignGoals[].goalPrompt`, plus only the receipt path and canonical
+   receipt requirement. Do not paste the full evergreen skill, lane packet,
+   receipt schema, repair history, or verifier checklist into the worker prompt.
+   The worker goal is simple: run `$sellable:create-campaign` normally for that
+   campaign goal, use the evergreen-selected provider/source only as internal
+   sourcing metadata, and write the receipt. The parent does not create campaign
+   shells.
 5. Collect fresh durable receipts, verify with the original planRevision and
    selectedActionIds, then run the idempotency plan and show sample messages.
 
+Critical separation: evergreen owns lane/source selection; `$sellable:create-campaign`
+owns the customer-visible campaign brief and message strategy. Provider names
+such as Signal Discovery, lane keys, source lists, receipt fields, workflow
+mechanics, repair notes, hard-block checklists, and approved-message scaffolding
+must never be pasted into `campaignBrief` or generated customer-facing messages.
+
 Do not keep reasoning, re-reading prompts, or restating this workflow instead of
 dispatching workers. If the first worker cannot be launched after at most one
 short planning pass, return `blocked: worker_dispatch_deadline_exceeded` before
@@ -1220,7 +1232,7 @@ Message, and verify current-revision sample messages before final completion.
      Short form: Do not pass the warm template into Shared Signal Discovery or Shared Cold Fallback.
      Short form: Shared lanes must reject generic product-summary samples.
      Short form: Shared lanes must reject three nearly identical samples.
-     Short form: Shared lanes must reject low-confidence relevance hedges.
+     Short form: Shared lanes must reject intent-assumptive/source-thread hedges such as "might be interested", "hope this is relevant", and "saw you in a few conversations"; Shared Signal Discovery is a source provider, not customer-facing message copy.
      Short form: Shared lanes must reject internal workflow vocabulary.
      Short form: revise or rerun the packaged create-campaign/generate-messages path.
    - **Post Engagers** first-message style: short, casual, references the
@@ -1240,9 +1252,11 @@ Message, and verify current-revision sample messages before final completion.
      append `curious, are you trying...`, `open to...`, `worth seeing...`, or
      Sellable/product copy to a Post Engagers first message.
 
-   - **Shared Signal Discovery** first-message style: short, casual, references
-     the real observed signal/theme or public conversation. It may mention the
-     engagement source only when the source evidence supports it. Do not say
+   - **Shared Signal Discovery** first-message style: short, casual, starts
+     from the real public business theme or buyer problem supported by the row.
+     Treat Signal Discovery as a lead-source provider only. Do not mention the
+     engagement source, source mechanics, or discovery method in customer-facing
+     copy. Do not say
      "my post" unless the selected source post was actually authored by the
      sending sender. Do not thank the prospect for showing support, reacting,
      commenting, or popping up unless this is a sender-owned Post Engagers lane
@@ -1259,9 +1273,11 @@ Message, and verify current-revision sample messages before final completion.
      product summaries, or repeated structure are bad. If the first generated
      batch violates these rules, rerun, but record that as a repaired UAT path
      rather than the desired zero-shot path.
-     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
+     Do not use intent-assumptive/source-thread hedges such as "might be
+     interested", "hope this is relevant", "found you in a thread", or "saw
+     you in a few conversations" 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",
      "Claude Code", or "Claude-style agent workflows" in customer-facing
      message one. Also avoid generic product-process nouns such as "dashboard",
@@ -1273,7 +1289,7 @@ Message, and verify current-revision sample messages before final completion.
      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 "might be interested", "hope this is relevant", "found you in a thread", or "saw you in a few conversations"; translate source evidence into buyer context.
      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",
@@ -1289,11 +1305,14 @@ Message, and verify current-revision sample messages before final completion.
      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.
-     Do not open with "hope this is relevant" or a similar low-confidence
-     relevance hedge. Do not use a repeated product-definition paragraph such
-     as "Sellable is a GTM system" across samples; every reviewed cold sample
-     should be specific enough to the role, company, or problem that the three
-     sample messages do not share the same body skeleton.
+     Do not use source-thread hedges such as "hope this is relevant", "might be
+     interested", or "saw you in a few conversations" in Shared Cold Fallback.
+     Start from a concrete role, company, or buyer-problem observation instead.
+     Do not use a repeated
+     product-definition paragraph such as "Sellable is a GTM system" across
+     samples; every reviewed cold sample should be specific enough to the role,
+     company, or problem that the three sample messages do not share the same
+     body skeleton.
      Do not use mechanical Sellable process language such as "campaign idea into
      prospects, filters, messages, and sequence setup", "sequence-prospects",
      "dashboard overhead", "campaign map", "send-ready copy", or "reviewed
@@ -1310,7 +1329,7 @@ Message, and verify current-revision sample messages before final completion.
      Short form: Shared Cold Fallback uses no "I've put together".
      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.
-     Short form: no low-confidence relevance hedge such as "hope this is relevant".
+     Short form: no "hope this is relevant", "might be interested", or "saw you in a few conversations" in shared evergreen lanes.
      Short form: no repeated product-definition paragraph such as "Sellable is a GTM system".
     - Customer-visible evergreen lanes must enable ICP filtering before Message
       Drafting. This applies to Post Engagers, Shared Signal Discovery, and
@@ -1399,12 +1418,13 @@ Message, and verify current-revision sample messages before final completion.
       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, low-confidence relevance hedges such as "hope this
-      is relevant", internal workflow vocabulary, any sample with non-empty
-      `issues`, and any preserved Post Engagers opener; revise or rerun the packaged
-      create-campaign/generate-messages path before reporting completion. Do not
-      approve or final-report samples with `verdict:"passed"` and non-empty
-      `issues`.
+      near-identical samples, intent-assumptive hedges such as "might be
+      interested", source-context mismatches such as "saw you in a few
+      conversations" in Shared Cold Fallback, internal workflow vocabulary, any
+      sample with non-empty `issues`, and any preserved Post Engagers opener;
+      revise or rerun the packaged create-campaign/generate-messages path before
+      reporting completion. Do not approve or final-report samples
+      with `verdict:"passed"` and non-empty `issues`.
    - 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.