@sellable/mcp 0.1.148 → 0.1.150

package/skills/create-campaign/SKILL.md

@@ -143,11 +143,34 @@ why. Do not call `search_signals`, `search_sales_nav`, `search_prospeo`,
 `fetch_post_engagers`, or provider-scoped subagents until the user approves this
 source plan or explicitly chooses a different source.
 
+For hiring-led campaigns, do not default to Sales Nav just because the target is
+a role search. Prospeo is the primary lane when the brief asks for companies
+actively hiring specific roles, open-role signals, account/contact coverage, or
+verified contacts at hiring companies because `search_prospeo` supports
+`company_job_posting_hiring_for` and `company_job_posting_quantity`. Signal
+Discovery can be a parallel or fallback lane when relevant hiring conversations
+are likely. Sales Nav is useful for recent LinkedIn activity, role/title
+precision, and referral paths, but it does not provide hiring-by-role filters;
+say that distinction plainly in the source-plan gate.
+
 After scouting, ask for a second approval on the concrete source action. For
 Signal Discovery, name how many selected posts will be scraped, the target
 engager/source-candidate volume, and the bounded review-batch size. For Sales
-Nav or Prospeo, name the specific approved import lane. Do not call
-`import_leads` or `confirm_lead_list` until this second approval is granted.
+Nav or Prospeo, name the specific approved import lane and source lead count.
+Do not call `import_leads` or `confirm_lead_list` until this second approval is
+granted.
+
+For Sales Nav and Prospeo, the second gate approves materializing the source
+lead list, not importing only the review batch. Use the first-page/sample review
+to calculate projected good fits: sampled fit rate after conservative cleanup,
+raw pool size, source target, and expected good-fit count. If the projected
+good-fit pool is below the campaign target (normally about 150+ usable
+prospects unless source defaults say otherwise), keep refining/broadening
+filters before asking for import approval. Once it clears target, approve
+`import_leads` with the source-list `targetLeadCount` (up to the raw count or
+provider max). Only after the source list is ready should `confirm_lead_list`
+clone the bounded review batch into the campaign table.
+
 For Signal Discovery, the customer-facing approval card must use the exact
 action shape "Approve scraping N Signal Discovery posts?" and the chat summary
 should be a compact `## Source Recommendation` block with:
@@ -158,12 +181,13 @@ should be a compact `## Source Recommendation` block with:
 - planning floor: continue with Signal Discovery only when sampled/projected
   fit is at least 10% after cleanup; below that, move to Sales Nav recent
   activity instead of scraping noisy engagers
-- review checkpoint: import the first 25 leads for fit and message review
+- review checkpoint: after the source list exists, clone only the bounded
+  review batch into the campaign for fit and message review
 - a selected-post table with post author/topic, why it fits, and visible
   engagement
 - total visible pool and estimated good-fit pool
-- first pass: build the source list, then import only the review
-  batch
+- first pass: build the source list at the approved source-candidate target,
+  then clone only the bounded review batch into the campaign
 - fallback: switch to Sales Nav recent activity if sampled/projected fit falls
   below 10%, or if the review batch is vendor-heavy, agency-heavy, or off-ICP
 
@@ -171,7 +195,8 @@ When the user has not supplied a source and multiple source angles are viable,
 scout those angles as independent branches when the host can actually do it:
 LinkedIn Engagement / active post engagers (internal `signal-discovery`
 provider prompt), Sales Nav / title + company filters, and Prospeo Contact /
