@sellable/mcp 0.1.153 → 0.1.155

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

@@ -17,8 +17,8 @@ table.
 ## MANDATORY TOOL ORDER (read this BEFORE any tail step)
 
 Every tail run MUST call these tools in this exact order. The tail is
-**first-sample cascade-driven**: you kick off Enrich Prospect only for
-the first review/process sample, and the workflow engine chains DNC Check →
+**initial-slice cascade-driven**: you kick off Enrich Prospect only for
+the initial campaign-table execution slice, and the workflow engine chains DNC Check →
 ICP Score → Passes Rubric → Generate Message automatically. Your job is
 to START the bounded cascade, WAIT until filter results land, OBSERVE message
 generation as soon as one row passes, and stop for review.
@@ -26,13 +26,13 @@ Do NOT manually run rubric-check, enrich, or message-generation
 tools — the cascade already does them.
 
 ```text
-Step 13 — materialize source list + confirm first sample
+Step 13 — materialize source list + confirm initial campaign slice
   materialize/reuse approved source with campaignOfferId
   import_leads(source-list target; SalesNav/Prospeo default ~1000, Signal Discovery default ~1500 engagers)
   wait_for_lead_list_ready
   confirm_lead_list(reviewBatchLimit=15)
   wait_for_campaign_table_ready    # campaign table exists
-  get_rows_minimal                 # read first review/process sample
+  get_rows_minimal                 # read initial campaign-table execution slice
   update_campaign(currentStep=filter-choice)
 
 Post-import main thread
@@ -42,10 +42,10 @@ Post-import main thread
   keep the watched app on Filter Leads after rubrics are saved
   while on Filter Leads, show the message template recommendation from the background Message Draft Builder
   after approve-message, update_campaign_brief writes `## Approved Message Template` with `{{...}}` tokens
-  only then start the first-sample cascade
+  only then start the initial-slice cascade
 
-Step 14 — kick first-sample cascade + observe sample
-  queue_cells(cellIds=<first 15 review/process Enrich Prospect cells only>)  <-- starts bounded chain
+Step 14 — kick initial-slice cascade + observe campaign rows
+  queue_cells(cellIds=<first 15 campaign-table execution-slice Enrich Prospect cells only>)  <-- starts bounded chain
   wait_for_campaign_table_ready    # wait until sample cascade starts returning filter results
   get_rows_minimal                 # read passesRubric + message cell status per row
   wait_for_rubric_results(minPassedCount=1, includeRows=false)
@@ -75,7 +75,7 @@ Step 16 — awaiting-user-greenlight
   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
   if the attach response did not move the UI: update_campaign(currentStep=send)
-  re-surface watchUrl + review-batch orientation + final launch choices
+  re-surface watchUrl + campaign setup orientation + final launch choices
   STOP. DO NOT call start_campaign. DO NOT move to running without explicit launch greenlight.
 ```
 
@@ -128,10 +128,10 @@ Message` column's http_request writes those cells via the cascade.
   any are pending, call `queue_cells` on those generateMessageCellIds
   and wait. If rows truly won't message, ESCALATE.
 - You MAY NOT advance past Step 13 without calling `queue_cells` on
-  the review-batch Enrich Prospect cells. Without it, every downstream
+  the initial-slice Enrich Prospect cells. Without it, every downstream
   cell stays `pending` and the campaign ships empty.
-- You MAY NOT queue enrichment for rows outside the configured review
-  batch before the user approves expansion. Full-list enrichment/message
+- You MAY NOT queue enrichment for rows outside the configured internal
+  execution slice before the user approves expansion. Full-list enrichment/message
   generation is a credit-spend decision and must happen after the user
   has reviewed the sample.
 
@@ -165,8 +165,8 @@ Entered from the lead-source confirmation path, with
 import milestone.
 
 > Reminder: every provider search you run from this point forward — the
-> review-batch source rerun in Step 13, any expansion search after the
-> review batch, alternate-lane probes, account-based reruns, and operator
+> campaign setup source rerun in Step 13, any expansion search after the
+> initial slice, alternate-lane probes, account-based reruns, and operator
 > follow-ups — MUST include `campaignOfferId`. This applies to
 > `search_prospeo`, `search_sales_nav`, `search_apollo`,
 > `search_signals`, and any other provider search tool added later.
