@sellable/mcp 0.1.149 → 0.1.150

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

@@ -4,15 +4,16 @@ This reference governs Step 15 (`auto-execute-messaging`) re-cascade
 behavior when Step 14's validate-sample loop graduates additional rows
 from pending → passed after the first Generate Message cells have already run.
 
-Load whenever Step 15 is about to transition to
-`awaiting-user-greenlight`, and on every resume into Step 15.
+Load whenever Step 15 is about to ask for generated-message review or transition
+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 new rows can sit pending with no message. Step 15 must explicitly
-queue the newly-pending Generate Message cells for the review-batch subset.
+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
+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.
 
 Observed on manual Phase-85 signal-discovery run (2026-04-20): 15 new
 rows graduated pending → passed mid-tail while `messagesCount` stayed
@@ -22,13 +23,17 @@ flat at 257. The new rows never got messages.
 
 Re-cascade runs whenever ALL of the following are true:
 
-1. Step 15 has already observed the initial review-batch message cascade.
+1. The user has already approved the first generated message or explicitly asked
+   to continue processing more review-batch 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
    (`messagesCount` flat relative to pre-cascade).
 4. Step 15 has NOT yet transitioned to `awaiting-user-greenlight`.
 
+Before that first generated-message approval, do not run this loop just to wait
+for a bigger sample. One passing generated message is enough for review.
+
 If condition 4 already fired (i.e. we're in Step 16), the re-cascade
 runs on resume into Step 15 if validate-sample was re-entered and new
 rows graduated.

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

@@ -194,10 +194,10 @@ After review batch import:
 ```json
 {
   "stage": "fit-message",
-  "headline": "I recommend adding filters",
-  "visibleState": "The first review batch is in the campaign. The visible sample looks mixed enough that filters should be added before message review.",
-  "agentIntent": "Codex is asking whether you want to further filter these leads before message review. Skip filters only if the visible rows already look clean.",
-  "nextAction": "Choose filters or skip",
+  "headline": "Filtering may not be needed",
+  "visibleState": "25 review leads are in the campaign table from 181 source candidates. Sample read: 23/25 look like senior target-role fits; 2 need cleanup or manual review. The browser is showing the filter-choice screen.",
+  "agentIntent": "Codex is not recommending filters because the sample already looks clean. Fit examples: Dave Kranowitz (Chief Revenue Officer); Marie Didominica (Head of Growth Marketing). Add filters only for a narrow exclusion.",
+  "nextAction": "Skip filters or add a narrow cleanup rule",
   "workerStatuses": {
     "leadFitBuilder": "idle",
     "messageDraftBuilder": "running"
@@ -206,11 +206,13 @@ After review batch import:
 ```
 
 Use this after the selected review rows are present and before filters are
-saved. This is add-filters intent, not active filtering. Recommend adding
-filters when the sample is mixed/noisy, tell the user to Choose filters or skip,
-and do not say filtering the batch before rubrics and message approval are
-saved. The Message Draft Builder should start immediately after the bounded
-review batch exists; mark it running only when that branch actually started.
+saved. The filter recommendation must be row-specific: say why filters are
+recommended from the sample counts and examples, or say filtering may not be
+needed when the visible review rows already look clean. This is a user decision
+gate, not active filtering; do not say filtering the batch before rubrics and
+message approval are saved. The Message Draft Builder should start immediately
+after the bounded review batch exists; mark it running only when that branch
+actually started.
 When the user chooses filters, immediately persist `enableICPFilters: true` and
 move to `create-icp-rubric` so the watched app shows Filter Rules while Codex
 defines the rules in chat. After `save_rubrics`, move to `apply-icp-rubric`
@@ -252,16 +254,17 @@ Template approved, bounded filter test running:
   "stage": "fit-message",
   "headline": "Template saved",
   "visibleState": "The browser stays on Filter Leads while the bounded enrichment and filter test runs.",
-  "agentIntent": "Codex saved the approved message template, queued the review-batch Enrich Prospect cells, and is waiting for at least one row to pass before moving to Messages.",
-  "nextAction": "Move to Messages after a passing row"
+  "agentIntent": "Codex saved the approved message template, queued the review-batch Enrich Prospect cells, and is waiting for one passing row with one generated message before moving to review.",
+  "nextAction": "Review the first passing generated message"
 }
 ```
 
 Do not move to Messages immediately after `approve-message`. The visible route
 is already Filter Leads after `save_rubrics`; approving the message only unlocks
 the bounded cascade from that screen. Move to Messages only once at least one
-review-batch row passes and Generate Message cells are ready/running for the
-passing rows.
+review-batch row passes and one generated message is ready for review. Do not
+wait for the rest of the review batch or a stronger sample before asking the
+user to approve the generated message.
 
 Messages waiting for template:
 

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

@@ -58,11 +58,12 @@ Step 14 — kick bounded cascade + observe sample
    passing filtered row exists.)
 
 Step 15 — observe messaging
-  get_rows_minimal                 # confirm passing rows have completed Generate Message cells
+  wait_for_rubric_results({ minPassedCount: 1, minMessagesCount: 1, includeRows: false })
+  get_rows_minimal                 # confirm the first passing generated message exists
   (rare) queue_cells on any pending Generate Message cells
   token-contract spot check via get_rows
   update_campaign(currentStep=auto-execute-messaging) with review-ready narration
-  ask the user to approve generated review-batch messages before Settings
+  ask the user to approve the generated message before Settings
   only after approval: update_campaign(currentStep=awaiting-user-greenlight)
   (generate_messages is NOT an MCP tool; messages come from the cascade)
 
@@ -291,8 +292,10 @@ Do not route to a visible `validate-sample` step. Full decision tree lives in
 review batch only. After `save_rubrics` and the approved message template are
 persisted, Step 14 queues the review-batch Enrich Prospect cells, waits until
 filter results start landing, then moves to message observation as soon as one
-row passes. It does NOT call `check_rubric`, `bulk_enrich_with_prospeo`, or any
-other direct enrichment/scoring tool.
+row passes. Step 15 opens review as soon as one passing generated message
+exists. Do not wait for a larger or stronger sample once that first passing
+message is ready. It does NOT call `check_rubric`,
+`bulk_enrich_with_prospeo`, or any other direct enrichment/scoring tool.
 
 Shape:
 
@@ -307,6 +310,7 @@ projectedPass = round(passInSample / sampleSize * importLimit)
 if wait_for_rubric_results.ready === true and passRate.passed >= 1:
     advance to Step 15 to observe or queue Generate Message for currently passing rows
     do not wait for every sample row to finish before message generation starts
+    stop for review as soon as one passing generated message is ready
 else if wait_for_rubric_results.ready === false and reason === "timeout":
     use the partial passRate/stats as the sample diagnostic
     if passRate.passed >= 1:
@@ -382,17 +386,20 @@ Template`. If it does not, fail before the cascade runs. Do not repair
      already (cascade auto-fired it). If it is still `pending`, queue
      it explicitly: `queue_cells({ tableId, cellIds:
 <generateMessageCellIds> })`.
