@sellable/mcp 0.1.351 → 0.1.353

package/dist/tools/setup-evergreen-campaigns.js

@@ -6,7 +6,7 @@ async function postSetupEvergreenCampaigns(body) {
 export const setupEvergreenCampaignsToolDefinitions = [
     {
         name: "setup_evergreen_campaigns",
-        description: "Evergreen campaign setup plan/verify command. Use plan mode first to inspect exact workspace/sender/campaign/table/source state and receive immutable lane packets. `selectedSenderIds` is a legacy shorthand for both scopes; prefer `postEngagerSenderIds` for the Post Engagers sender scope and `sharedSenderIds` for the shared lane sender scope when they differ. The command plans one Post Engagers lane per post-engager sender plus shared Signal Discovery and Shared Cold Fallback lanes for the shared sender set. yolo is only a parent-skill auto-execution hint for safe lane packets; this backend command remains read-only in plan mode and verifies receipts in verify mode. When safe-yolo needs normal setup work, the parent skill may ask for bounded delegated approval: one approval over the current planRevision, selected action ids, caps, allowed side-effect classes, and stop conditions lets lane workers execute without per-substep approval while staying inside that packet. Lane workers must execute creation, source import, create-campaign workflow steps, generate-messages, sequence attachment, and review readiness through existing create-campaign workflow/subskills, then return receipts here for verification. Customer-visible verify receipts must include createCampaignStepReceipt with setupPlanCall, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall. This command does not launch campaigns, does not schedule sends, does not assign scheduler-owned send fields, does not archive/delete cleanup targets, and does not spend paid credits.",
+        description: "Evergreen campaign setup plan/verify command. Use plan mode first to inspect exact workspace/sender/campaign/table/source state and receive immutable lane packets. `selectedSenderIds` is a legacy shorthand for both scopes; prefer `postEngagerSenderIds` for the Post Engagers sender scope and `sharedSenderIds` for the shared lane sender scope when they differ. The command plans one Post Engagers lane per post-engager sender plus shared Signal Discovery and Shared Cold Fallback lanes for the shared sender set. yolo is only a parent-skill auto-execution hint for safe lane packets; this backend command remains read-only in plan mode and verifies receipts in verify mode. When safe-yolo needs normal setup work, the parent skill may ask for bounded delegated approval: one approval over the current planRevision, selected action ids, caps, allowed side-effect classes, and stop conditions lets lane workers execute without per-substep approval while staying inside that packet. Lane workers must execute creation, source import, create-campaign workflow steps, generate-messages, sequence attachment, and review readiness through existing create-campaign workflow/subskills, then return receipts here for verification. Customer-visible verify receipts must include createCampaignStepReceipt with setupPlanCall, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall. messageDraftingReceipt must include validationResult:'passed', a passed qualityReview, and at least 3 concrete sampleMessages with row ids, generated message text, pass verdicts, and no issues; Shared Cold Fallback samples with a standalone name followed by 'Hey there' are rejected. This command does not launch campaigns, does not schedule sends, does not assign scheduler-owned send fields, does not archive/delete cleanup targets, and does not spend paid credits.",
         inputSchema: {
             type: "object",
             properties: {

package/package.json

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

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

@@ -129,6 +129,13 @@ filter choice, Message Drafting, packaged `generate-messages`, sequence
 attachment, and send-review readiness. Do not rebuild those steps ad hoc in the
 parent thread.
 
+For any lane with `intent:"create"`, the worker must satisfy the normal
+net-new create-campaign preflight before shell creation: load
+`get_subskill_prompt({ subskillName:"research-sender" })`, run the sender/team
+identity research needed for the brief, call `complete_sender_research(...)`,
+then call `create_campaign`. Do not bypass this with a parent-thread brief or
+by directly setting campaign state.
+
 Workers return worker receipts. Each customer-visible lane receipt must include
 one durable `createCampaignStepReceipt` built from actual tool calls or worker receipts,
 not a parent-thread summary. The receipt must include:
@@ -138,6 +145,9 @@ not a parent-thread summary. The receipt must include:
   campaign/table binding or create intent used before work started. For a
   create lane, this receipt must explicitly include `createIntent:true`; for a
   reuse lane, do not report `createIntent:true`.
+- `researchSenderReceipt`: `research-sender` prompt load proof,
+  `complete_sender_research` result, sender LinkedIn identity basis, and the
+  notes/proof counts used before the net-new `create_campaign` call.
 - `campaignBriefReceipt`: the CampaignOffer/campaign id, current
   workflowTableId, brief hash or updated-at marker, delivery format, token
   rules, hard avoids, source-use rules, and first-message template state.
@@ -172,6 +182,12 @@ review-batch row ids/hash, and either `statusSource:"branch"` or
 full packaged prompt with `get_subskill_prompt({ subskillName:"generate-messages"`
 until `hasMore:false`, loaded the required message assets, and loaded
 `create-campaign-v2-validation` before returning a `messageDraftRecommendation`.
+The receipt must also include `validationResult:"passed"`, a passed
+quality-review object, and at least 3 concrete reviewed sample messages with
+row ids, generated message text, pass verdicts, and no issues. Shared Cold
+Fallback samples must not open with a standalone name line followed by
+"Hey there" or another generic greeting; that pattern means the lane did not
+finish the create-campaign message workflow to customer quality.
 The generated-message cells are not prompt proof: `currentRevisionGeneratedMessages`,
 Generate Message column counts, `messagesCount`, or rendered row previews prove
 only that table cells exist from the current brief/template, not that the
@@ -191,9 +207,14 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
 
 <objective>
 1. **Inventory first**: `get_campaigns` + `list_tables` + `get_campaign_waterfall` in the active workspace. Treat `list_tables` and the managed waterfall as authoritative for older managed slots; `get_campaigns` is a recent campaign page and may miss canonical evergreen lanes. Match existing campaigns/tables/waterfall slots to the plan by name (case-insensitive, ignore suffixes like "(Copy)") and stored slot identity. `list_tables.campaignStatus` and `list_tables.dashboardBucket` are part of the identity check: a matching `ARCHIVED` table/campaign is not a plain `REUSE`. If it is the canonical prod slot and the invocation explicitly allows dashboard visibility repair, repair it to `PAUSED`; otherwise mark it `flagged`/`blocked` and do not create a duplicate. A matching non-archived campaign/table/waterfall slot = REUSE; record it and move on. Never create a second campaign for a slot that already has one in any of those inventories.
-2. **Create only the missing slots** with `create_on_demand_campaign({ name, senderIds, campaignBrief })`:
+2. **Create only the missing slots** through the full `$sellable:create-campaign`
+   workflow path for each lane, using the lane packet as the setup basis:
    - Post Engagers lanes: that sender's ID only. Shared lanes: all the senders' IDs.
-   - The brief must include the warm post-engager first-message template style — short, casual, references the post they engaged with, closed question, **no internal vocabulary, no pitch, no meeting ask** in message one:
+   - The brief and message direction are lane-specific. Never reuse the Post
+     Engagers opening for Shared Cold Fallback.
+   - **Post Engagers** first-message style: short, casual, references the
+     sender-authored post they engaged with, closed question, **no internal
+     vocabulary, no pitch, no meeting ask** in message one:
 
      ```
      {{first_name}}
@@ -203,6 +224,25 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      Saw you pop up on my post about {{post_topic_line}}
      ```
 
+   - **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
+     "my post" unless the selected source post was actually authored by the
+     sending sender.
+   - **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
+     generic greeting. It should open with a light role/company/problem
+     observation 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.
+   - 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
+     `create-campaign-v2-validation`; the returned receipt must include at
+     least 3 concrete reviewed sample messages, a passed validation result, and
+     a passed quality review. Row/message counts alone are not enough.
+
    - **The brief must declare the delivery format** so Generate Message writes copy suited to how it actually sends:
      - DM lanes: add a `Delivery format:` line — either `multiline (each paragraph sends as its own DM message)` or `single message`. When multiline, the template's blank-line paragraphs ARE the message boundaries — write each one as a standalone typed message.
      - **InMail lanes can never be multiline**: an InMail is one message and the recipient must reply before anything else can be sent. InMail-bound templates must read as one cohesive message — declare `Delivery format: single message (InMail — no follow-up until reply)` and never structure the copy to depend on multi-message pacing.
@@ -235,7 +275,11 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      `workerDetails.messageDraftBuilder` with `statusSource:"branch"` or an
      inline `statusSource:"parent-thread-fallback"` receipt. The generated-message
      cells are not prompt proof; `currentRevisionGeneratedMessages` and row
-     previews are only downstream cell evidence.
+     previews are only downstream cell evidence. The proof must include
+     `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.
    - 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.