@sellable/mcp 0.1.151 → 0.1.153

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

@@ -24,12 +24,34 @@ When the user asks to find posts or start searching, **IMMEDIATELY begin Round 1
 
 <lead_target>
 
-- **Default: provider max import count** (use this unless user specifies otherwise; see `lead-import-limits.json`, currently 2,500)
-- **Maximum: provider max import count**
+- **Default create-campaign target: ~300 good-fit prospects after cleanup,
+  enrichment, and fit filtering.**
+- **Working assumption when no stronger sample exists: ~20% of raw post
+  engagers become good-fit prospects, so plan around ~1,500 raw engagers.**
+- Provider/import caps are internal execution limits, not customer-facing
+  promises. Do not tell the user the internal provider cap.
 - Quality > Quantity: a few hundred active users > 1000 potentially inactive profiles
 - Focus on ACTIVE platform users who will actually see and respond to outreach
   </lead_target>
 
+<harvest_scrape_contract>
+
+Production Signal Discovery uses Harvest for post comments and reactions.
+Harvest returns about 100 comments or reactions per page. The source scrape
+pages through Harvest up to the configured per-post caps, currently 1,500
+reactions and 300 comments per selected post.
+
+Important interpretation rule: a source list row count is the number of
+headline-passing candidates inserted after scraping and filtering, not the raw
+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.
+
+</harvest_scrape_contract>
+
 <multi_round_search>
 
 ## Multi-Round Search Strategy
@@ -98,12 +120,12 @@ You must estimate:
   - expected good-fit prospects per right-content post after dedupe/cleanup
 - `postsNeededForTarget`
   - number of right-content posts needed to reach the target good-fit lead
-    count, defaulting to 150 for Signal Discovery unless the campaign says
+    count, defaulting to 300 for Signal Discovery unless the campaign says
     otherwise
 - `requiredEngagersToScrape`
-  - `ceil(targetGoodFitLeads / sampledFitRate)`; for example 15 good-fit
-    prospects per 100 engagers means a 150-good-fit source target needs about
-    1,000 engagers scraped
+  - `ceil(targetGoodFitLeads / sampledFitRate)`; for example the default
+    planning assumption of 20 good-fit prospects per 100 engagers means a
+    300-good-fit source target needs about 1,500 raw engagers scraped
 - `planningFloor`
   - minimum acceptable sampled/projected fit rate after conservative cleanup;
     default 10%. Below this, do not scale Signal Discovery.
@@ -119,8 +141,8 @@ Use conservative logic:
      those posts in the watched Signal Discovery UI before sampling engagers
    - call `fetch_post_engagers`
    - fetch only a representative first sample, not a full scrape
-   - default to `limit: 25` for one post or `limit: 20` per post when checking two posts
-   - inspect roughly 25-40 engagers total
+   - default to a fast first sample of roughly 15 people for one post; when
+     comparing multiple posts, inspect roughly 15-40 people total
    - score them against `headlineICPCriteria` or a rough yes/no headline rubric
    - use headline and display-name cues only for this spot check; do not enrich people during viability estimation
    - use that sampled pass rate to extrapolate conservatively
@@ -130,7 +152,7 @@ Use conservative logic:
    - stale posts
    - adjacent communities that are not actual buyers
 4. Explain the pass-through briefly and explicitly:
-   - preferred: "`sampledCount`: 40, `passCount`: 9, `passRate`: ~22%, `goodFitPer100Engagers`: ~22 before cleanup / ~13-16 after cleanup, `requiredEngagersToScrape`: ~940-1,150 for a 150-good-fit target after cleanup, `avgReachableEngagersPerPost`: 240, `goodFitProspectsPerPost`: ~31-38, `postsNeededForTarget`: ~4-5, `recentStrongPostCount`: 15-25, `freshEnoughPostCount`: 8-12, `projectedRange`: 150-190 from selected posts"
+   - preferred: "`sampledCount`: 40, `passCount`: 9, `passRate`: ~22%, `goodFitPer100Engagers`: ~22 before cleanup / ~13-16 after cleanup, `requiredEngagersToScrape`: ~1,875-2,300 for a 300-good-fit target after cleanup, `avgReachableEngagersPerPost`: 240, `goodFitProspectsPerPost`: ~31-38, `postsNeededForTarget`: ~8-10, `recentStrongPostCount`: 15-25, `freshEnoughPostCount`: 8-12, `projectedRange`: 300-380 from selected posts"
    - fallback: "I could not fetch engagers, so this is inferred from post and author quality only"
 5. If the evidence is too weak, say so and return a low-confidence estimate instead of pretending precision.
 6. If sampled/projected fit after cleanup is below the 10% planning floor,
@@ -385,7 +407,7 @@ For `create-campaign-v2` source approval, do not treat the default
 `selectionTarget` of 3 posts as enough by itself. Before the final source
 recommendation, estimate source capacity from real sample math:
 
-- source target good-fit leads (default 150 for Signal Discovery unless the
+- source target good-fit leads (default 300 for Signal Discovery unless the
   campaign says otherwise)
 - eligible right-content posts by lane/content type
 - reachable engagers from those posts
@@ -450,18 +472,21 @@ 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.
+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.
+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.
 
 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
@@ -474,9 +499,8 @@ the source-list materialization.
 ```json
 import_leads({
   "campaignOfferId": "cmp_xxx",
-  "targetLeadCount": 1000,
-  "targetEngagerCount": 1000,
-  "maxPostsToScrape": 5
+  "targetEngagerCount": 1500,
+  "maxPostsToScrape": 3
 })
 ```
 
@@ -488,13 +512,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 +540,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