@sellable/mcp 0.1.150 → 0.1.152

package/skills/create-rubric/SKILL.md

@@ -51,8 +51,8 @@ Create and save a comprehensive lead scoring rubric that:
 
 ## Rubric Validation + Results
 
-- `mcp__sellable__get_rows_minimal` - Read bounded review-batch cell IDs
-- `mcp__sellable__queue_cells` - Queue only bounded `enrichCellId` values
+- `mcp__sellable__get_rows_minimal` - Read first review/process sample cell IDs
+- `mcp__sellable__queue_cells` - Queue only bounded sample `enrichCellId` values
 - `mcp__sellable__wait_for_rubric_results` - Poll pass-rate results
 
 `check_rubric` is legacy/recovery only. Do not use it in normal
@@ -207,8 +207,8 @@ update_campaign({
 
 This triggers the campaign sync and moves the user to the filter-leads step where they can see the campaign table with scoring columns.
 
-For normal create-campaign-v2 runs, the caller should immediately queue only the
-bounded review-batch enrichment cells and wait for scores. For standalone
+For normal create-campaign-v2 runs, the caller should queue only the first
+review/process sample enrichment cells after message approval. For standalone
 rubric editing, ask the user if we should kick off enrichment for a sample:
 
 "ICP filtering enabled — you should see the leads table with scoring columns now. Want me to run enrichment on the first 5 leads to check pass rates?"
@@ -219,7 +219,7 @@ rubric editing, ask the user if we should kick off enrichment for a sample:
 ## Phase 5: Enrich + Score a Sample
 
 1. Call `get_rows_minimal({ tableId, limit: 5 })` or use the caller-provided
-   bounded review-batch rows.
+   review/process sample rows.
 2. Call `queue_cells({ tableId, cellIds })` with only pending/error
    `enrichCellId` values. Do not pass `icpCellId` values or full-table cells;
    the workflow cascade handles downstream ICP scoring after enrichment.

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)
-   - `targetLeadCount` (from `import_leads` when available)
+   - `reviewBatchLimit: 15` for the first review/process sample
 9. For campaign-builder flows, `confirm_lead_list` owns the watched move to
-   `filter-choice` after the bounded review batch exists. Then run:
+   `filter-choice` after the first review/process sample 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

@@ -28,7 +28,8 @@ You craft messages in one of two 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.
+Builder after `confirm_lead_list` copies source rows and the first
+review/process sample exists.
 This is not the row-cell generation path.
 
 Inputs must come from the parent thread or scoped MCP/product tools for the

package/skills/providers/prospeo.md

@@ -62,14 +62,14 @@ search_prospeo({
 - Pass `searchId` on subsequent pages to paginate.
 - 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.
-- Default source target is about 150 good-fit leads, capped at 2,500 source candidates for now.
+- Default source import target is about 1,000 source contacts. Use the provider cap internally when the raw pool is larger; do not present that cap as the customer-facing plan unless it is reached.
 - Apply the campaign source planning floor: the sampled/projected good-fit rate
   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 the review-batch `targetLeadCount` from the active campaign defaults to import only the review batch into the campaign table.
+- 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.
 - `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.
+- `confirm_lead_list` owns the watched move to `filter-choice` after confirmed campaign rows exist.
 - 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

package/skills/providers/sales-nav.md

@@ -354,9 +354,9 @@ Step 4 - Final Search + Confirm:
 What would you like?"
 
 User: "Save it"
-→ import_leads({campaignOfferId: "cmp_xxx", searchId: "search_xxx", targetLeadCount: 300})
+→ import_leads({campaignOfferId: "cmp_xxx", searchId: "search_xxx", targetLeadCount: 1000})
 → (wait for lead list to finish, ask user to confirm)
-→ confirm_lead_list({campaignOfferId: "cmp_xxx", jobId: "<jobId from import_leads>", targetLeadCount: 25})
+→ confirm_lead_list({campaignOfferId: "cmp_xxx", jobId: "<jobId from import_leads>", reviewBatchLimit: 15})
 → wait_for_campaign_table_ready({campaignId: "cmp_xxx"})
 → get_campaign_context({campaignId: "cmp_xxx", refresh: true}) + get_rows_minimal(...)
 </iteration_example>
@@ -378,17 +378,17 @@ User: "Save it"
   Call after user selects a search to save
   **IMPORTANT:** If response returns `needsModeSelection: true`, use `AskUserQuestion` to ask "add to existing leads or replace?" Do NOT assume.
 
-- `confirm_lead_list` - Import confirmed lead list into campaign table
-  Parameters: campaignOfferId, sourceLeadListId (optional), currentStep (optional)
+- `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 bounded review rows exist; then call wait_for_campaign_table_ready -> get_campaign_context + get_rows_minimal
+  Owns the filter-choice beat after campaign rows exist; process only the first 15 review rows until later approvals
   </mcp_tools>
 
 <limits>
 - 25 results per page
 - Maximum 100 pages (2,500 leads)
-- Default source target: about 150 good-fit leads, capped at 2,500 source
-  candidates for now
+- Default source import target: about 1,000 source contacts. The provider cap is
+  internal; do not present it as the customer-facing plan unless it is reached.
 - Maximum 5 search calls per session
 - If user needs more than 2,500: explain limit, suggest splitting by region
 </limits>

package/skills/providers/signal-discovery.md

@@ -450,15 +450,16 @@ to say **yes**.
 
 For `create-campaign-v2` after the user has already approved the lead-source
 decision, that approval is the explicit confirmation to materialize the approved
-source list and then import only the bounded campaign review batch. In that
+source list and then copy the confirmed source rows into the campaign. In that
 tail flow, follow `create-campaign-v2-tail`: call
 `select_promising_posts({ campaignOfferId, selectionMode: "replace",
 selections, headlineICPCriteria })`, then call
 `import_leads({ campaignOfferId, provider: "signal-discovery",
-targetLeadCount, targetEngagerCount, maxPostsToScrape })` for the approved
+targetEngagerCount, maxPostsToScrape })` for the approved
 source-capacity plan without asking for another yes/no gate. Then
-`confirm_lead_list` imports only the bounded review batch into the campaign
-table. Do not confuse the source-candidate target with the review-batch size.
+`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.
 If the completed source scrape comes back below the approved source-candidate
 target, do not call `confirm_lead_list`; select more posts, rerun source
 discovery, or move to Sales Nav.
@@ -474,9 +475,8 @@ the source-list materialization.
 ```json
 import_leads({
   "campaignOfferId": "cmp_xxx",
-  "targetLeadCount": 1000,
-  "targetEngagerCount": 1000,
-  "maxPostsToScrape": 5
+  "targetEngagerCount": 1500,
+  "maxPostsToScrape": 3
 })
 ```
 
@@ -488,13 +488,13 @@ After the lead list finishes and the user confirms it looks good, call:
 confirm_lead_list({
   "campaignOfferId": "cmp_xxx",
   "jobId": "<jobId from import_leads>",
-  "targetLeadCount": 25
+  "reviewBatchLimit": 15
 })
 ```
 
 Then run post-confirm routing in this order:
 
-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.
+1. `confirm_lead_list` owns the watched move to `filter-choice` after confirmed campaign rows exist; 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(...)`
 
@@ -516,8 +516,8 @@ Then run post-confirm routing in this order:
 5. Standalone Signal Discovery flow: ask for explicit confirmation to import
    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 bounded review
-   batch; do not ask again.
+   decision, that approval is the import confirmation for the source list and
+   first review sample; 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

package/skills/create-campaign-v2/references/message-review-safety-gate.md

@@ -1,162 +0,0 @@
-# Message Review Safety Gate
-
-Use this reference for `create-campaign-v2` message review only in two cases:
-when these rules are embedded inside the `post-find-leads-message-scout` agent
-prompt, or when the host cannot launch that agent and the parent thread needs a
-self-contained safety gate. It is the campaign-launch subset of
-`generate-messages`: enough to prove a truthful first-send message, rendered
-token examples, and an approval decision without loading the full long-form
-message-generation prompt into the main Claude/Codex thread.
-
-In a normal installed Claude/Codex session, the message scout owns these rules.
-The parent-thread asset is a compatibility safety path, not a fast-mode prompt
-or a shortcut. Do not load the full `generate-messages` subskill in this flow. If
-the safety gate is missing a needed campaign-specific rule or the draft fails
-quality gates, stop at `revise-messaging` with the exact missing rule/failure
-instead of pulling the long prompt into the main thread.
-
-## Required Workflow
-
-1. Read the live campaign basis: campaign id, campaign revision or
-   `campaignUpdatedAt`, campaign brief content, selected source decision,
-   selected lead list/source state, `workflowTableId`, imported review-batch
-   row ids/hash, and any saved rubric/filter summary supplied by the parent.
-2. Pick 2-3 sample rows from the imported review-batch rows, preferring rows
-   that pass the saved rubrics or are likely to pass. Do not invent new rows.
-3. Build the message from the approved campaign brief, selected source context,
-   sampled rows, and explicit user answers. Use only proof that appears in that
-   live basis. Unsupported reply-rate, meeting-rate, ROI, revenue, and
-   customer-logo claims are blocked.
-4. Return a compact message recommendation to the parent thread. Do not write
-   local markdown/json artifacts in normal customer runs; emit debug artifacts
-   only when the parent explicitly asks for debug/UAT output.
-5. Render the customer-facing message review in chat before asking for approval.
-   Keep chat lightweight: show the tokenized template and one strong rendered
-   good-fill example only. Do not print the token notes table, omit/fallback
-   example, or bad-fill analysis in chat unless the user explicitly asks.
-   After approval, the parent persists template, token rules, fallback guidance,
-   and bad-fill avoidance notes into campaign state with `update_campaign_brief`.
-6. Ask exactly `approve-message` or `revise-messaging`. Do not import, queue,
-   attach sequence, or start before `approve-message`.
-
-## Required Message Recommendation Sections
-
-- `Status`
-- `Mode`
-- `Lead Sample Basis`
-- `Strongest Reply Reason`
-- `Campaign Element Pool`
-- `Gold Standard Strategy Map`
-- `Current Campaign Translation`
-- `Token Fill Rules`
-- `Token Adherence Table`
-- `Angle Drafts`
-- `Kill / Combine Review`
-- `Finalizer Pass`
-- `Gold-Standard Quality Gate`
-- `Skeptical Prospect Review`
-- `Winner Gate`
-- `Selected Winner`
-- `Findings`
-- `Recommendation`
-
-Keep this recommendation concise. It should prove the reasoning path, not
-reproduce the full framework.
-
-## Message Quality Gates
-
-- The selected winner must be one first outbound send only. No post-accept DM,
-  follow-up, cadence branch, or sequence copy.
-- The message must explain what the product is and what it does in plain
-  language before asking for a call.
-- The message must use a truthful buyer-side reply reason, not just sender
-  biography.
-- If using a template, include at least one supported `{{token}}` and show a
-  complete rendered good-fill example and complete rendered omit/fallback
-  example.
-- Do not use internal tokens such as `{{profile_signal}}` in customer-facing
-  copy.
-- Do not put bracketed instructions in the message body, such as `[ROW_BRIDGE]`,
-  `[insert]`, `[generated]`, or any instruction for a later model to fill.
-- Optional row-specific personalization must be grounded in a row field or
-  omitted entirely. Never use generic filler like "your work" or "your team."
-- Engagement-source personalization is a special case, not the default opener.
-  Do not write `saw you {{engagement_context}} on {{post_context}}`, `saw you
-reacted to`, `saw you engaging with`, or equivalent source-citation copy as a
-  default hook. Only refer to the prospect's engagement when the line is
-  self-aware and low-certainty, for example `not sure if this is too specific,
-but the [topic] thread felt close enough to send`. Otherwise omit the
-  engagement signal and use role/company/problem context.
-- Subject lines should be short, buyer-relevant, and specific. Avoid
-  `quick question`, `demo`, `founder call`, sender names, and generic `outbound`.
-- If the message is plausible but not ready to send, set
-  `Recommendation: revise-messaging`.
-
-## Internal Message Recommendation
-
-The message scout or parent safety gate should still produce complete internal
-review data: token-fill rules, one rendered omit/fallback example, and bad-fill
-avoidance notes. This data is for campaign-brief persistence and safety checks,
-not for the default chat approval packet.
-
-## Customer-Facing Message Review
-
-Render this in chat before asking. Use Markdown structure so the approval target
-is visually scannable and low-overhead:
-
-````markdown
-Status: message-review
-
-## Message Template
-
-**Subject**
-
-```text
-{{tokenized_subject}}
-```
-
-**Body**
-
-```text
-{{tokenized_message_body}}
-```
-
-## Rendered Example
-
-### Example
-
-Good token fill:
-
-```text
-Subject: ...
-
-Hey First,
-
-...
-```
-
-## Recommendation
-
-**My take:** ...
-
-**Suggested adjustment:** ...
-
-**Question:** approve-message or revise-messaging?
-
-**Recommendation:** approve-message
-````
-
-Formatting requirements:
-
-- Put the tokenized template and rendered example in fenced `text` blocks
-  so chat gives them a distinct background.
-- The chat example must contain a complete rendered subject + body, not a
-  bullet list of token names or a single bridge-line fragment.
-- Do not show `Good omit / fallback`, `Bad fill to avoid`, or `Token Notes` in
-  the default chat approval packet. Keep those in the internal recommendation
-  and persist them to the campaign brief after approval.
-- Keep reasoning outside the code blocks so the blocks are easy to inspect and
-  approve.
-
-`My take` and `Suggested adjustment` must be specific. The adjustment can be
-"approve as-is, or revise once to X if you want Y"; it must not be empty.