@@ -220,9 +220,9 @@ reviewBatchLimit: 15 })`. Do not call `import_leads` for this
      `domainFilterId`; run a campaign-associated Prospeo people search with
      `campaignOfferId`, provider prompt preflight, and that `domainFilterId`;
      then import with `targetLeadCount` set to the approved source-list target
-     (default about 1,000). The first 15 copied campaign rows are the
-     review/process sample; the full confirmed source list is copied into the
-     campaign for later expansion.
+     (default about 1,000). The first copied campaign rows are the internal
+     execution slice; the full confirmed source list is copied into the campaign
+     for later expansion.
      Persist or recover materialized IDs on resume: `leadListId`,
      `domainFilterId`, `searchId`, `selectedLeadListId`, `workflowTableId`, and
      imported row IDs. If the source file changed after preview, or an existing lead list
@@ -263,10 +263,10 @@ searchId, targetLeadCount: 1000 })`.
 3. `wait_for_lead_list_ready` when a provider import job exists, then
    `confirm_lead_list`. Persist both identifiers: `selectedLeadListId` remains
    the source list and `workflowTableId` is the campaign table.
-4. `wait_for_campaign_table_ready` until the first review/process sample rows are
+4. `wait_for_campaign_table_ready` until the initial campaign-table execution slice rows are
    available in the campaign table.
-5. Call `get_rows_minimal({ tableId: workflowTableId })` and confirm the first
-   15-row review/process sample is present. Do not queue cells in Step 13.
+5. Call `get_rows_minimal({ tableId: workflowTableId })` and confirm the
+   15-row internal execution slice is present. Do not queue cells in Step 13.
 6. If the import returns zero usable leads, ESCALATE per
    `references/escalation-ladder.md` (hard fail).
 7. `update_campaign({ campaignId, currentStep: "filter-choice" })`.
@@ -288,7 +288,7 @@ Do not route to a visible `validate-sample` step. Full decision tree lives in
 `references/sample-validation-loop.md`.
 
 **Step 14 starts the bounded fit cascade, then observes it.** Step 13 imported
-the review batch only. After `save_rubrics`, Step 14 queues the review-batch
+the internal execution slice only. After `save_rubrics`, Step 14 queues the initial-slice
 Enrich Prospect cells, waits until filter results start landing, then moves to
 message observation as soon as one row passes and approved-template message
 generation is ready. Step 15 opens review as soon as one passing generated message
@@ -351,9 +351,9 @@ Signals underfloor results), then offer revise-filter only if the imported rows
 look close to ICP but the rubric is too strict. This prevents customer-visible
 loops where the agent keeps asking to retry the same weak source.
 
-When the sample passes the projected-pass floor, call
+When the internal slice passes the projected-pass floor, call
 `update_campaign({ campaignId, currentStep: "auto-execute-messaging" })`
-and orient the user that messaging will complete for the review batch only.
+and orient the user that messaging will complete for the initial campaign rows only.
 
 ## Step 15: auto-execute-messaging
 
@@ -367,7 +367,7 @@ flow through the column pipeline: `Enrich Prospect` →
 `DNC Check` → `ICP Score` → `Passes Rubric` → `Generate Message`.
 Each column's http_request auto-fires when its upstream dependency
 completes AND passes gate (e.g. `Passes Rubric === true` before
-`Generate Message`). Your job in Step 15 is to WAIT for the review-batch
+`Generate Message`). Your job in Step 15 is to WAIT for the initial-slice
 cascade to reach `Generate Message` for rows that passed ICP, and verify
 the output — not to generate messages manually.
 
@@ -536,14 +536,14 @@ runs.
 
 ## Tail Hard Rules
 
-- Source-list materialization and first-sample confirmation happen in Step 13,
+- Source-list materialization and initial-slice confirmation happen in Step 13,
   not during atomic mint.
 - Step 13 materializes/reuses the approved source with `campaignOfferId` before
   import. Do not import a legacy campaignless Signal source until selected posts
   exist on the campaign.
-- Full-list expansion happens only after the first review flow proves out. The
-  first enrichment/scoring pass must stay capped to the 15-row review/process
-  sample.
+- Full-list expansion happens only after the initial campaign setup proves out.
+  The first enrichment/scoring pass must stay capped to the internal
+  campaign-table execution slice.
 - The tail NEVER calls `start_campaign` on its own.
 - The tail NEVER auto-revises leads. Brief revision is autonomous; lead
   revision is always operator-gated.

package/skills/create-rubric/SKILL.md

@@ -51,7 +51,7 @@ Create and save a comprehensive lead scoring rubric that:
 
 ## Rubric Validation + Results
 