-3. `wait_for_campaign_table_ready` (or poll) until every passing
-   row's Generate Message cell is `completed`.
-4. Read the results back via `get_rows` (full) and sanity-check a
-   sample against the Phase 84 token contract: no unresolved
+3. `wait_for_rubric_results({ tableId, targetCount: reviewBatchSize,
+minPassedCount: 1, minMessagesCount: 1, includeRows: false })` until the
+   first passing generated message is ready. Do not wait for every passing row's
+   Generate Message cell, and do not add "one more wait" for a stronger sample.
+   Remaining review-batch rows can continue processing in the background.
+4. Read the first ready generated message back via `get_rows` (full) and
+   sanity-check that sample against the Phase 84 token contract: no unresolved
    `{{tokens}}`, no invented proof, one sentence per line, etc.
 5. If the sample fails the token contract, diagnose brief-vs-list
    (same revision loop as Step 14) and escalate if over
    `maxRevisionRounds`.
-6. On success, keep `currentStep: "auto-execute-messaging"` and ask the user
-   to approve the generated review-batch messages. Only that approval may move
-   the campaign to Settings / `awaiting-user-greenlight`.
+6. On success, keep `currentStep: "auto-execute-messaging"` and ask the user to
+   approve the generated message before continuing to Settings. Only that
+   approval may move the campaign to Settings / `awaiting-user-greenlight`.
 
 **Do NOT hand-write message bodies via `update_cell`.** `update_cell`
 is reachable for legitimate operator overrides AFTER the tail hands
