@sellable/install 0.1.200 → 0.1.201

package/package.json

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

package/skill-templates/create-campaign.md

@@ -90,6 +90,9 @@ execution slice configures filters and messages. After that, the user chooses
 whether to use filters or skip.
 When filters are chosen, save rubrics, get filter approval, then wait for
 message-template approval before enrichment/filtering or Generate Message cells.
+Filter work stays in the parent thread and must inspect visible campaign rows
+with `get_rows_minimal` / `get_rows` before drafting and saving rubrics; use at
+most one direct `enrich_with_prospeo` sample when row evidence is too thin.
 After filter approval, Filter Leads should show `Filters saved + waiting for
 message approval` until the template is approved.
 The default path stays the existing first campaign-table execution slice:
@@ -97,17 +100,19 @@ review the normal `reviewBatchLimit:15`, approve reviewed draft rows, then move
 to Settings/sequence/final greenlight. Only call
 `start_campaign_message_preparation` when the user explicitly asks for more
 prepared messages or a send count. If the user says "prepare/generate X
-messages", set `targetPreparedMessages:X`, let the backend derive
-`maxRowsToCheck:min(2500,max(300,X*5))`, and keep
-`approvalMode:"mark_ready"`. The backend samples up to 100 rows first, then
-adapts later batches up to 250 rows while recalculating yield. Poll
+messages", set `targetPreparedMessages:X`, omit `maxRowsToCheck`, and keep
+`approvalMode:"mark_ready"`. The backend calibrates on at least 100 rows,
+estimates the row budget from observed rubric/pass yield, caps
+`maxRowsToCheck` at 2500, then adapts later batches up to 250 rows while
+recalculating yield. Poll
 `get_campaign_message_preparation_status` for preparation-job status: checked
-rows, prepared/approved count, target, row budget remaining, and stop reason. If
-the user says "approve X messages", use `approvalMode:"approve"` but still do
-not launch. If the user says "schedule X sends", use `approvalMode:"approve"`
-to approve exactly the bounded X-message cohort during preparation, then
-continue through sender, sequence, and final launch greenlight; the launch path
-must verify that bounded cohort and must not broad approve-all.
+rows, passed/prepared/approved count, target, estimated row budget remaining,
+and stop reason. If the user says "approve X messages", use
+`approvalMode:"approve"` but still do not launch. If the user says "schedule X
+sends", use `approvalMode:"approve"` to approve exactly the bounded X-message
+cohort during preparation, then continue through sender, sequence, and final
+launch greenlight; the launch path must verify that bounded cohort and must not
+broad approve-all.
 Treat `campaignId` as `CampaignOffer.id`. Low level selector/queue tools are
 diagnostics and recovery only for this lane. If the user asks to stop
 preparation, the target is wrong, or status shows the wrong campaign/table, call
@@ -480,14 +485,14 @@ automation just because a watch link exists. If `create_campaign` returns
 `watchHandoff.markdown`, print that exact value once, directly before the brief
 approval question. It will use the URL mode to say Codex or Claude Code:
 
-````markdown
+```markdown
 > **WATCH CODEX BUILD THE CAMPAIGN LIVE**
 >
 > [Open live campaign builder]({watchUrl})
 >
 > Keep this chat open. I'll ask approval questions here before making decisions
 > that need your judgment.
-````
+```
 
 The rendered callout is intentional: rendered chat clients highlight the
 headline, link, and note without treating it as a code block, and plain terminals
@@ -969,7 +974,7 @@ updates.
    is ready.
    Do not ask the user to approve the brief before shell creation unless they
    explicitly requested a no-write draft; the shell itself is the review surface.
-6. The main thread owns watch navigation. Call
+7. The main thread owns watch navigation. Call
    `mcp__sellable__update_campaign({ campaignId, currentStep })` before major
    visible work so the user can watch progress in the app: `create-offer` for
    the brief, `pick-provider` or the selected provider step while sourcing,
@@ -984,9 +989,9 @@ updates.
    job has reported compact checked/prepared/stop status, `settings` for sender
    selection, `sequence` after sender attach, and `send` once the recommended
    sequence is attached. Do not advance the step backward.
-7. Keep `selectedLeadListId` as the source list and `workflowTableId` as the
+8. Keep `selectedLeadListId` as the source list and `workflowTableId` as the
    campaign table. Do not use disk files as the post-mint source of truth.
-8. Do not ask the user to run another command.
+9. Do not ask the user to run another command.
 
 ## Fallback