@sellable/mcp 0.1.362 → 0.1.364

package/skills/create-campaign-v2-tail/SKILL.md

@@ -68,7 +68,6 @@ Step 16 — awaiting-user-greenlight
   ask the user which connected sender to attach; in explicit UAT safe mode only, use the safe mock sender
   update_campaign(senderIds=[selectedSenderId], currentStep=sequence)
   attach_recommended_sequence({ campaignId, currentStep: "send" })  # tier-aware: premium/SN -> If Open Profile->INMAIL_OPEN, else INVITE->accepted->DM
-  reread get_campaign + list_tables; verify hasSequence:true on the current workflowTableId, not an older shell table
   if the attach response did not move the UI: update_campaign(currentStep=send)
   surface campaign setup orientation + final launch choices without repeating the watch URL
   STOP. DO NOT call start_campaign. DO NOT move to running without explicit launch greenlight.
@@ -82,13 +81,7 @@ hand-author a `version: 2` template with nodes, branches, and
 entryNodeId — that's error-prone mid-long-context (galley-off UAT
 `20260420T195732Z` failed because Claude hit "Invalid node type" and
 tried to debug via forbidden Bash/Glob calls). Use `attach_sequence`
-only when the caller explicitly needs a custom non-recommended cadence, or when
-you have just reread the campaign after `confirm_lead_list` and proved the
-current campaign table has no sequence while an older stale shell table is
-causing campaign-level `SEQUENCE_EXISTS`. In that stale-shell repair case, use
-`attach_sequence` on the current workflowTableId with the same non-paid product
-template the backend would select; never choose a paid-InMail template and never
-repair a table other than the current workflowTableId.
+only when the caller explicitly needs a custom non-recommended cadence.
 
 Hard gates — if you find yourself about to violate any of these, stop
 first:
@@ -539,14 +532,6 @@ Shape:
    opt-in because it can spend InMail credits. If the tool response
    does not persist `currentStep: "send"`, call
    `update_campaign({ campaignId, currentStep: "send" })`.
-   Then reread `get_campaign({ campaignId })` and `list_tables()` and verify the
-   returned current workflowTableId has `hasSequence:true`. If
-   `attach_recommended_sequence` returned `SEQUENCE_EXISTS` but the current table
-   still has `hasSequence:false`, do not continue to launch handoff from that
-   stale shell proof. Repair only the current workflowTableId with
-   `attach_sequence` using the same non-paid product template the recommended
-   selector would have chosen, or stop and report the stale-shell sequence
-   blocker if replacement was not explicitly approved.
 9. Surface the `handoff.orientation` string from `auto-execute.yaml` without
    repeating the watch URL.
 10. Ask the final launch greenlight with the structured question function:

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

