@sellable/mcp 0.1.149 → 0.1.151

package/skills/create-campaign-v2/references/approval-gate-framing.md

@@ -33,14 +33,13 @@ Before showing the commit gate, the draft directory must contain all of:
 - `message-validation.md`
 - `approval-packet.md`
 
-The current run must also have retrieved message-generation rules before
-`message-validation.md`, `approval-packet.md`, or the commit gate is written. In
-`create-campaign-v2`, use the compact
-`references/message-review-safety-gate.md` asset or the embedded
-`post-find-leads-message-scout` prompt. Do not load the full long-form
-`generate-messages` subskill for the hosted campaign launch path. If the message
-template was written directly from memory or planning artifacts, do not show the
-commit gate; route back to message generation.
+The current run must also have retrieved the full message-generation rules
+before `message-validation.md`, `approval-packet.md`, or the commit gate is
+written. In `create-campaign-v2`, use the embedded
+`post-find-leads-message-scout` prompt or load the full long-form
+`generate-messages` subskill. If the message template was written directly from
+memory, checklist instructions, or planning artifacts, do not show the commit
+gate; route back to message generation.
 
 `rubric.json` is optional but strongly preferred — when missing, derive it from
 `lead-filter.md` in the atomic mint step.

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

@@ -60,9 +60,10 @@ auto-revise leads.
      explicit batch count anyway so future larger expansion batches do not
      accidentally stop early
      (see §Known Tool Behaviors #3)
-   - minPassedCount=1 means one passing filtered row unblocks Step 15
-     Generate Message observation. Do not wait for all sample rows to finish
-     before messages start.
+   - minPassedCount=1 means one passing filtered row unblocks Step 15 Generate
+     Message observation. Step 15 then waits only for one generated message
+     (`minMessagesCount=1`) before review. Do not wait for all sample rows to
+     finish before messages start.
 
 7. call `wait_for_rubric_results` with `includeRows=false`; extract ONLY:
    - ready: boolean
@@ -101,7 +102,9 @@ auto-revise leads.
 10. branch:
    if passInSample >= 1:
        proceed to Step 15 (auto-execute-messaging) with currently passing rows
-       so Generate Message can start without waiting for the full sample
+       so Generate Message can start without waiting for the full sample. Once
+       one passing generated message is ready, stop for user review instead of
+       waiting for a stronger sample.
    else:
        diagnose (see Brief-vs-List Diagnosis below)
        revisionRound += 1
@@ -179,7 +182,8 @@ processing makes the experience feel frozen.
 
 Workaround: treat timeout stats as a partial sample. If at least one row has
 passed, move to Step 15 and observe or queue Generate Message for the passing
-rows. If zero rows have passed and no active processing is visible, stop at
+rows; Step 15 stops when one generated message is ready. If zero rows have
+passed and no active processing is visible, stop at
 `Status: sample-needs-revision` before Settings. Show the completed / passed /
 pending counts and ask whether to revise source, revise filter/rubric, or wait
 once only if active processing is still visible.

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

@@ -106,7 +106,7 @@ fills the source lead list; it does **not** clone rows into the campaign table:
 ```text
 import_leads({
   campaignOfferId,
-  targetLeadCount: <sourceCandidateTarget; provider default>,
+  targetLeadCount: <sourceCandidateTarget from approved good-fit math>,
   // Signal Discovery only:
   targetEngagerCount: <ceil(targetGoodFitLeads / sampledFitRateAfterCleanup)>,
   maxPostsToScrape: <postsNeeded from approved math>
@@ -114,9 +114,15 @@ import_leads({
 ```
 
 Provider is inherited from the selected source decision (not re-selected here)
-and should already be saved on the campaign before import. Response returns
-`{ imported, skipped, duplicates }` — surface all three to the escalation logic
-so dedup ratios are visible.
+and should already be saved on the campaign before import. For Sales Nav and
+Prospeo, `<sourceCandidateTarget>` is not the 25-row review batch. It is the
+source-list export/materialization count from the approved source math:
+`min(rawResultCount, providerMax, ceil(targetGoodFitLeads /
+projectedFitRateAfterCleanup))`. If projected good fits remain below the target
+(often about 150+ usable prospects unless the campaign/source defaults specify
+otherwise), return to find-leads and refine filters before import. Response
+returns `{ imported, skipped, duplicates }` — surface all three to the
+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

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
+}

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.