-- `mcp__sellable__get_rows_minimal` - Read first review/process sample cell IDs
+- `mcp__sellable__get_rows_minimal` - Read initial campaign-table execution-slice cell IDs
 - `mcp__sellable__queue_cells` - Queue only bounded sample `enrichCellId` values
 - `mcp__sellable__wait_for_rubric_results` - Poll pass-rate results
 

package/skills/find-leads/SKILL.md

@@ -162,9 +162,9 @@ Execution flow:
    - `campaignOfferId`
    - `sourceLeadListId` (or omit to use `selectedLeadListId`)
    - `jobId` (from `import_leads` when available; omit for direct CSV lead lists)
-   - `reviewBatchLimit: 15` for the first review/process sample
+   - `reviewBatchLimit: 15` for the internal campaign-table execution slice
 9. For campaign-builder flows, `confirm_lead_list` owns the watched move to
-   `filter-choice` after the first review/process sample exists. Then run:
+   `filter-choice` after the initial campaign-table execution slice 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/providers/prospeo.md

@@ -67,7 +67,7 @@ search_prospeo({
   after cleanup should be at least 10%. Prospeo is the terminal fallback; if the
   best reasonable Prospeo lane is still below 10%, tighten the ICP/source
   direction instead of switching to another provider.
-- After the list finishes and the user confirms it looks good, call `confirm_lead_list` with the `jobId` and `reviewBatchLimit: 15` to copy confirmed rows into the campaign table and use the first 15 as the review/process sample.
+- After the list finishes and the user confirms it looks good, call `confirm_lead_list` with the `jobId` and `reviewBatchLimit: 15` to copy confirmed rows into the campaign table and use the first 15 as the internal campaign-table execution slice.
 - `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 confirmed campaign rows exist.
 - Post-confirm readback order is required:

package/skills/providers/sales-nav.md

@@ -381,7 +381,7 @@ User: "Save it"
 - `confirm_lead_list` - Copy confirmed lead list into campaign table
   Parameters: campaignOfferId, sourceLeadListId (optional), reviewBatchLimit (optional, default 15), currentStep (optional)
   Only call after user confirms the list looks good
-  Owns the filter-choice beat after campaign rows exist; process only the first 15 review rows until later approvals
+  Owns the filter-choice beat after campaign rows exist; process only the internal campaign-table execution slice until later approvals
   </mcp_tools>
 
 <limits>

package/skills/providers/signal-discovery.md

@@ -47,8 +47,8 @@ number of engagers fetched. If a selected post has 1,200 visible engagers and
 the source list lands at 71 rows, read that as 71 headline-passing inserted
 rows, not as "only 71 engagers were scraped." Do not reject a completed
 non-empty source list solely because inserted rows are below the raw engager
-target; confirm/copy it for the 15-row review sample, then decide whether to add
-more posts or switch lanes based on sample quality and scale.
+target; confirm/copy it for campaign setup, then decide whether to add more
+posts or switch lanes based on source quality and scale.
 
 </harvest_scrape_contract>
 
@@ -480,13 +480,13 @@ selections, headlineICPCriteria })`, then call
 targetEngagerCount, maxPostsToScrape })` for the approved
 source-capacity plan without asking for another yes/no gate. Then
 `confirm_lead_list({ reviewBatchLimit: 15 })` copies confirmed source rows into
-the campaign table and returns the first 15 review/process rows. Do not confuse
-the source-candidate target with the review sample size.
+the campaign table and returns the internal campaign-table execution slice. Do not confuse
+the source-candidate target with the execution-slice size.
 If the completed source scrape comes back below the approved source-candidate
 target but has usable rows, still call `confirm_lead_list` so the completed
-source list is copied into the campaign and the first 15 rows can be reviewed.
+source list is copied into the campaign and the initial setup slice can run.
 Treat the shortfall as a scale warning: add more approved posts or move to Sales
-Nav only after the first sample proves the lane is too thin or off-ICP.
+Nav only after source quality proves the lane is too thin or off-ICP.
 
 The promotion/select step is required campaign state. Use post IDs from the
 current campaign-scoped search result, not stale IDs copied from a source review
@@ -541,7 +541,7 @@ Then run post-confirm routing in this order:
    leads (e.g., "Does this look right? Should I import leads now?").
    `create-campaign-v2` tail flow: if the user already approved the source
    decision, that approval is the import confirmation for the source list and
-   first review sample; do not ask again.
+   internal campaign setup slice; do not ask again.
 6. If confirmation exists, call `import_leads`. If not, refine
    selections/criteria and ask again.
 7. When the lead list finishes and the user confirms it looks good, call