@@ -51,353 +51,11 @@ Default evergreen plan per workspace (override only if the prompt specifies diff
 3. **`<Workspace/Team> - Shared Cold Fallback`** — one shared cold/fallback campaign lane across senders
 </inputs>
 
-<command_backed_workflow>
-For full/customer-visible setup, the first operational command is always
-`setup_evergreen_campaigns({ mode:"plan", yolo })`. Inventory can happen first
-for operator understanding, but do not create/reuse/repair campaign shells,
-source rows, messages, sequence, approvals, or cleanup before the command-backed
-plan returns lane packets.
-If `setup_evergreen_campaigns` is unavailable, returns 404, throws an API
-error, or does not return a current `planRevision` with lane packets, stop
-immediately with `blocked: setup_evergreen_campaigns_unavailable`. Do not fall
-back to ad hoc create-campaign calls, inventory-only guesses, or direct shell
-creation when the command-backed plan is missing.
-
-Plan shape:
-
-- one Post Engagers lane per sender in the **Post Engagers sender scope**;
-- one shared Signal Discovery lane for the **shared lane sender scope**;
-- one shared Cold Fallback lane for the **shared lane sender scope**;
-- explicit existing campaign/table bindings when the user points at a canonical
-  lane. Pass those exact ids to the plan and reuse/verify them instead of
-  creating duplicates.
-- If a user supplies canonical ids, reuse/verify them instead of creating duplicates.
-
-The command-backed unbound plan is authoritative. If
-`setup_evergreen_campaigns({ mode:"plan", ... })` returns a lane packet with
-`intent:"create"`, execute that create packet exactly. Do not convert it into an
-explicit binding because `list_tables`, `get_campaigns`, a waterfall, or old
-inventory shows an `ARCHIVED` campaign/table with a matching name. Archived
-campaigns are not reusable evergreen targets. Only pass an archived
-campaign/table as an explicit binding when the user supplied those exact ids and
-explicitly allowed dashboard visibility repair; otherwise ignore archived
-matches for execution and let the create packet proceed.
-
-Use `selectedSenderIds` only as a legacy shorthand when the same senders should
-get sender-owned Post Engagers lanes and attach to shared lanes. When the scopes
-differ, pass both explicit arrays:
-
-- `postEngagerSenderIds`: only senders that should have sender-owned Post
-  Engagers campaigns.
-- `sharedSenderIds`: senders attached to the shared Signal Discovery and Shared
-  Cold Fallback campaigns.
-
-If the operator says a sender is shared-only, do not create a Post Engagers lane
-for that shared-only sender. Example: if Justin already has a Post Engagers
-campaign and Jell/Hulan should only participate in the two shared campaigns,
-call `setup_evergreen_campaigns` with `postEngagerSenderIds:["<justin id>"]`
-and `sharedSenderIds:["<justin id>","<jell or hulan id>"]`.
-
-When senders are ambiguous, ask which sender ids belong in the Post Engagers
-sender scope and which belong in the shared lane sender scope before planning.
-If the operator says all connected senders for both scopes, pass
-`allConnectedSenders` and let the command return exact selected sender ids or
-blockers.
-
-`--yolo` is supported, but it is a safety-scoped execution mode, not a cleanup
-or launch permission. With `--yolo`, pass `yolo:true` to
-`setup_evergreen_campaigns({ mode:"plan", yolo })` and proceed without
-intermediate approval only when every selected lane packet returns
-`autoExecutable:true`. `--yolo` does not authorize archive/delete cleanup,
-launch/start, schedule/send, broad approve-all, wrong workspace work, stale
-plan execution, paid InMail spend, or ambiguous target choice. Stop on wrong
-workspace, cleanup/archive/delete need, stale plan, disconnected sender,
-duplicate candidate, unsafe side effect, missing source proof, or missing
-message proof.
-
-When safe-yolo is blocked only because the plan needs normal setup work, ask
-for a **bounded delegated approval** over the rendered current plan instead of
-asking for each substep. The approval packet must name the workspace id, sender
-ids, lane keys, campaign/table ids or create intents, source/import caps,
-generate-message caps, route-proof approval policy, selectedActionIds,
-planRevision, allowed side-effect classes, and stop conditions. After that one
-approval covers the current planRevision, the parent may act on behalf of the
-operator and execute the selectedActionIds end to end. Do not ask again for
-substep approvals for source import, create-campaign choices, Message Drafting,
-sequence attach/precheck, or exactly one route-proof approval when those actions
-are within the lane packet, approved caps, approved side-effect classes, and
-route-proof approval policy. Stop and re-plan if any fresh reread changes the
-workspace id, sender ids, source/list id, campaign/table id, new campaign/table
-id, planRevision, actionId, selectedActionIds, allowed side effects, caps,
-status, or blocker set outside the approved packet.
-The short rule: one approval covers the current planRevision and selectedActionIds.
-The execution rule: act on behalf of the operator; do not ask again for substep approvals while work stays within the lane packet, approved caps, approved side-effect classes, and route-proof approval policy.
-The drift rule: stop and re-plan when ids, caps, blockers, side-effect classes, or any new campaign/table id leave the approved packet.
-
-After bounded delegated approval or safe `--yolo`, fan out lane worker tasks
-only from the current plan. Each worker receives the complete lane packet:
-workspace id, sender ids, lane key/type, existing campaign/table binding or
-create intent, source hints, caps, planRevision, actionId, allowed side effects,
-and postconditions. Workers must use the create-campaign workflow and
-create-campaign workflow/subskills for campaign creation/setup, source/import,
-filter choice, Message Drafting, packaged `generate-messages`, sequence
-attachment, and send-review readiness. Do not rebuild those steps ad hoc in the
-parent thread. The parent thread is only the planner, dispatcher, verifier, and
-receipt collector: it must not call `create_campaign`, `import_leads`,
-`start_campaign_message_preparation`, `update_cell`, or sequence-attach tools
-for a lane that was assigned to a worker. When the host supports branch
-execution, Task/subagent, or separate Codex threads, assign one lane packet per
-worker and run the lane workers in parallel. If the host cannot run parallel
-workers, report `blocked: missing_parallel_lane_worker_runtime` instead of
-silently doing all lane creation sequentially in the parent thread.
-Short form: the parent thread is the planner, dispatcher, verifier, and receipt collector.
-Before the first mutating lane action, complete an execution-runtime preflight:
-name the callable worker surface/tool that will run lane packets (for example
-Task/subagent, branch worker, separate Codex thread, or an equivalent explicit
-worker runtime). If you cannot name a real callable worker runtime, stop with
-`blocked: missing_parallel_lane_worker_runtime` before calling
-`create_campaign`, `update_campaign`, `import_leads`, `confirm_lead_list`, or
-any source/message/sequence mutation. Creating campaign shells first and then
-discovering the worker runtime is missing is a failed run.
-
-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:
-
-- `setupPlanCall`: the exact `setup_evergreen_campaigns({ mode:"plan", ... })`
-  planRevision, selected actionId, lane key, workspace id, sender ids, and
-  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.
-- `sourceDecisionReceipt`: selected source/list id, provider, cursor/inventory
-  state, import/copy caps, explicit `dedupeDncProviderExclusions:true` or an
-  equivalent exclusions object, row ids or row-count evidence (`rowCount`,
-  `readyRowCount`, or `rowEvidence`), and the reason no colder source was used
-  before the current source was proven exhausted or insufficient.
-- `filterDecisionReceipt`: saved/applied filter ids or explicit skip-filter
-  decision with current campaign/table basis.
-- `messageDraftingReceipt`: the Message Drafting proof described below,
-  including packaged `generate-messages` prompt/assets and validation.
-- `reviewBatchReceipt`: review-batch row ids/hash, generated row count,
-  quality-valid route-proof row id when approved, and proof that no broad
-  approve-all occurred.
-- `sequenceReceipt`: exact current workflowTableId, recommended non-paid
-  sequence attach/precheck result, and readback showing `hasSequence:true` when
-  completion is claimed.
-- final paused-send proof: if the current campaign table is `DRAFT` after the
-  sequence is attached, call the product `pause_campaign({ campaignId })`
-  endpoint/tool to put the unlaunched campaign into `PAUSED` review state, then
-  reread the campaign/table. Do not raw-write `campaignStatus`, do not start or
-  launch, and do not schedule/send. Completion requires reread proof of
-  `currentStep:"send"` and `campaignStatus:"PAUSED"`.
-- `verifyCall`: the exact `setup_evergreen_campaigns({ mode:"verify",
-  planRevision, selectedActionIds, receipts })` call/result used before the
-  parent reports completion.
-
-Use these canonical receipt leaf names exactly. Do not substitute looser aliases
-like `generateMessagesPromptLoad`, `requiredAssetLoads`,
-`validationPromptLoad`, `reviewBatchBasisHash`, `reviewRowIds`,
-`sequenceActionTypes`, or `pass:true` unless you also include the canonical
-fields below:
-
-```json
-{
-  "status": "succeeded",
-  "planRevision": "<original planRevision>",
-  "laneKey": "<lane key>",
-  "laneType": "<lane type>",
-  "workspaceId": "<workspace id>",
-  "senderIds": ["<sender id>"],
-  "campaignId": "<campaign id>",
-  "tableId": "<workflow table id>",
-  "createCampaignStepReceipt": {
-    "campaignBriefReceipt": {
-      "campaignId": "<campaign id>",
-      "workflowTableId": "<workflow table id>",
-      "briefHash": "<brief/currentApprovedBriefHash>",
-      "deliveryFormat": "single message",
-      "tokenRules": true,
-      "hardAvoids": true,
-      "sourceUseRules": true,
-      "firstMessageTemplate": "<template or template state>"
-    },
-    "sourceDecisionReceipt": {
-      "sourceId": "<source id>",
-      "sourceListId": "<source/list id>",
-      "cursorOrInventoryState": "<cursor/inventory/import state>",
-      "dedupeDncProviderExclusions": true,
-      "sourceLadderReason": "<why the current source is valid before colder sources>"
-    },
-    "filterDecisionReceipt": {
-      "status": "skipped",
-      "workflowTableId": "<workflow table id>"
-    },
-    "messageDraftingReceipt": {
-      "promptLoadedToHasMoreFalse": true,
-      "requiredAssetsLoaded": true,
-      "validationLoaded": true,
-      "campaignId": "<campaign id>",
-      "workflowTableId": "<workflow table id>",
-      "selectedLeadListId": "<source/list id>",
-      "reviewBatchRowHash": "<review row ids hash>",
-      "messageDraftRecommendation": {"basis": "generate-messages"},
-      "sampleMessages[].verdict": "pass",
-      "sampleMessages": [
-        {"rowId": "<row id>", "generatedMessageText": "<message>", "verdict": "pass"}
-      ]
-    },
-    "reviewBatchReceipt": {
-      "rowIdsHash": "<review row ids hash>",
-      "generatedCount": 3
-    },
-    "sequenceReceipt": {
-      "workflowTableId": "<workflow table id>",
-      "hasSequence": true,
-      "sequenceReceipt.actionTypes": ["send_invite"],
-      "sequenceReceipt.nonPaid": true,
-      "actionTypes": ["send_invite"],
-      "nonPaid": true
-    },
-    "finalPausedSendProof": {
-      "currentStep": "send",
-      "campaignStatus": "PAUSED"
-    },
-    "verifyCall": {
-      "mode": "verify",
-      "planRevision": "<original planRevision>",
-      "selectedActionIds": ["<all original selected action ids>"]
-    }
-  }
-}
-```
-
-Verification always uses the original execution planRevision and original
-selectedActionIds from the plan packets that were dispatched before mutation.
-The parent must preserve the original selectedActionIds exactly.
-Do not replace them with a later reuse planRevision/actionIds after the
-campaigns exist. After workers complete, attach or patch `verifyCall` on each
-lane receipt with that original execution planRevision, original
-selectedActionIds, same sender scopes, and the verify result. Only after verify
-succeeds should the parent perform the idempotency rerun.
-
-If any required field is missing, report
-`blocked: missing_create_campaign_step_receipt` for that lane and do not call it
-complete.
-
-Message Drafting runtime rule: the preferred proof source is the normal
-create-campaign branch handoff (`watchNarration.workerDetails.messageDraftBuilder`
-or equivalent) with `statusSource:"branch"`. If that internal branch handoff is
-not callable or not exposed in the packaged MCP runtime, do **not** stop after
-creating/importing rows. The lane worker must run the packaged message-drafting
-path itself in the worker thread:
-
-1. Load `get_subskill_prompt({ subskillName:"generate-messages" })` until
-   `hasMore:false`.
-2. Load the required message assets and `create-campaign-v2-validation`.
-3. Call `start_campaign_message_preparation({ campaignId, tableId,
-   targetPreparedMessages, maxRowsToCheck, approvalMode:"mark_ready",
-   autoContinue:true })` inside the same lane worker, with bounded caps from the
-   lane packet.
-4. Poll `get_campaign_message_preparation_status` until no queued/active cells
-   remain or a bounded stop reason is returned.
-5. Use `get_campaign_messages_preview` or `select_campaign_cells` to inspect
-   generated rows, quality-review at least 3 samples, approve exactly one
-   quality-valid route-proof row when none is already approved, and prove no
-   broad approve-all happened.
-6. Continue to `attach_recommended_sequence({ campaignId, currentStep:"send" })`
-   and, if the campaign is still `DRAFT`, `pause_campaign({ campaignId })`.
-   Reread the campaign/table before claiming completion.
-
-That packaged worker path must return `messageDraftingReceipt.statusSource:
-"packaged-generate-messages-worker"`. It is accepted only when the receipt
-includes the same prompt/assets/validation proof, current campaign/table/source
-basis, generated review rows, sample messages, quality review, route-proof
-approval evidence, sequence proof, and final paused-send proof required of the
-branch handoff. `statusSource:"parent-thread-fallback"` is still invalid.
-
-One lane may produce exactly one CampaignOffer/campaign id and one current
-workflow table id. For `intent:"create"`, the first successful
-`create_campaign` result establishes the lane's only allowed campaign/table
-target. Every later source/import/confirm/message/filter/sequence/readback call
-must use that same campaign id and current workflow table id. If any tool
-returns or creates a different CampaignOffer, workflow table, "Campaign from
-Source" campaign, or shell for the same lane, stop immediately with
-`blocked: duplicate_campaign_offer_created`, include both ids in the receipt,
-and do not report completion. Do not hide the earlier shell by reporting only
-the later imported campaign.
-
-Each customer-visible lane receipt must also include message proof from
-`watchNarration.workerDetails.messageDraftBuilder`, the worker's equivalent
-branch handoff record, or the packaged message-prep worker path above. Valid
-evergreen message proof names the current campaign id, workflowTableId,
-selected lead-list or source id, filter choice, and review-batch row ids/hash,
-and it must use `statusSource:"branch"` or
-`statusSource:"packaged-generate-messages-worker"`.
-`statusSource:"parent-thread-fallback"` is not accepted for evergreen
-customer-visible completion because it can be a parent summary rather than proof
-that the create-campaign Message Drafting branch actually ran. The proof must
-show the worker loaded the 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.
-Shared Signal Discovery samples must not use sender-owned post-engager language
-such as "my post", "thanks for showing support", "saw you pop up", or any copy
-that implies the sending sender authored the source post or personally received
-the prospect's engagement unless the selected source evidence proves that exact
-sender authored the post.
-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
-create-campaign Message Drafting branch ran. If this receipt is missing, report
-`blocked: missing_message_drafting_receipt` and do not call the lane complete.
-
-The parent then calls
-`setup_evergreen_campaigns({ mode:"verify", postEngagerSenderIds,
-sharedSenderIds, planRevision, selectedActionIds, receipts })` using the same
-sender scopes as the plan call and the original execution planRevision/actionIds,
-and reports only verified completion. A verify call without the same sender scopes can recompute an empty or different plan and is invalid proof. A verify call that uses a later reuse planRevision instead of the original execution planRevision is also invalid proof. Only after verify succeeds, rerun
-`setup_evergreen_campaigns({ mode:"plan", postEngagerSenderIds,
-sharedSenderIds, yolo:true })` without explicit campaign/table bindings. That
-idempotency rerun must return `intent:"reuse"` for every completed lane and no
-duplicate-lane blockers before you call the command finished. If verify blocks,
-report the blocker and repair only the missing postconditions from the same
-current plan.
-
-Message proof for every customer-visible lane must come from the current
-campaign/table basis and include at least 3 generated review rows from the
-packaged `generate-messages` path before completion is reported.
-Parent-thread handwritten copy or setting `currentStep` is not proof.
-</command_backed_workflow>
-
 <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** through the full `$sellable:create-campaign`
-   workflow path for each lane, using the lane packet as the setup basis:
+2. **Create only the missing slots** with `create_on_demand_campaign({ name, senderIds, campaignBrief })`:
    - Post Engagers lanes: that sender's ID only. Shared lanes: all the senders' IDs.
-   - 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:
+   - 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:
 
      ```
      {{first_name}}
@@ -407,33 +65,6 @@ 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. Do not thank the prospect for showing support, reacting,
-     commenting, or popping up unless this is a sender-owned Post Engagers lane
-     with sender-authored source evidence.
-   - **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, avoid awkward phrases like "looks like a team where", 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`; if the internal branch handoff is not
-     callable in the packaged runtime, the worker must call
-     `start_campaign_message_preparation` and poll
-     `get_campaign_message_preparation_status` from the lane worker. The
-     returned receipt must include `statusSource:"branch"` or
-     `statusSource:"packaged-generate-messages-worker"`, 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.
@@ -459,73 +90,26 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
    - Message Drafting has run from the current campaign/table basis, using the
      create-campaign message prompt/assets and validation gate. Updating
      `currentStep:"messages"` is not proof. Parent-thread handwritten copy is
-     not a substitute. The proof receipt must show
-     `get_subskill_prompt({ subskillName:"generate-messages"` was loaded until
-     `hasMore:false`, required message assets were loaded, and
-     `create-campaign-v2-validation` ran through
-     `workerDetails.messageDraftBuilder` with `statusSource:"branch"` or
-     through the lane worker's packaged message-prep path with
-     `statusSource:"packaged-generate-messages-worker"`,
-     `start_campaign_message_preparation`, and
-     `get_campaign_message_preparation_status`. The generated-message cells are
-     not prompt proof; `currentRevisionGeneratedMessages` and row 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.
+     not a substitute.
    - 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.
-     If a bounded preparation job requested more than the minimum but already
-     met the minimum generated-message floor, do not stall on a single bad review row once a fresh status/readiness check shows no queued, processing, or active cells; record the shortfall, name the failed/empty-row reason when
-     available, and continue with route-proof review rather than expanding source
-     or waiting forever.
    - At least one generated row is approved as a route-proof gate. If zero rows
      are approved and the prompt explicitly asked for full/customer-ready
      completion, approve exactly one quality-valid generated row. If one or more
      rows are already approved, do not add more approvals during evergreen
      completion. Never broad approve all rows.
-    - The recommended non-paid sequence is attached to the current campaign
-      table, and the watched campaign is on Send. Use
-      `attach_recommended_sequence({ campaignId, currentStep:"send" })` when a
-      safe attach is needed. After `confirm_lead_list` or any source-list copy,
-     immediately reread `get_campaign({ campaignId })`; the returned
-     `workflowTableId` is the current campaign table. Cross-check that exact
-     current workflowTableId with `list_tables` and require `hasSequence:true`
-     before reporting completion. If a stale shell table has sequence columns but
-     the current campaign table does not, `SEQUENCE_EXISTS` is not enough:
-     record the stale shell table id, then repair the current workflowTableId
-     with `attach_sequence` using the same non-paid product template
-      `attach_recommended_sequence` would have selected. Never use a paid-InMail
-      template and never attach/replace sequence outside the current table unless
-      the current lane packet explicitly allowed sequence repair.
-    - If the current campaign table is still `DRAFT` after sequence/readiness
-      proof, call `pause_campaign({ campaignId })` and reread. `pause_campaign`
-      is the product-native review-state transition; it is not a launch and does
-      not schedule or send. Never raw-write campaign status.
-    - No scheduled, queued outbound, sent outbound, campaign launch, or paid
-      InMail spend is created by this skill.
+   - The recommended non-paid sequence is attached, and the watched campaign is
+     on Send. Use `attach_recommended_sequence({ campaignId, currentStep:"send" })`
+     when a safe attach is needed. Existing sequence proof may come from
+     `SEQUENCE_EXISTS`; do not replace it without explicit user confirmation.
+   - No scheduled, queued outbound, sent outbound, campaign launch, or paid
+     InMail spend is created by this skill.
 4. **Verify each slot** after create/reuse/repair:
    - `get_campaign` shows the campaign exists, remains unlaunched, and has the expected workflow table.
    - Builder truth must match dashboard truth. `currentStep:"running"` is valid only when the linked table has `campaignStatus:"ACTIVE"`. For a `PAUSED` or `ARCHIVED` campaign/table, repair or flag stale `currentStep:"running"` back to launch review (`send` / review-ready) before reporting the slot done. Never call `start_campaign` just to make a stale `running` step true.
-   - Send/action lanes such as Post Engagers have a sequence attached on the
-     exact current campaign table. Use `list_tables({ hasSequence: true })` as a
-     quick cross-check, but do not treat that filter as the only proof. If the
-     canonical current campaign table is missing from the sequence-filtered
-     table list and `attach_recommended_sequence({ campaignId })` returns
-     `SEQUENCE_EXISTS`, inspect whether a stale shell table owns the sequence.
-     For a customer-visible completion run, stale shell proof is not completion:
-     rerun the current-table repair above or report `blocked: stale_shell_sequence`.
-   - Only use `attach_recommended_sequence({ campaignId })` for a send-lane
-     sequence repair/precheck when the target is a canonical prod slot and the
-     invoking prompt allows sequence repair. Call it at most once without
-     `confirmed`; a successful response is `repaired`. Treat `SEQUENCE_EXISTS` as
-     non-mutating proof only when the current table also has `hasSequence:true`.
-     Never call `attach_recommended_sequence` or `attach_sequence` with
-     `confirmed:true` in evergreen automation unless the user explicitly asks to
-     replace an existing sequence or the approved lane packet allows current
-     table stale-shell repair.
+   - Send/action lanes such as Post Engagers have a sequence attached. Use `list_tables({ hasSequence: true })` as a quick cross-check, but do not treat that filter as the only proof. If the canonical campaign/table is missing from the sequence-filtered table list but a safe `attach_recommended_sequence({ campaignId })` repair/precheck returns `SEQUENCE_EXISTS`, record `sequence attached (verified by SEQUENCE_EXISTS precheck; list_tables.hasSequence mismatch)` and do not retry.
+   - Only use `attach_recommended_sequence({ campaignId })` for a send-lane sequence repair/precheck when the target is a canonical prod slot and the invoking prompt allows sequence repair. Call it at most once without `confirmed`; a successful response is `repaired`, and `SEQUENCE_EXISTS` is non-mutating proof that a sequence already exists. Never call `attach_recommended_sequence` or `attach_sequence` with `confirmed:true` in evergreen automation unless the user explicitly asks to replace an existing sequence.
    - Do not report `source-only/no sequence expected` for any named evergreen
      campaign that appears in Campaigns, has a CampaignOffer ID, or is backed by
      a campaign dashboard table. Shared Signal Discovery and Shared Cold

package/skills/refill-sends/SKILL.md

@@ -9,9 +9,6 @@ allowed-tools:
   - mcp__sellable__get_campaign_refill_state
   - mcp__sellable__fill_campaign_horizon
   - mcp__sellable__get_campaign
-  - mcp__sellable__get_campaign_context
-  - mcp__sellable__update_campaign
-  - mcp__sellable__get_provider_prompt
   - mcp__sellable__get_campaign_message_preparation_status
   - mcp__sellable__start_campaign_message_preparation
   - mcp__sellable__cancel_campaign_message_preparation
@@ -19,7 +16,6 @@ allowed-tools:
   - mcp__sellable__wait_for_lead_list_ready
   - mcp__sellable__confirm_lead_list
   - mcp__sellable__search_signals
-  - mcp__sellable__select_promising_posts
   - mcp__sellable__fetch_post_engagers
   - mcp__sellable__search_sales_nav
   - mcp__sellable__lookup_sales_nav_filter
@@ -33,10 +29,6 @@ allowed-tools:
   - mcp__sellable__get_rows
   - mcp__sellable__get_rows_minimal
   - mcp__sellable__get_table_rows
-  - mcp__sellable__get_campaign_table_schema
-  - mcp__sellable__select_campaign_cells
-  - mcp__sellable__wait_for_campaign_processing
-  - mcp__sellable__get_sender
 ---
 
 # Refill Sends

package/skills/refill-sends-workflow/SKILL.md

@@ -7,9 +7,6 @@ allowed-tools:
   - mcp__sellable__get_campaign_refill_state
   - mcp__sellable__fill_campaign_horizon
   - mcp__sellable__get_campaign
-  - mcp__sellable__get_campaign_context
-  - mcp__sellable__update_campaign
-  - mcp__sellable__get_provider_prompt
   - mcp__sellable__get_campaign_message_preparation_status
   - mcp__sellable__start_campaign_message_preparation
   - mcp__sellable__cancel_campaign_message_preparation
@@ -17,7 +14,6 @@ allowed-tools:
   - mcp__sellable__wait_for_lead_list_ready
   - mcp__sellable__confirm_lead_list
   - mcp__sellable__search_signals
-  - mcp__sellable__select_promising_posts
   - mcp__sellable__fetch_post_engagers
   - mcp__sellable__search_sales_nav
   - mcp__sellable__lookup_sales_nav_filter
@@ -31,10 +27,6 @@ allowed-tools:
   - mcp__sellable__get_rows
   - mcp__sellable__get_rows_minimal
   - mcp__sellable__get_table_rows
-  - mcp__sellable__get_campaign_table_schema
-  - mcp__sellable__select_campaign_cells
-  - mcp__sellable__wait_for_campaign_processing
-  - mcp__sellable__get_sender
 ---
 
 # Refill Sends Workflow
@@ -109,42 +101,6 @@ Source replenishment choices:
   source prospects into the same campaign/source-list path, then confirm
   readiness.
 
-### Running Campaign Signal Discovery Recovery
-
-For an already-running regular campaign that needs same-campaign Signal
-Discovery replenishment, treat the watch/current-step transition as a guarded
-repair, not as normal create-campaign navigation.
-
-Do not call `search_signals` with `currentStep:"signal-discovery"` directly from `currentStep:"running"`. The campaign step guard intentionally rejects that
-backwards transition. After exact approval and a fresh refill-state reread, clear `currentStep` only if it still exactly matches `running`:
-
-```text
-update_campaign({ campaignId, currentStep:null, clearCurrentStepIfMatches:"running" })
-```
-
-Then register provider preflight and run a campaign-scoped `search_signals` so
-post rows exist in the campaign's Signal Discovery state:
-
-```text
-get_provider_prompt({ provider:"signal-discovery", campaignOfferId, confirmed:true })
-search_signals({ campaignOfferId, currentStep:"signal-discovery", confirmed:true, ... })
-```
-
-Use `select_promising_posts` before importing. For a fresh source refill, prefer
-`selectionMode:"replace"` and `scrapePlanMode:"capacity-target"` with the
-approved `targetEngagerCount` and `maxPostsToScrape`. If the approved post set cannot cover the target, do not knowingly run an under-capacity scrape; ask for approval to expand the selected post set or switch source.
-
-If `import_leads` returns `reusedExistingSourceList` but the user explicitly
-approved a different selected-post scrape, retry `import_leads` with the existing `sourceLeadListId` from that response or from refill state. For Signal
-Discovery this bypasses the stale reuse guard and materializes the newly
-selected campaign-scoped posts into a fresh source list.
-
-After `wait_for_lead_list_ready`, call `confirm_lead_list` with the new
-source-list id and same campaign id. Pass `currentStep:"running"` to `confirm_lead_list` for an ACTIVE already-running campaign so the watched state
-returns to Running after same-campaign source rows are copied. Do not call
-`update_campaign` to fake this after the copy; `confirm_lead_list` owns the
-post-copy state transition.
-
 Before any source mutation, show exact approval evidence: workspace id,
 campaign id, workflow table id, source/provider id, source-list id when known,
 import caps, target dates/caps, dedupe/DNC/provider exclusion expectations, and
@@ -179,28 +135,11 @@ Before prep or approval mutation, reread `get_campaign_refill_state` and compare
 If they changed, stop. A second concurrent refill run must see the first run's
 import/prep state on reread and avoid duplicate work.
 
-After same-campaign source copy, inspect the actual campaign-table position of
-the copied rows before starting prep. Newly copied rows often land after the first 100 table rows. Use `get_campaign_table_schema` to read the `reviewBatch`,
-then use `select_campaign_cells` diagnostics against
-`rowSelector:{ type:"reviewBatch" }` for `enrich`, `generateMessage`, and
-`approved` roles when needed.
-
-If review-batch enrich cells are pending or Generate Message cells are
-dependency-blocked, omit `maxRowsToCheck` so the adaptive prep job can cover the
-bounded table scan, or set a bounded cap high enough to include appended rows
-when row count evidence requires it. Do not run a fixed `maxRowsToCheck:100` prep pass after appending rows to a larger existing campaign table; it can spend
-the whole budget on older rows and miss the refill batch.
-
 Scheduled success requires a post-action reread proving scheduler-owned cells
 with non-null `scheduledFor`. Prepared, approved, and ready-to-schedule rows are
 intermediate states; report them as awaiting scheduler unless scheduled cells
 are present.
 
-preparedMessages can remain 0 while scheduler-ready state changes downstream.
-After a prep job reaches a terminal state, run `wait_for_campaign_processing`
-when generated/pass counts are still settling, then poll `get_campaign_refill_state` until `readyToSchedule` drops, scheduled counts increase, or the state clearly
-remains awaiting scheduler. Do not force scheduler fields directly.
-
 ## Evergreen Campaign Discipline
 
 `fill_campaign_horizon` is a legacy evergreen-only lower-level primitive. Call it