-domains only when relevant. In Codex, explicitly spawn the named custom scouts
+domains, hiring filters, or broad verified-contact expansion when relevant. In
+Codex, explicitly spawn the named custom scouts
 `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
 `source-scout-prospeo-contact` for the credible lanes only when the current host
 exposes those names; Codex does not infer subagent fan-out from generic source
@@ -193,16 +218,16 @@ that we are pulling sample engagers from these posts to confirm the ICP is
 actually engaging and the source is viable.
 
 After the bounded review batch exists, use the same registry pattern for
-post-lead work. The create-campaign-v2 subskill calls
-`get_post_find_leads_scout_registry`, then launches the returned
-message-generation scout immediately when real subagents are available and the
-current session exposes the returned name. If the user chooses filters, launch
-the filter-leads scout then and join it with the already-running or completed
-message draft before message review. Workflow cell execution still waits for
-filter and template approval. AI Generated is an explicit opt-out that cancels
-or ignores the background template draft. If the post-lead agents are absent,
-the main thread still orchestrates the same branches from the compact context
-with MCP tools/assets.
+post-lead work, but do not load that registry or any deep filter/message prompt
+before the filter-choice question. After `confirm_lead_list`, ask add filters
+vs skip filters immediately. Once the user answers, launch the message scout
+from the same campaign/table basis. If the user chooses filters, also launch the
+filter-leads scout, move to Filter Rules, save rubrics, then keep the browser on
+Filter Leads while the message recommendation is reviewed. If the user skips
+filters, move to Messages/message review. Workflow cell execution still waits
+for filter and template approval. AI Generated is an explicit opt-out from the
+template path. If the post-lead agents are absent, the main thread still
+orchestrates the same branches from the compact context with MCP tools/assets.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
@@ -631,13 +656,16 @@ updates.
    call `mcp__sellable__update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
    so the watched app moves to Filter Rules while rubrics are drafted/saved.
    After rubrics save, move the watched app to `apply-icp-rubric` / Filter
-   Leads and say the fit rules are saved; approve the message template next
-   while the browser stays on Filter Leads. After approval, save the template
-   to the campaign brief, then queue the bounded review-batch `enrichCellId`
-   cells to kick off enrichment/filtering. Move to Messages only after at
-   least one review row passes and Generate Message cells are running or ready.
-   Product Generate Message cells must not run from the background template
-   path before that template/token approval.
+   Leads and say the fit rules are saved; the background message scout is
+   preparing the message recommendation and approval comes next while the
+   browser stays on Filter Leads. If filters are skipped, move the watched app to
+   Messages/message review and wait for message approval there. After approval,
+   save the template to the campaign brief, then queue the bounded review-batch
+   `enrichCellId` cells to kick off enrichment/filtering. Move to Messages only
+   after at least one review row passes and Generate Message cells are running or
+   ready.
+   Product Generate Message cells must not run before that template/token
+   approval.
    Do not ask the user to approve the brief before shell creation unless they
    explicitly requested a no-write draft; the shell itself is the review surface.
 6. The main thread owns watch navigation. Call

package/skills/create-campaign/core/providers/apollo.json

@@ -21,10 +21,12 @@
     "priority": 3,
     "useWhen": [
       "You need technology stack targeting",
-      "You need bulk domain list targeting",
       "You need high volume and can accept lower reply rates"
     ],
-    "avoidWhen": ["High reply rate and LinkedIn activity are the top priority"],
+    "avoidWhen": [
+      "The user supplied a company-domain list; use Prospeo domainFilterId first",
+      "High reply rate and LinkedIn activity are the top priority"
+    ],
     "reason": "Best for scale and firmographic/technographic filters, but lower LinkedIn activity by default.",
     "prose": "Since you need to find **{icp}**, I'd recommend **Apollo**.\n\nHere's why:\n- Apollo has technology filters that other sources don't\n- We can find people at companies using {techStack}\n- Heads up: reply rates will be lower since not all leads are active on LinkedIn\n\nShould I search Apollo for {techStack} users?"
   },

package/skills/create-campaign/core/providers/prospeo.json

@@ -21,11 +21,12 @@
     "priority": 2,
     "useWhen": [
       "You want Prospeo filters or domain-based search",
+      "You need companies hiring for specific roles using job-posting filters",
       "You need high deliverability from Prospeo"
     ],
     "avoidWhen": ["You need LinkedIn activity filters"],