@@ -432,15 +439,16 @@ strings, which is why Step 16 requires Step 15 to be complete.
 4. Check `messaging.tokenContract`. When `strict`, reject any sample
    message that contains unresolved or unsupported tokens (including
    any critique rewrite that tried to introduce one).
-5. If the sample passes the token contract (and critique when enabled),
-   stop at the review-batch handoff. Do NOT scale to the full source list
-   before explicit user expansion approval.
+5. If the first passing generated message passes the token contract (and
+   critique when enabled), stop at the review-batch handoff. Do NOT wait for the
+   remaining review-batch rows and do NOT scale to the full source list before
+   explicit user expansion approval.
 6. If the sample fails the token contract or critique, diagnose +
    loop the same way Step 14 does (brief-vs-list), subject to the same
    `maxRevisionRounds` cap.
 7. On success, keep `currentStep: "auto-execute-messaging"`, show that the
-   review-batch messages are ready in Messages, and ask for approval before
-   Settings. Only after the user approves those generated messages should
+   first passing generated message is ready in Messages, and ask for approval
+   before Settings. Only after the user approves the generated message should
    `update_campaign({ campaignId, currentStep: "awaiting-user-greenlight" })`
    run.
 

package/skills/providers/apollo.md

@@ -378,7 +378,14 @@ search_apollo({
 
 ### ABM / Domain List Targeting
 
-For account-based targeting, use `q_organization_domains_list` to search specific companies:
+For campaign routing, supplied company-domain lists should go to Prospeo first
+using `load_csv_domains` or `save_domain_filters`, then `domainFilterId`.
+Apollo still supports `q_organization_domains_list` as a secondary/legacy
+capability when the user explicitly chooses Apollo or needs an Apollo-only
+filter such as a technographic constraint.
+
+If Apollo is explicitly selected for account-based targeting, use
+`q_organization_domains_list` to search specific companies:
 
 ```json
 search_apollo({

package/skills/providers/prospeo.md

@@ -62,7 +62,7 @@ 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 300+ good-fit leads, capped at 2,500 source candidates for now.
+- Default source target is about 150 good-fit leads, capped at 2,500 source candidates for now.
 - 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
@@ -95,6 +95,11 @@ Prospeo filters are split into person vs company. Most filters use `include` / `
 
 Preference rules:
 
+- For hiring-led campaigns, use `company_job_posting_hiring_for` to target the
+  open-role themes and `company_job_posting_quantity` when the campaign needs
+  an active hiring floor. Pair those company hiring filters with buyer/referrer
+  person filters such as founders, GTM leaders, talent leaders, or revenue
+  owners.
 - For ABM lists, use `load_csv_domains` + `domainFilterId` when the accounts are already in a CSV file on disk.
 - For pasted/raw domain lists, use `save_domain_filters` + `domainFilterId` instead of inline domains or `company.websites.include`.
 - If user input starts as company names, resolve names to domains first, then use `save_domain_filters`.
@@ -167,6 +172,11 @@ search_prospeo({
 
 ## When to Use Prospeo
 
+- **Hiring-led targeting**: Find companies hiring for specific roles with
+  `company_job_posting_hiring_for` and `company_job_posting_quantity`, then
+  identify reachable buyer/referrer contacts at those companies
+- **Account/domain targeting**: Use `domainFilterId` from `load_csv_domains` or
+  `save_domain_filters` for ABM searches
 - **Email Finding**: Get verified work emails from LinkedIn URLs
 - **Lead Enrichment**: Add company data, job history, and contact info to leads
 - **Bulk Operations**: Enrich up to 100 leads at once

package/skills/providers/sales-nav.md

@@ -387,7 +387,7 @@ User: "Save it"
 <limits>
 - 25 results per page
 - Maximum 100 pages (2,500 leads)
-- Default source target: 300+ good-fit leads, capped at 2,500 source
+- Default source target: about 150 good-fit leads, capped at 2,500 source
   candidates for now
 - Maximum 5 search calls per session
 - If user needs more than 2,500: explain limit, suggest splitting by region

package/skills/research/config.json

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