@sellable/mcp 0.1.154 → 0.1.156

package/skills/create-campaign-v2/references/sample-validation-loop.md

@@ -7,13 +7,13 @@ on every revision round.
 ## Principle
 
 We spend a bounded review/process sample (default 15 rows) to prove fit before
-the user spends credits on the rest of the confirmed source list. The sample loop has one job:
+the user spends credits on the rest of the confirmed source list. The setup loop has one job:
 answer the question "do we have enough real passing examples for the user to
 judge this campaign?" Message generation starts earlier: the first row that
 passes filters is enough to begin observing or queueing Generate Message for
 that passing row.
 
-If the answer is yes, proceed to Step 15 messaging for the review sample. If
+If the answer is yes, proceed to Step 15 messaging for the initial campaign rows. If
 the answer is no, diagnose whether the brief is wrong or the list is wrong,
 and either revise brief autonomously OR escalate to the user — never
 auto-revise leads.
@@ -25,7 +25,7 @@ auto-revise leads.
   not a visible route)
 - Approved message template/token rules exist in the campaign brief before any
   enrichment or scoring cells are queued
-- Confirmed campaign rows from Step 13, with first review/process sample from
+- Confirmed campaign rows from Step 13, with the internal execution slice from
   `reviewBatchRowIds` (size: `importLimit`, default 15)
 - Config from `auto-execute.yaml`: `sample.sampleSize`,
   `sample.minProjectedPass`, `sample.maxRevisionRounds`
@@ -57,9 +57,9 @@ auto-revise leads.
    scoring from the queued Enrich Prospect cells
 
 6. wait_for_rubric_results(sample, targetCount = <cohortSize>, minPassedCount = 1)
-   - cohortSize = stats.totalRows of the enrichment batch, or the review sample
+   - cohortSize = stats.totalRows of the enrichment batch, or the execution slice
      count
-   - default targetCount=15 matches the default review sample, but pass the
+   - default targetCount=15 matches the default execution slice, but pass the
      explicit batch count anyway so future larger expansion batches do not
      accidentally stop early
      (see §Known Tool Behaviors #3)
@@ -179,7 +179,7 @@ company, enrichCellId, enrichStatus) over the default shape.
 
 ### 5. `wait_for_rubric_results` can timeout with enough signal to decide
 
-Observed: a 15-row review sample may return `ready=false`, `reason="timeout"`,
+Observed: a 15-row internal execution slice may return `ready=false`, `reason="timeout"`,
 and partial stats such as 12/15 scored, 4 passing, 4 messages generated. That is
 enough to diagnose an underperforming sample. Waiting again without active
 processing makes the experience feel frozen.
@@ -211,8 +211,8 @@ Worked examples with defaults (sampleSize=15, importLimit=15):
 | 15           | 15            | Yes                                               |
 
 When non-default importLimit/sampleSize are configured, the math scales
-the same way. In the default review-batch mode, the sample size equals the
-import limit, so the projection is the actual review-batch pass count.
+the same way. In the default internal-slice mode, the slice size equals the
+import limit, so the projection is the actual pass count.
 
 ## Brief-vs-List Diagnosis
 

package/skills/create-campaign-v2/references/step-13-import-leads.md

@@ -55,7 +55,7 @@ Supported branches:
   `import_leads({ campaignOfferId })` for Signal Discovery unless selected posts
   already exist on the campaign. Provider import materializes the source lead
   list from the approved source-capacity plan; it is not the same target as the
-  default 15-row campaign review/process sample.
+  default internal campaign-table execution slice.
 - **Supplied LinkedIn profile CSV** — confirm `load_csv_linkedin_leads` only
   after the user approves that supplied-list source. Batch/materialize the
   uploaded CSV into a Sellable lead-list table. Persist the returned
@@ -74,7 +74,7 @@ Supported branches:
   its `domainFilterId`, run a campaign-associated Prospeo people search with
   `campaignOfferId`, provider prompt preflight, and `domainFilterId`, then
   materialize the source list from that search before copying the confirmed
-  list into the campaign table and processing the first 15 rows.
+  list into the campaign table and processing the first internal execution slice.
 
 ## Campaign-Attached Source Contract
 
@@ -107,14 +107,14 @@ import_leads({
   campaignOfferId,
   targetLeadCount: <sourceCandidateTarget from approved good-fit math>,
   // Signal Discovery only:
-  targetEngagerCount: <ceil(targetGoodFitLeads / sampledFitRateAfterCleanup)>,
+  targetEngagerCount: <ceil(targetHeadlineFitProspects / sampledHeadlinePassRate)>,
   maxPostsToScrape: <postsNeeded from approved math>
 })
 ```
 
 Provider is inherited from the selected source decision (not re-selected here)
 and should already be saved on the campaign before import. For Sales Nav and
-Prospeo, `<sourceCandidateTarget>` is not the 15-row review/process sample. It is
+Prospeo, `<sourceCandidateTarget>` is not the internal campaign-table execution slice. It is
 the source-list export/materialization count from the approved source math. Aim
 for about 1,000 source contacts by default and use the provider cap internally
 when the raw pool is larger. If projected good fits remain below the target,
@@ -124,20 +124,21 @@ escalation logic so dedup ratios are visible.
 
 For Signal Discovery, do not scrape every currently selected/promoted sample
 post by default. Before `import_leads`, reconcile selected posts with the
-approved source math. The default good-fit target is 300 and the planning
-fit-rate assumption is 20%, so the default source-candidate plan is about 1,500
-raw engagers. If the sampled fit rate is stronger or weaker, use the sampled
-rate with a conservative cleanup factor, cap the source candidates at the
-approved provider limit, and select only enough posts to reach that engager
-count. The planning floor is 10% projected fit after cleanup; if Signal
-Discovery falls below that floor during the pre-scrape sample, revise the source
-plan before importing. After an approved scrape starts, do not discard a nonempty
+approved source math. The default headline-fit target is 300 and the planning
+headline-pass assumption is 20%, so the default source-candidate plan is about
+1,500 raw engagers. If the sampled headline-fit rate is stronger or weaker, use
+that sampled rate for `ceil(targetHeadlineFitProspects / sampledHeadlinePassRate)`,
+cap the source candidates at the approved provider limit, and select only
+enough posts to reach that engager count. The planning floor is 10% projected
+headline-fit rate; if Signal Discovery falls below that floor during the
+pre-scrape sample, revise the source plan before importing. After an approved
+scrape starts, do not discard a nonempty
 completed source list just because it lands below the source-candidate target:
-confirm/copy the completed list for the first review sample, then add more posts
-or switch provider if the sample quality or scale is not enough. The subsequent
+confirm/copy the completed list for campaign setup, then add more posts
+or switch provider if the source quality or scale is not enough. The subsequent
 `confirm_lead_list` call uses `reviewBatchLimit: 15`. It copies the confirmed
 source rows into the campaign table and returns only the first 15 rows as the
-review/process sample.
+internal campaign-table execution slice.
 
 Harvest-specific interpretation: Signal Discovery post comments and reactions
 are paged from Harvest at about 100 records per page, with production caps of
@@ -145,12 +146,12 @@ are paged from Harvest at about 100 records per page, with production caps of
 headline-passing candidates after that scrape. Therefore `71 source rows` means
 71 candidates passed headline/list filtering and were inserted; it does not
 mean the post scrape stopped after 71 raw engagers. Treat raw visible engagement,
-raw fetched pages, inserted source rows, and the 15-row review/process sample as
+raw fetched pages, inserted source rows, and the internal campaign-table execution slice as
 separate numbers.
 
 For supplied direct lists, `confirm_lead_list` should receive
 `reviewBatchLimit: 15` so the campaign table can hold the confirmed list while
-the first 15 rows drive the initial approval flow.
+the first 15 rows drive the internal setup flow.
 
 ## `mode=add` Two-Step Handshake
 
@@ -241,7 +242,7 @@ cannot scale further without a new source lane.
 - `import_leads` is allowed immediately after the concrete source-action
   approval. It materializes the source list and then `confirm_lead_list` copies
   the confirmed source rows into the campaign table while returning only the
-  first 15 rows for the initial review/process sample. Enrichment and fit
+  first 15 rows for the internal campaign-table execution slice. Enrichment and fit
   scoring wait for saved rubrics/run conditions; message cells wait for the
   approved message set.
 - Step 13 MUST reuse an approved source already attached with `campaignOfferId`

package/skills/create-campaign-v2/references/step-15-re-cascade.md

@@ -10,7 +10,7 @@ to `awaiting-user-greenlight`, and on every resume into Step 15.
 ## Principle
 
 Generate Message cells are cascade-scoped. If Step 14's rubric flips rows from
-pending → passed AFTER Step 15 first observes messages for the review batch, the
+pending → passed AFTER Step 15 first observes messages for the initial campaign rows, the
 new rows can sit pending with no message. That must not block the first review
 handoff. Step 15 opens review as soon as one passing generated message exists;
 late-passed rows can be re-cascaded after explicit user continuation or resume.
@@ -24,7 +24,7 @@ flat at 257. The new rows never got messages.
 Re-cascade runs whenever ALL of the following are true:
 
 1. The user has already approved the first generated message or explicitly asked
-   to continue processing more review-batch rows.
+   to continue processing more campaign rows.
 2. A subsequent check of rubric state shows rows that were pending at
    first message-generation pass are now passed.
 3. Those newly-passed rows do NOT yet have generated messages

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

@@ -49,13 +49,13 @@ states.
 
 ## Stages
 
-| stage          | UI label      | Next          |
-| -------------- | ------------- | ------------- |
-| `brief-review` | Brief review  | Find Leads    |
-| `find-leads`   | Find Leads    | Review batch  |
-| `review-batch` | Review batch  | Fit + message |
-| `fit-message`  | Fit + message | Review ready  |
-| `review-ready` | Review ready  | Validation    |
+| stage          | UI label       | Next           |
+| -------------- | -------------- | -------------- |
+| `brief-review` | Brief review   | Find Leads     |
+| `find-leads`   | Find Leads     | Campaign setup |
+| `review-batch` | Campaign setup | Fit + message  |
+| `fit-message`  | Fit + message  | Review ready   |
+| `review-ready` | Review ready   | Validation     |
 
 ## Examples
 
@@ -138,7 +138,7 @@ Search iteration:
   "stage": "find-leads",
   "headline": "Tightening the search",
   "visibleState": "The first Signal Discovery search was broad, so Codex is trying a narrower Claude Code founder lane.",
-  "agentIntent": "It is sampling a few engagers before scraping so the first review sample stays on-brief.",
+  "agentIntent": "It is sampling a few engagers before scraping so the source quality stays on-brief.",
   "nextAction": "Review source math"
 }
 ```
@@ -165,9 +165,9 @@ Review/process sample:
 ```json
 {
   "stage": "review-batch",
-  "headline": "Preparing your first sample",
-  "visibleState": "This page shows the confirmed source leads. Codex will process the first 15 for review.",
-  "agentIntent": "Codex is preparing the first campaign sample from those leads.",
+  "headline": "Preparing campaign setup",
+  "visibleState": "This page shows the confirmed source leads. Codex will process the initial campaign rows for setup.",
+  "agentIntent": "Codex is preparing filters and messages from those leads.",
   "nextAction": "Fit + message"
 }
 ```
@@ -179,8 +179,8 @@ Source approved and import starting:
   "stage": "review-batch",
   "headline": "Copying source leads",
   "visibleState": "The browser is still showing the approved LinkedIn Engagement source candidates.",
-  "agentIntent": "Codex is copying the confirmed source into the campaign and will process only the first 15 for review.",
-  "nextAction": "Review sample ready"
+  "agentIntent": "Codex is copying the confirmed source into the campaign and will process only the internal execution slice for setup.",
+  "nextAction": "Campaign setup ready"
 }
 ```
 
@@ -282,8 +282,8 @@ Blocked/recovering:
 ```json
 {
   "stage": "review-batch",
-  "headline": "Fixing the review batch",
-  "visibleState": "The browser is not showing the campaign batch yet.",
+  "headline": "Fixing campaign setup",
+  "visibleState": "The browser is not showing campaign rows yet.",
   "agentIntent": "Codex is reconnecting the campaign state before moving forward.",
   "nextAction": "Fit + message",
   "blockedReason": "Campaign batch is not ready yet."

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

@@ -24,10 +24,12 @@ When the user asks to find posts or start searching, **IMMEDIATELY begin Round 1
 
 <lead_target>
 
-- **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.**
+- **Default create-campaign target: ~300 headline-fit prospects that pass the
+  Signal Discovery headline criteria for now.**
+- **Use sample math first: required raw engagers =
+  `ceil(targetHeadlineFitProspects / sampledHeadlinePassRate)`. When no
+  stronger sample exists, assume ~20% of raw post engagers pass headline
+  filtering, 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
@@ -47,8 +49,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>
 
@@ -112,23 +114,24 @@ You must estimate:
 - `passRate`
   - sampled pass rate used for extrapolation
 - `goodFitPer100Engagers`
-  - normalized fit rate as good-fit prospects per 100 engagers, before and
-    after a conservative dedupe/cleanup factor
+  - normalized headline-pass rate as headline-fit prospects per 100 engagers
 - `avgReachableEngagersPerPost`
   - average reachable engagers per right-content post used for capacity math
 - `goodFitProspectsPerPost`
-  - expected good-fit prospects per right-content post after dedupe/cleanup
+  - expected headline-fit prospects per right-content post
 - `postsNeededForTarget`
   - number of right-content posts needed to reach the target good-fit lead
     count, defaulting to 300 for Signal Discovery unless the campaign says
     otherwise
 - `requiredEngagersToScrape`
-  - `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
+  - `ceil(targetHeadlineFitProspects / sampledHeadlinePassRate)`; for example
+    a 35/60 sample is ~58%, so a 300 headline-fit target needs about 515 raw
+    engagers before adding a practical coverage buffer, not 3,000. The 10%
+    floor is a viability reject threshold, not the denominator when the sample
+    rate is higher.
 - `planningFloor`
-  - minimum acceptable sampled/projected fit rate after conservative cleanup;
-    default 10%. Below this, do not scale Signal Discovery.
+  - minimum acceptable sampled/projected headline-fit rate; default 10%.
+    Below this, do not scale Signal Discovery.
 - `projectedRange`
   - the conservative range implied by the observed sample
 
@@ -152,10 +155,10 @@ 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`: ~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"
+   - preferred: "`sampledCount`: 40, `passCount`: 9, `passRate`: ~22%, `goodFitPer100Engagers`: ~22 headline-fit prospects, `requiredEngagersToScrape`: ~1,365 raw engagers for a 300 headline-fit target before a practical coverage buffer, `avgReachableEngagersPerPost`: 240, `goodFitProspectsPerPost`: ~53, `postsNeededForTarget`: ~6, `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,
+6. If sampled/projected headline-fit rate is below the 10% planning floor,
    reject the Signal Discovery scrape path and recommend Sales Nav recent
    activity as the next source.
 7. Do not manually enumerate dozens of engagers in the final answer. Summarize the sample by `sampledCount`, `passCount`, `passRate`, `projectedRange`, and 3-6 representative examples.
@@ -411,20 +414,21 @@ recommendation, estimate source capacity from real sample math:
   campaign says otherwise)
 - eligible right-content posts by lane/content type
 - reachable engagers from those posts