-    "reason": "Strong for Prospeo-specific filters and domain lists.",
-    "prose": "Since you're targeting **{icp}**, I'd recommend **Prospeo**.\n\nHere's why:\n- Prospeo has strong domain-based search and deliverability\n- We can find verified contacts at your target companies\n- Good for high-deliverability outreach\n\nShould I search Prospeo for {icp}?"
+    "reason": "Strong for hiring-led search, Prospeo-specific filters, verified contacts, and domain lists.",
+    "prose": "Since you're targeting **{icp}**, I'd recommend **Prospeo**.\n\nHere's why:\n- Prospeo can filter for companies hiring specific roles with job-posting filters\n- We can pair those company hiring signals with buyer/referrer titles\n- Good for verified-contact coverage when Sales Nav cannot filter by hiring role\n\nShould I search Prospeo for {icp}?"
   },
   "askOption": {
     "label": "Prospeo",

package/skills/create-campaign/references/provider-selection-strategy.md

@@ -53,7 +53,29 @@ Activity Filters (use one or both):
 
 Sales Nav works without these filters too -- just expect lower reply rates.
 
-### 3. Apollo (LAST RESORT FOR VOLUME)
+### 3. Prospeo (HIRING / ACCOUNT / VERIFIED-CONTACT EXPANSION)
+
+Prospeo is the main lane when the user's direction points to database filters
+that LinkedIn sources do not expose.
+
+USE WHEN:
+
+- Hiring-led targeting: companies actively hiring specific roles
+- Named-account or domain-list targeting
+- Broad persona expansion where verified contact coverage matters
+- You need `company_job_posting_hiring_for`,
+  `company_job_posting_quantity`, funding, headcount, or domain filters
+
+SKIP WHEN:
+
+- The campaign is mainly about fresh LinkedIn activity or engagement warmth
+- Signal Discovery can clearly produce enough ICP-fit engagers
+
+WHY: Prospeo is the only current provider with company job-posting filters by
+role. Sales Nav is stronger for recent LinkedIn activity, but not for
+hiring-by-role filtering.
+
+### 4. Apollo (LAST RESORT FOR VOLUME)
 
 Large database but leads may not be active on LinkedIn.
 
@@ -74,25 +96,30 @@ Is your ICP LinkedIn-active (founders, sales, marketing, GTM, engineers)?
     NO  -> Sales Navigator + POSTED_ON_LINKEDIN (4x reply rates)
   NO  -> Sales Navigator (with or without POSTED_ON_LINKEDIN)
 
+Need hiring-by-role filters? -> Prospeo (has company job-posting filters)
 Need tech stack targeting? -> Apollo (has technology filters)
-Have specific company names? -> Sales Navigator or Apollo with domains
+Have specific company names/domains? -> Sales Navigator for small lists or Prospeo with domainFilterId
 ```
 
 ## ICP-to-Provider Quick Reference
 
-| ICP Type                  | Recommended      | Why                                                  |
-| ------------------------- | ---------------- | ---------------------------------------------------- |
-| Founders, CEOs            | Signal Discovery | Highly active on LinkedIn, lots of founder content   |
-| Sales/GTM leaders         | Signal Discovery | Very active, tons of sales content                   |
-| Marketing leaders         | Signal Discovery | Active, lots of marketing content                    |
-| Engineers/DevOps          | Signal Discovery | Active on tech discussions, open source              |
-| Enterprise CTOs           | Sales Navigator  | Less public engagement, use POSTED_ON_LINKEDIN       |
-| Procurement/Ops           | Sales Navigator  | Rarely engage publicly                               |
-| Few specific companies    | Sales Navigator  | Use CURRENT_COMPANY filter (lookup each company)     |
-| Company domain list (ABM) | Apollo           | Has `q_organization_domains_list` for bulk targeting |
-| Tech stack users          | Apollo           | Has technology filters                               |
-
-**Default:** Try Signal Discovery first. Fall back to Sales Navigator if ICP is too niche.
+| ICP Type                  | Recommended      | Why                                                |
+| ------------------------- | ---------------- | -------------------------------------------------- |
+| Founders, CEOs            | Signal Discovery | Highly active on LinkedIn, lots of founder content |
+| Sales/GTM leaders         | Signal Discovery | Very active, tons of sales content                 |
+| Marketing leaders         | Signal Discovery | Active, lots of marketing content                  |
+| Engineers/DevOps          | Signal Discovery | Active on tech discussions, open source            |
+| Enterprise CTOs           | Sales Navigator  | Less public engagement, use POSTED_ON_LINKEDIN     |
+| Procurement/Ops           | Sales Navigator  | Rarely engage publicly                             |
+| Few specific companies    | Sales Navigator  | Use CURRENT_COMPANY filter (lookup each company)   |
+| Hiring-led targeting      | Prospeo          | Has company job-posting filters by role            |
+| Company domain list (ABM) | Prospeo          | Uses `domainFilterId` for domain targeting         |
+| Tech stack users          | Apollo           | Has technology filters                             |
+
+**Default:** Try Signal Discovery first only when there is no stronger source
+direction and the ICP is plausibly active in public LinkedIn conversations. Fall
+back to Sales Navigator if ICP is too niche. Use Prospeo first when the ask is
+hiring-led, account/domain-led, or broad verified-contact expansion.
 
 ## ABM / Account-Based Targeting
 
@@ -103,10 +130,10 @@ When user has a list of target companies:
   - Requires looking up each company individually
   - Can combine with POSTED_ON_LINKEDIN for active users
 
-- **Many companies (domain list):** Use Apollo with `q_organization_domains_list`
-  - Supports bulk domain upload (up to 190 per search)
-  - Example: `filters: { q_organization_domains_list: ["stripe.com", "notion.so", "figma.com"] }`
-  - Trade-off: No POSTED_ON_LINKEDIN equivalent, so reply rates may be lower
+- **Many companies (domain list):** Use Prospeo with `domainFilterId`
+  - Supports large domain filters through `load_csv_domains` or `save_domain_filters`
+  - Example: create a domain filter for `stripe.com`, `notion.so`, and `figma.com`, then pass `domainFilterId` into `search_prospeo`
+  - Trade-off: No POSTED_ON_LINKEDIN equivalent, so LinkedIn activity warmth may be lower
 
 ## Recommendation Templates
 
@@ -141,6 +168,19 @@ Here's why:
 Should I search for active {icp} on Sales Navigator?
 ```
 
+**Prospeo (hiring-led ICP):**
+
+```
+Since this campaign depends on companies actively hiring for **{roleThemes}**, I'd recommend **Prospeo** first.
+
+Here's why:
+- Prospeo can filter companies by open-role themes using job-posting filters
+- We can pair those hiring signals with founder, GTM, recruiting, or revenue-owner contacts
+- Sales Nav is useful for LinkedIn activity and referrals, but it cannot filter companies by hiring role
+
+Should I search Prospeo for companies hiring {roleThemes} and the right hiring-owner contacts?
+```
+
 **Apollo (tech stack targeting):**
 
 ```
@@ -154,17 +194,17 @@ Here's why:
 Should I search Apollo for {techStack} users?
 ```
 
-**Apollo ABM (company domains):**
+**Prospeo ABM (company domains):**
 
 ```
-Since you have a **list of target companies**, I'd recommend **Apollo** with domain targeting.
+Since you have a **list of target company domains**, I'd recommend **Prospeo** with a domain filter.
 
 Here's why:
-- Apollo supports bulk domain lists (up to 190 companies per search)
+- Prospeo is the campaign-default path for supplied company-domain lists
+- We'll create a `domainFilterId` from the CSV or pasted domains before searching
 - We can find decision-makers at your exact target accounts
-- Just share the domains (e.g., stripe.com, notion.so) and I'll find your ICP at those companies
 
-Note: Reply rates may be lower than Signal Discovery or Sales Nav with POSTED_ON_LINKEDIN, since we can't filter for LinkedIn activity. Consider combining with a strong personalized message.
+Note: LinkedIn activity warmth may be lower than Signal Discovery or Sales Nav with POSTED_ON_LINKEDIN, so we should inspect the first review batch before scaling.
 
 Can you share your target company domains?
 ```
@@ -179,7 +219,8 @@ Do not hardcode provider options. Build them from the framework:
    - If user already has some other list shape that does not fit those CSV paths -> proceed with provider selection
    - If the user specifies a provider or research plan -> treat that as a hard override
    - Else if `providerPreference` override exists -> recommend that provider
-   - Else use the decision hierarchy above (Signal Discovery -> Sales Nav -> Apollo)
+   - Else use the decision hierarchy above only when there is no stronger source
+     direction (Signal Discovery -> Sales Nav -> Prospeo -> Apollo)
 2. Build options from `providerOrder` and `framework.providers[providerId].askOption`
 3. Mark the recommended option by appending " (Recommended)" if needed
 

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

@@ -126,6 +126,16 @@ Default source order when the user has not supplied a source:
 3. broader Sales Nav role/title filters
 4. Prospeo account/contact expansion
 
+Use that order only when the brief has no stronger sourcing constraint. If the
+campaign is hiring-led, asks for companies actively hiring specific roles, asks
+for open-role/job-posting signals, or needs verified contacts at companies with
+those hiring signals, start with Prospeo. Prospeo supports
+`company_job_posting_hiring_for` and `company_job_posting_quantity`; Sales Nav
+does not provide hiring-by-role filters. For those campaigns, Signal Discovery
+can be a conversation-signal check if relevant hiring posts are likely, and
+Sales Nav is a LinkedIn activity/referral fallback rather than the main hiring
+filter.
+
 Before any provider prompt, search, source scout, or signal-discovery call,
 show a short source-plan gate and ask for approval. This first approval
 authorizes source scouting/search only. The gate must say, in plain language:
@@ -162,14 +172,30 @@ the target engager/source-candidate volume, the bounded campaign review-batch
 size, the cleanup risk, and the fallback if the selected posts look wrong. The
 approval label must describe the action with the count, such as "Approve
 scraping 3 Signal Discovery posts?" For Sales Nav or Prospeo, the label should
-name the specific search/import lane. Do not call `import_leads` or
-`confirm_lead_list` until this second source-action approval is granted.
+name the specific search/import lane and source lead count. Do not call
+`import_leads` or `confirm_lead_list` until this second source-action approval
+is granted.
+
+For Sales Nav and Prospeo, do not ask to import only the 25-row review batch at
+the source-action gate. First-page samples are for source math: compute sampled
+fit after conservative cleanup, project how many good-fit prospects the raw
+pool can yield, and keep refining filters while the projected good-fit pool is
+below the campaign target (normally about 150+ usable prospects unless the
+campaign/source defaults say otherwise). Once the lane clears the target, ask
+approval to materialize the source list with
+`targetLeadCount = min(rawResultCount, providerMax, ceil(targetGoodFitLeads /
+projectedFitRateAfterCleanup))`. After that source list is ready,
+`confirm_lead_list` imports only the bounded review batch into the campaign
+table for fit and message review.
+
 After the user approves this concrete source-action gate, do not show the
 Source Recommendation again and do not ask another source approval question.
 Acknowledge once, then call `import_leads` immediately with the approved source
-math. For Signal Discovery, pass `provider: "signal-discovery"`,
-`targetEngagerCount`, `maxPostsToScrape`, and `confirmed: true`; the tool owns
-moving the watch UI to source-list progress after a lead-list/job id exists.
+math. For Sales Nav/Prospeo, pass `targetLeadCount` as the approved source-list
+export count, not the review-batch size. For Signal Discovery, pass
+`provider: "signal-discovery"`, `targetEngagerCount`, `maxPostsToScrape`, and
+`confirmed: true`; the tool owns moving the watch UI to source-list progress
+after a lead-list/job id exists.
 
 For Signal Discovery, use this compact source-action approval shape after
 selected posts exist:
@@ -182,7 +208,7 @@ Use Signal Discovery first.
 **Good-fit target:** ~150 prospects after cleanup, enrichment, and filters<br>
 **Source-candidate plan:** scrape ~1,000 raw engagers using a conservative 15% fit-rate assumption<br>
 **Planning floor:** continue only when sampled/projected fit is at least 10% after cleanup; below that, switch to Sales Nav recent activity<br>
-**Review checkpoint:** import the first 25 leads into the campaign for fit and message review before scaling<br>
+**Review checkpoint:** after the source list exists, clone only the bounded review batch into the campaign for fit and message review<br>
 
 ### Selected posts
 
@@ -203,8 +229,9 @@ This gives enough volume to work toward ~150 good-fit prospects, while
 keeping the source tied to people already engaging with Claude Code outbound /
 AI-native sales workflows.
 
-**First pass:** build the source list, then import only the 25-lead review
-batch so we can inspect fit and messages before scaling.
+**First pass:** build the source list at the approved source-candidate target,
+then clone only the bounded review batch into the campaign so we can inspect
+fit and messages before sending.
 
 **Fallback:** if sampled/projected fit falls below 10%, or if the review batch
 is too vendor-heavy, agency-heavy, or off-ICP, switch to Sales Nav recent
@@ -214,7 +241,11 @@ activity.
 A source recommendation must show concrete evidence: source lane, filters or
 recipe, raw volume, sample size, sampled fits as n/N plus percentage/range,
 estimated usable prospects, cleanup risk, runner-up, and what approval
-authorizes.
+authorizes. For Sales Nav/Prospeo it must also show source export math:
+`rawResultCount`, `sampledFitRate`, conservative projected fit rate,
+`targetLeadCount` for the source list, and projected good-fit count from that
+export. If projected good-fit count is below target, the recommendation is to
+refine or broaden filters, not to import a 25-row batch.
 
 Supplied profile CSVs, company/domain CSVs, pasted domains, and existing
 Sellable lead lists are supported, but keep provider mechanics out of the first
@@ -223,24 +254,28 @@ customer-facing source-choice labels.
 ## Post-Lead Workstreams
 
 After `confirm_lead_list` imports a non-empty bounded review batch and
-`get_rows_minimal({ tableId: workflowTableId })` proves rows exist, call
-`get_post_find_leads_scout_registry` and start the Message Draft Builder branch
-immediately when the current host exposes that returned agent. Do this before
-asking the filter-choice question. If no real background branch can start, say
-the real sequence and do not claim background drafting is running.
-
-The message branch uses live CampaignOffer/source/table state as the source of
-truth and may draft while the user is choosing filters. It does not write
-message cells, enrich rows, attach sequences, or unlock Settings. The Lead Fit
-Builder branch starts only after the user chooses filters. Debug markdown/json
-artifacts are optional only.
+`get_rows_minimal({ tableId: workflowTableId })` proves rows exist, ask the
+filter-choice question immediately. Do not call
+`get_post_find_leads_scout_registry`, load filter/message subskill prompts, or
+spawn post-lead workers before that question. The only customer-facing work
+before the question should be a short review-batch summary and the choice:
+add filters, skip filters, or revise source.
+
+If the user chooses filters, then load the post-lead registry/reference needed
+for filtering and start the Lead Fit Builder. Also start the Message Draft
+Builder in the background from the same campaign/table basis as soon as the
+filter-choice answer is known. If the user skips filters, move the watched app to
+Messages and run the Message Draft Builder there. Debug markdown/json artifacts
+are optional only.
 
 When the user chooses filters, immediately call
 `update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
 before rubric thinking or branch work. The watched app should move to Filter
 Rules quickly. After `save_rubrics`, the watched app should move to
 `apply-icp-rubric` / Filter Leads so the user can see the saved filters are
-ready before message approval unlocks any enrichment or filtering.
+ready and wait there for the background message agent. Tell the user explicitly
+that a message agent is drafting the first-message template while enrichment,
+filtering, and Generate Message cells remain blocked.
 
 Lead Fit Builder persists production rubrics with `save_rubrics` when filters
 are enabled. It must not require `brief.md`, `lead-review.md`, or

package/skills/create-campaign-v2/SOUL.md

@@ -274,14 +274,18 @@ keep the output numeric but do not claim the source scout was parallel or
 surface install status to the customer.
 
 For post-lead work, call `get_post_find_leads_scout_registry` after
+the user chooses filters, not before the filter-choice question. After
 `confirm_lead_list` imports a non-empty bounded review batch and
-`get_rows_minimal` proves rows exist. Start `post-find-leads-message-scout`
-immediately when real subagents are available, before asking the filter-choice
-question. Start `post-find-leads-filter-scout` only after the user chooses
-filters. This is the same registry pattern as source scouting, but the trigger
-for message drafting is review-batch import, not filter approval. The join gate
-is live branch readiness: saved rubrics or a resolved skip-filter choice, plus a
-message recommendation grounded in the same campaign/table basis.
+`get_rows_minimal` proves rows exist, ask add-filters vs skip-filters
+immediately. Once the user answers, start `post-find-leads-message-scout` /
+message generation from the same campaign/table basis. If the user chooses
+filters, also start `post-find-leads-filter-scout`, move the browser to Filter
+Rules, save rubrics, then keep the browser on Filter Leads while the message
+recommendation is reviewed. If the user skips filters, move the browser to
+Messages/message review. The join gate is live branch readiness: saved rubrics
+or a resolved skip-filter choice, plus a message recommendation grounded in the
+same campaign/table basis. Enrichment, filtering, and product Generate Message
+cells still wait for template approval.
 
 Only promise parallel post-lead work when parallel work actually started. If the
 host cannot or should not launch background branches, say the real sequence: