@sellable/mcp 0.1.135 → 0.1.136

package/skills/create-campaign-v2/references/watch-guide-narration.md

@@ -195,24 +195,26 @@ After review batch import:
 ```json
 {
   "stage": "fit-message",
-  "headline": "Do you want filters?",
-  "visibleState": "The first review batch is in the campaign. The list is ready to decide whether extra filtering is worth it.",
-  "agentIntent": "Codex is asking whether you want to further filter these leads before message review. The Message Draft Builder may prepare a template in the background, but review waits until the filter path is settled.",
+  "headline": "I recommend adding filters",
+  "visibleState": "The first review batch is in the campaign. The visible sample looks mixed enough that filters should be added before message review.",
+  "agentIntent": "Codex is asking whether you want to further filter these leads before message review. Skip filters only if the visible rows already look clean.",
   "nextAction": "Choose filters or skip",
   "safety": "Nothing enriches, validates, or sends until the message is ready and approved.",
   "workerStatuses": {
-    "leadFitBuilder": "running",
-    "messageDraftBuilder": "running"
+    "leadFitBuilder": "idle",
+    "messageDraftBuilder": "idle"
   }
 }
 ```
 
 Use this after the selected review rows are present and before filters are
-saved. This is add-filters intent, not active filtering. Tell the user to
-Choose filters or skip, and do not say filtering the batch before rubrics and
-message approval are saved. When the user chooses filters, immediately persist
-`enableICPFilters: true` and move to `create-icp-rubric` so the watched app
-shows Filter Rules while Codex defines the rules in chat.
+saved. This is add-filters intent, not active filtering. Recommend adding
+filters when the sample is mixed/noisy, tell the user to Choose filters or skip,
+and do not say filtering the batch before rubrics and message approval are
+saved. Only show worker statuses as running if those branches actually started.
+When the user chooses filters, immediately persist `enableICPFilters: true` and
+move to `create-icp-rubric` so the watched app shows Filter Rules while Codex
+defines the rules in chat.
 
 Fit + message:
 

package/skills/find-leads/SKILL.md

@@ -147,6 +147,9 @@ Execution flow:
    - `campaignOfferId`
    - `currentStep`
    - `sourceLeadListId` OR `searchId`
+   - On success, `import_leads` owns the watched move to `confirm-lead-list`
+     after a lead list/job exists. Do not call `update_campaign` to fix the
+     import step.
 6. Call `wait_for_lead_list_ready` only for provider-imported lead lists (pass jobId/targetLeadCount from `import_leads` if available).
 7. Ask the user to review and confirm the list looks good.
 8. When the user confirms, call `confirm_lead_list` with:
@@ -154,8 +157,8 @@ Execution flow:
    - `sourceLeadListId` (or omit to use `selectedLeadListId`)
    - `jobId` (from `import_leads` when available; omit for direct CSV lead lists)
    - `targetLeadCount` (from `import_leads` when available)
-9. For campaign-builder flows, run post-confirm routing in this order:
-   - `update_campaign({ campaignId, currentStep: "filter-choice" })`
+9. For campaign-builder flows, `confirm_lead_list` owns the watched move to
+   `filter-choice` after the bounded review batch exists. Then run:
    - `wait_for_campaign_table_ready({ campaignId })`
    - `get_campaign_context({ campaignId, refresh: true })`
    - `get_rows_minimal({ tableId: workflowTableId, limit: 10, page: 1 })`

package/skills/generate-messages/SKILL.md

@@ -25,6 +25,31 @@ You craft messages in one of two modes:
 
 ## Execution Modes
 