-- sampled ICP-fit rate as `n/N` plus an easy percentage/range
-- good-fit prospects per 100 engagers before and after conservative cleanup
-- required engagers to scrape for the source target
+- sampled headline-fit rate as `n/N` plus an easy percentage/range
+- headline-fit prospects per 100 engagers
+- required engagers to scrape for the source target using the sampled
+  headline-fit rate
 - average reachable engagers per right-content post
-- expected good-fit leads per selected post after dedupe/cleanup
+- expected headline-fit leads per selected post
 - posts needed to reach the target
-- whether sampled/projected fit clears the 10% planning floor
+- whether sampled/projected headline-fit rate clears the 10% planning floor
 
 Then select the smallest right-content post set that plausibly hits the source
 target. Do not scrape every promoted sample post by default; promoted sampling
 state and final scrape plan are separate. If the math says the warm post lane
 only supports a smaller first batch, say that and name the Sales Nav or Prospeo
 scale fallback rather than padding the selection with noisy posts. If the
-sampled/projected fit rate is below 10% after cleanup, do not call
+sampled/projected headline-fit rate is below 10%, do not call
 `import_leads`; move to Sales Nav recent activity.
 
 ```json
@@ -480,13 +484,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 +545,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

package/skills/research/config.json

@@ -0,0 +1,9 @@
+{
+  "parallelMode": "wide",
+  "agentCount": 6,
+  "maxToolCallsPerAgent": 2,
+  "senderMaxAgents": 2,
+  "senderMaxToolCallsPerAgent": 3,
+  "progressMode": true,
+  "debugMode": true
+}