+### Mode 0: Message Draft Builder Branch
+
+Use this mode when create-campaign-v2 starts the background Message Draft
+Builder after `confirm_lead_list` imports a non-empty bounded review batch.
+This is not the row-cell generation path.
+
+Inputs must come from the parent thread or scoped MCP/product tools for the
+current workspace/campaign:
+
+- campaign id plus campaign revision or `updatedAt`
+- current campaign brief and a brief hash
+- selected source state and `selectedLeadListId`
+- `workflowTableId`
+- imported review-batch contacts, row ids, and review-batch row hash
+- filter choice at branch start, plus filter/rubric basis when present
+
+Reject the branch as blocked if the campaign id, selected lead list, workflow
+table, or review-batch row ids/hash do not match. Do not reconstruct state from
+stale local markdown artifacts or direct database reads.
+
+Return compact output only: template recommendation, token fill rules, rendered
+sample, concerns, status, basis token, output timestamp/hash, and error or
+retry detail. Do not write message cells, enrich rows, update the campaign
+brief, attach sequence, or imply send readiness from this branch.
+
 ### Mode 1: Live Campaign Mode
 
 Use this mode when the caller provides a real `campaignId` or asks to save

package/skills/providers/prospeo.md

@@ -63,10 +63,11 @@ search_prospeo({
 - Use `import_leads` with `provider: \"prospeo\"` and the `searchId` to create a lead list and start import.
 - **IMPORTANT:** If `import_leads` returns `needsModeSelection: true`, use `AskUserQuestion` to ask "add to existing leads or replace?" Do NOT assume.
 - After the list finishes and the user confirms it looks good, call `confirm_lead_list` with the `jobId` and `targetLeadCount` from `import_leads` to import into the campaign table.
-- Post-confirm routing order is required:
-  1. `update_campaign({ currentStep: "filter-choice" })`
-  2. `wait_for_campaign_table_ready({ campaignId })`
-  3. `get_campaign_context({ campaignId, refresh: true })` then `get_rows_minimal(...)` for recommendation
+- `import_leads` owns the watched move to `confirm-lead-list` after a lead list/job exists.
+- `confirm_lead_list` owns the watched move to `filter-choice` after the bounded review batch exists.
+- Post-confirm readback order is required:
+  1. `wait_for_campaign_table_ready({ campaignId })`
+  2. `get_campaign_context({ campaignId, refresh: true })` then `get_rows_minimal(...)` for recommendation
 
 **Required:** Always include `campaignOfferId` on new `search_prospeo` calls so searches persist in watch mode.
 

package/skills/providers/sales-nav.md

@@ -352,7 +352,6 @@ User: "Save it"
 → import_leads({campaignOfferId: "cmp_xxx", searchId: "search_xxx", targetLeadCount: 100})
 → (wait for lead list to finish, ask user to confirm)
 → confirm_lead_list({campaignOfferId: "cmp_xxx", jobId: "<jobId from import_leads>", targetLeadCount: 100})
-→ update_campaign({campaignId: "cmp_xxx", currentStep: "filter-choice"})
 → wait_for_campaign_table_ready({campaignId: "cmp_xxx"})
 → get_campaign_context({campaignId: "cmp_xxx", refresh: true}) + get_rows_minimal(...)
 </iteration_example>
@@ -377,7 +376,7 @@ User: "Save it"
 - `confirm_lead_list` - Import confirmed lead list into campaign table
   Parameters: campaignOfferId, sourceLeadListId (optional), currentStep (optional)
   Only call after user confirms the list looks good
-  Post-confirm order: update_campaign(filter-choice) -> wait_for_campaign_table_ready -> get_campaign_context + get_rows_minimal
+  Owns the filter-choice beat after bounded review rows exist; then call wait_for_campaign_table_ready -> get_campaign_context + get_rows_minimal
   </mcp_tools>
 
 <limits>

package/skills/providers/signal-discovery.md

@@ -480,7 +480,7 @@ confirm_lead_list({
 
 Then run post-confirm routing in this order:
 
-1. `update_campaign({ campaignId: "cmp_xxx", currentStep: "filter-choice" })`
+1. `confirm_lead_list` owns the watched move to `filter-choice` after the bounded review batch exists; do not call `update_campaign` to fix that step.
 2. `wait_for_campaign_table_ready({ campaignId: "cmp_xxx" })`
 3. `get_campaign_context({ campaignId: "cmp_xxx", refresh: true })` then `get_rows_minimal(...)`