@sellable/mcp 0.1.143 → 0.1.145

package/skills/create-campaign/SKILL.md

@@ -86,7 +86,7 @@ or tool discovery. Start in product language:
 ```text
 I’ll help you launch this as a Sellable campaign. First I’ll resolve the
 client/company this campaign is for, then I’ll turn that into a campaign brief
-before any leads are imported or anything can send.
+before we move into lead sourcing.
 ```
 
 If a linked/local skill file is stale or missing, silently use the installed
@@ -102,8 +102,14 @@ clear business decisions, tradeoffs, and approval gates. Use product language:
 - "a couple setup choices", not `request_user_input`
 - "campaign brief", not prompt artifact
 - "lead source", not provider internals unless comparing source options
-- "I can create a draft shell for you to watch, but no leads import and nothing
-  sends until you approve", not mutation jargon
+- "I can create a draft shell for you to watch with approval gates before
+  sourcing", not mutation jargon
+
+Approval and safety copy should be tasteful. State what the current approval
+covers once, in one short sentence, then move on. Do not append repeated
+"nothing starts / no leads import / no sending" disclaimers to routine progress
+updates. Use positive gate language like "Next gate: selected-post scrape" or
+"Approval covers scouting/search only" instead of long negative lists.
 
 When explaining lead-source decisions, show the concrete counts behind the
 logic: lanes searched, timeframe, raw result counts, finalist posts or preview
@@ -127,7 +133,7 @@ authorizes scouting/search only. The gate should say:
 - why that lane fits the buyer, offer, and likely public activity
 - what will be tested next
 - the fallback lane if relevant posts or ICP engagement look thin
-- that approval authorizes scouting/search only, not lead import or sending
+- what approval covers in one concise line
 
 Do not surface blanket source heuristics as product copy. Make the
 recommendation specific to the campaign. If Signal Discovery is recommended,
@@ -142,6 +148,21 @@ 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.
+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:
+
+- good-fit target: about 150 prospects after cleanup, enrichment, and filters
+- source-candidate plan: about 1,000 raw engagers using a conservative 15%
+  fit-rate assumption unless sampled data supports a different number
+- review checkpoint: import the first 25 leads 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
+- fallback: switch to Sales Nav recent activity if the review batch is
+  vendor-heavy, agency-heavy, or off-ICP
 
 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:
@@ -168,19 +189,17 @@ which posts are being sampled in the watched app. The watch guide should say
 that we are pulling sample engagers from these posts to confirm the ICP is
 actually engaging and the source is viable.
 
-After find-leads returns a lead source and the user approves it, use the same
-registry pattern for the two post-lead branches. The create-campaign-v2 subskill
-calls `get_post_find_leads_scout_registry`, then launches the returned
-filter-leads scout and message-generation scout together when real subagents are
-available and the current session exposes the returned names. Message
-generation is the provisional Message Draft Builder: it may start after the
-review batch exists, including while the user is on filter choice, but workflow
-cell execution must wait. After rubrics are saved, do not queue enrichment,
-filtering, or Generate Message cells until the user approves the message
-template. 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.
+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.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
@@ -233,7 +252,7 @@ After every `update_campaign({ campaignId, currentStep })`, use
 `get_campaign_navigation_state` when available as a compact orientation check:
 match the saved campaign state to the expected watch-link step, explain the
 current state in one sentence, and only then continue. Sender selection belongs
-at Settings after message approval and 15-row validation. After message
+at Settings after message approval and review-batch validation. After message
 validation, use Settings to help the user connect or select a LinkedIn sender.
 Explain Slack reply review before launch. After sender selection, attach the
 recommended sequence and move the watched UI to Send. Do not start the campaign
@@ -412,7 +431,7 @@ First I’ll resolve the client/company this campaign is for. I’ll use that
 context to choose the target, offer, proof, and lead source.
 
 Then I’ll turn that into a campaign brief for you to approve before any leads
-are imported or anything can send.
+are sourced.
 ```
 
 Do not silently ask Codex intake or approval questions as plain chat when
@@ -596,9 +615,9 @@ updates.
    until `hasMore=false`. The create-campaign message-review safety gate is a
    supplemental approval checklist, not a replacement for the long prompt. Use
    campaign state, campaign brief content, selected source state, and imported
-   review-batch rows as the source of truth; do not read stale local markdown,
-   inspect the database directly, or synthesize local validation artifacts from
-   general knowledge.
+   review-batch rows as the source of truth; do not read stale local markdown
+   such as `message-validation.md`, inspect the database directly, or synthesize
+   local validation artifacts from general knowledge.
 5. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Import only the first
    bounded review batch after the source is attached to the campaign; do not
@@ -609,9 +628,11 @@ 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;
-   after approval, queue the bounded review-batch
-   `enrichCellId` cells to kick off enrichment/filtering.
+   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.
    Do not ask the user to approve the brief before shell creation unless they
@@ -620,15 +641,15 @@ updates.
    `mcp__sellable__update_campaign({ campaignId, currentStep })` before major
    visible work so the user can watch progress in the app: `create-offer` for
    the brief, `pick-provider` or the selected provider step while sourcing,
-   `filter-choice` after the 15-row review batch, `create-icp-rubric` as soon
-   as filters are approved, `apply-icp-rubric` after rubrics save, `messages`
-   for the Use Template / AI Generated mode
-   choice, `auto-execute-messaging` for approved
-   message work or the product's AI-generated path, `awaiting-user-greenlight`
-   for the final handoff, `settings` for sender selection, `sequence` after
-   sender attach, and `send` once the recommended sequence is attached.
-   `validate-sample` is recovery/legacy only if reached. Do not advance the
-   step backward.
+   `filter-choice` after the review batch, `create-icp-rubric` as soon
+   as filters are approved, `apply-icp-rubric` after rubrics save and while
+   waiting for message-template approval, `validate-sample` while the approved
+   template unlocks bounded enrichment/filter scoring on Filter Leads,
+   `auto-execute-messaging` after at least one row passes and review-batch
+   messages are being generated or reviewed, `awaiting-user-greenlight` only
+   after generated review-batch messages are approved, `settings` for sender
+   selection, `sequence` after sender attach, and `send` once the recommended
+   sequence is attached. Do not advance the step backward.
 7. Keep `selectedLeadListId` as the source list and `workflowTableId` as the
    campaign table. Do not use disk files as the post-mint source of truth.
 8. Do not ask the user to run another command.

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

@@ -47,8 +47,11 @@ for debug output.
     rows.
 11. Review and approve/revise the message.
 12. Sync the approved template into the campaign brief.
-13. Validate the bounded review batch, then move to Settings, sender, sequence,
-    and explicit launch greenlight.
+13. After message approval, keep the watched app on Filter Leads while the
+    bounded enrichment/filter cascade starts.
+14. Move to Messages only after at least one review row passes, generate and
+    review bounded messages, then hand off to Settings, sender, sequence, and
+    explicit launch greenlight.
 
 There is no normal approval-packet, commit-gate, atomic-mint, or local
 artifact-validation step. Those belong only to legacy validation/rehearsal
@@ -151,10 +154,48 @@ After scouting, show a second approval gate for the concrete source action. For
 Signal Discovery, this gate must say how many selected posts will be scraped,
 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 should describe the action, such as "Scrape 2 selected posts for
-the bounded review batch." 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.
+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.
+
+For Signal Discovery, use this compact source-action approval shape after
+selected posts exist:
+
+```markdown
+## Source Recommendation
+
+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>
+**Review checkpoint:** import the first 25 leads into the campaign for fit and message review before scaling<br>
+
+### Selected posts
+
+| Post             | Why it fits                                     | Visible engagement |
+| ---------------- | ----------------------------------------------- | -----------------: |
+| Dylan Power      | Claude outbound system                          |             ~1,571 |
+| Fivos Aresti     | Replacing Clay outbound with Claude Code        |               ~734 |
+| Divyanshi Sharma | LinkedIn lead-gen system built with Claude Code |               ~508 |
+
+**Total visible pool:** ~2,813 engagers<br>
+**Estimated good-fit pool at 15%:** ~420 prospects before dedupe/risk cleanup
+
+### Recommendation
+
+Approve scraping these 3 posts.
+
+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.
+
+**Fallback:** if the review batch is too vendor-heavy, agency-heavy, or
+off-ICP, switch to Sales Nav recent 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,
@@ -169,8 +210,15 @@ customer-facing source-choice labels.
 
 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`. The filter and message branches use live
-CampaignOffer/source/table state as the source of truth. Debug markdown/json
+`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.
 
 When the user chooses filters, immediately call
@@ -198,7 +246,9 @@ get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/
 ```
 
 Do not load the full `generate-messages` prompt in the create-campaign parent
-thread unless you are executing the parent-thread fallback for that branch.
+thread unless you are executing the parent-thread fallback for the actual
+message-draft branch. Parent-thread template approval uses only the compact
+message-review safety gate.
 
 ## Hard Gates
 

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

@@ -35,7 +35,7 @@ tell them what they will see next.
   is missing.
 - "lead source" beats provider internals unless comparing options.
 - "I’ll create the campaign shell with the brief so you can watch it fill in,
-  but no leads import and nothing sends yet" beats mutation jargon.
+  with approval gates before sourcing" beats mutation jargon.
 - "I’m turning this into a brief now" beats "I’m persisting the draft."
 - "Sorry, this is taking a little longer than expected" is appropriate when a
   step overruns its estimate. Do not over-apologize; one calm acknowledgment is
@@ -148,9 +148,9 @@ unless the user asks for them.
 Good opening:
 
 ```text
-I’ll help you launch this as a Sellable campaign. First I’ll resolve the
-client/company this campaign is for, then I’ll turn that into a campaign brief
-before any leads are imported or anything can send.
+I’ll help you launch this as a Sellable campaign. First I’ll confirm who we’re
+sending from and which company this is for, then I’ll turn that into a campaign
+brief before lead sourcing or anything can send.
 ```
 
 Good identity setup:
@@ -236,6 +236,13 @@ source. That approval only authorizes scouting/search. Second, after the
 source evidence exists, show counts, samples, fit math, cleanup risk, and ask
 for source approval before import.
 
+For Signal Discovery, the second gate is not "approve source" in the abstract.
+It is a concrete scrape approval: show a compact `## Source Recommendation`
+with the ~150 good-fit prospect goal, 15% raw-engager assumption, selected-post
+table, total visible pool, estimated good-fit pool, first-pass review
+batch, and fallback. The approval question should be "Approve scraping N Signal
+Discovery posts?"
+
 ## Parallelism + Naming
 
 Source selection is sequential by default. Start with the first recommended
@@ -257,14 +264,15 @@ scout loads only its matching provider prompt. If source work is sequential,
 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 source
-approval and use the returned canonical `name` values. Launch both returned
-scouts in the same assistant turn/message when real subagents are available:
-`post-find-leads-filter-scout` and `post-find-leads-message-scout`. This is the
-same registry pattern as source scouting, but the trigger is approved
-source output plus a non-empty bounded review batch. 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.
+For post-lead work, call `get_post_find_leads_scout_registry` 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.
 
 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:

package/skills/create-campaign-v2/core/auto-execute.README.md

@@ -33,16 +33,16 @@ the imported review batch for validation).
 
 - **`sampleSize`** — How many rows the validation loop pulls from the
   imported review batch. In v2 this matches the review-batch cap
-  (default 15), so the user sees enough real rows to judge the campaign
+  (default 25), so the user sees enough real rows to judge the campaign
   without spending credits on hundreds more.
 - **`minProjectedPass`** — Passing-message floor required before handoff.
-  The default requires 3 passing examples from the 15-row review batch.
+  The default requires 5 passing examples from the 25-row review batch.
   Math:
   ```text
   projectedPass = round(passInSample / sampleSize * importLimit)
   ```
-  With defaults (sampleSize=15, importLimit=15), `projectedPass` equals
-  the actual review-batch pass count. 3 passing rows is exactly at the
+  With defaults (sampleSize=25, importLimit=25), `projectedPass` equals
+  the actual review-batch pass count. 5 passing rows is exactly at the
   floor.
 - **`maxRevisionRounds`** — Hard cap before escalating to the user. A
   revision round is one full sample pass that triggered brief revision

package/skills/create-campaign-v2/core/auto-execute.yaml

@@ -17,7 +17,7 @@ import:
   # Initial review batch imported in Step 13 before the sample validation
   # loop. Import + enrichment must never exceed this cap before the user
   # reviews the sample and explicitly asks to expand.
-  importLimit: 15
+  importLimit: 25
   # Provider is inherited from the campaign-attached source association created
   # during find-leads. Step 13 may re-run provider preflight in memory, but it
   # does not choose a new source.
@@ -27,11 +27,11 @@ sample:
   # Rows pulled from the imported cohort for the validation loop. In v2 this
   # equals the review-batch cap so the user sees a focused first test batch
   # without spending credits on hundreds of rows.
-  sampleSize: 15
+  sampleSize: 25
   # Projected first-batch passing count required to proceed to sample
   # messaging. This is not approval to scale the full source list.
   # projectedPass = round(passInSample / sampleSize * importLimit).
-  minProjectedPass: 3
+  minProjectedPass: 5
   # Hard cap on revision loops before escalating to the user. On a stale
   # resume the counter does NOT reset — the 3-round cap holds across
   # sessions.
@@ -106,7 +106,7 @@ handoff:
   # Orientation surfaced in Step 16 ("awaiting-user-greenlight") along with
   # the watch link. Keep this short and user-facing.
   orientation: >-
-    Review the first 15 enriched leads and messages. If they look good,
+    Review the first 25 enriched leads and messages. If they look good,
     attach a sender in Settings, accept the recommended sequence, and start
     the campaign without spending credits on more leads first.
 

package/skills/create-campaign-v2/core/flow.v2.json

@@ -1,7 +1,7 @@
 {
   "version": "v2.1-compact",
   "workflow": "create-campaign-v2",
-  "principle": "CampaignOffer state and the watch link are canonical from the first brief onward. The active customer path is shell-first and state-first: create the watchable campaign shell with the brief, attach source/search state to that CampaignOffer, import one bounded review batch, persist rubrics and approved message template, validate the review batch, then hand off to Settings, sequence, and explicit start.",
+  "principle": "CampaignOffer state and the watch link are canonical from the first brief onward. The active customer path is shell-first and state-first: create the watchable campaign shell with the brief, attach source/search state to that CampaignOffer, import one bounded review batch, persist rubrics, wait on Filter Leads for approved message-template review, save the approved template, validate the bounded review batch, generate and review bounded messages, then hand off to Settings, sequence, and explicit start.",
   "normalCustomerPath": "Use campaign state, MCP tool responses, and concise watchNarration. Do not create, read, link, or surface local draft files in normal customer runs.",
   "legacyCompatibility": {
     "validationSubskill": "create-campaign-v2-validation",
@@ -460,6 +460,7 @@
           "requiredInlineFields": [
             "primary source and exact filters/recipe",
             "specific source action awaiting approval",
+            "for Signal Discovery: Source Recommendation markdown with ~150 good-fit prospects as the target, source-candidate plan ~1,000 raw engagers at a conservative ~15% fit assumption, review checkpoint size, selected-post table, total visible pool, estimated good-fit pool, first pass, and fallback",
             "for Signal Discovery: selected post count and target engager/source-candidate volume",
             "bounded review batch size",
             "runner-up and why it lost",
@@ -475,13 +476,13 @@
           "action": "ask_source_review_choice",
           "uses": "request_user_input",
           "choices": [
-            "Scrape selected posts for the bounded review batch",
+            "Approve scraping N Signal Discovery posts",
             "Run the approved source import for the bounded review batch",
             "Revise source",
             "Pause here"
           ],
           "approvalChoiceLabelsByProvider": {
-            "signal-discovery": "Scrape selected posts for the bounded review batch",
+            "signal-discovery": "Approve scraping {selectedPostCount} Signal Discovery posts?",
             "sales-nav": "Import the approved Sales Nav review batch",
             "prospeo": "Import the approved Prospeo review batch"
           }
@@ -540,7 +541,7 @@
             "importLimit"
           ],
           "requiredValues": {
-            "importLimit": 15
+            "importLimit": 25
           },
           "modeAddHandshake": {
             "firstCallReturns": "needsModeSelection when adding to an existing campaign-attached list",
@@ -579,7 +580,18 @@
         {
           "action": "launch_message_draft_builder_after_review_batch_import",
           "tool": "get_post_find_leads_scout_registry",
-          "requiresNonEmptyRows": true
+          "target": "post-find-leads-message-scout",
+          "requiresNonEmptyRows": true,
+          "mustRunBefore": [
+            "filter-choice question",
+            "filter approval",
+            "save_rubrics"
+          ],
+          "mode": "background_when_host_supports_subagents",
+          "fallback": "if no real background branch can start, say the real sequence and do not claim background drafting is running",
+          "toolCallRequiredInBranch": "get_subskill_prompt({ subskillName: \"generate-messages\", offset, limit }) until hasMore=false",
+          "runtimeProofTransport": "CampaignOffer.watchNarration.workerDetails.messageDraftBuilder",
+          "purpose": "start the provisional message draft from the imported review batch immediately; do not defer this to filter approval"
         }
       ],
       "requiredCampaignState": [
@@ -702,7 +714,7 @@
           "purpose": "load canonical post-lead worker names"
         },
         {
-          "action": "launch_or_reuse_post_lead_workstreams",
+          "action": "launch_or_reuse_lead_fit_builder_and_existing_message_draft",
           "mode": "parallel_when_host_supports_subagents",
           "inputs": [
             "campaignId",
@@ -713,7 +725,8 @@
             "filterChoice"
           ],
           "stateSource": "CampaignOffer and workflow table rows",
-          "debugFilesOptionalOnly": true
+          "debugFilesOptionalOnly": true,
+          "messageDraftRule": "reuse or join the Message Draft Builder branch that started immediately after confirm_lead_list; do not start first-time message drafting here unless the earlier branch failed to start"
         },
         {
           "action": "save_filter_rubrics_to_campaign",
@@ -727,7 +740,7 @@
           "requiredSideEffects": {
             "enableICPFilters": true,
             "currentStep": "apply-icp-rubric",
-            "watchNarration.headline": "Filter Leads is ready"
+            "watchNarration.headline": "Filter rules saved"
           }
         }
       ],
@@ -769,7 +782,8 @@
       ],
       "hardRules": [
         "after_save_rubrics_currentStep_must_be_apply-icp-rubric",
-        "do_not_move_browser_to_messages_until_filter_leads_step_is_current_or_filters_are_explicitly_skipped"
+        "do_not_move_browser_to_messages_until_filter_leads_step_is_current_or_filters_are_explicitly_skipped",
+        "message_draft_builder_start_is_not_deferred_until_filters"
       ],
       "transitions": {
         "post_lead_workstreams_ready": "message-review",
@@ -800,7 +814,7 @@
           "requiredSideEffects": {
             "enableICPFilters": true,
             "currentStep": "apply-icp-rubric",
-            "watchNarration.headline": "Filter Leads is ready"
+            "watchNarration.headline": "Filter rules saved"
           }
         }
       ],
@@ -968,17 +982,26 @@
         "revise_messaging"
       ],
       "transitions": {
-        "message_approved": "auto-execute-messaging",
+        "message_approved": "validate-sample",
         "revise_messaging": "message-generation"
       }
     },
     {
       "id": "validate-sample",
-      "label": "Validate bounded review batch (legacy)",
-      "currentStepValue": "validate-sample",
-      "legacyOnly": true,
+      "label": "Validate bounded review batch",
+      "currentStepValue": "apply-icp-rubric",
       "reference": "references/sample-validation-loop.md",
+      "visibleStepRule": "This is the same Filter Leads screen reached by save_rubrics. Do not route away from or back to Filter Leads on approve-message; save the approved template, refresh watch narration on apply-icp-rubric, then queue the bounded Enrich Prospect cells.",
       "onEnter": [
+        {
+          "tool": "update_campaign",
+          "requiredValues": {
+            "currentStep": "apply-icp-rubric",
+            "watchNarration.stage": "fit-message"
+          },
+          "purpose": "keep the watched UI on Filter Leads while the approved template starts the bounded cascade",
+          "watchNarrationRule": "Say the template is saved and Filter Leads is now running the bounded enrichment and scoring pass."
+        },
         {
           "tool": "queue_cells",
           "purpose": "queue ICP/enrichment cells for the bounded review batch only",
@@ -1121,10 +1144,21 @@
         {
           "tool": "update_campaign",
           "requiredValues": {
-            "currentStep": "awaiting-user-greenlight",
+            "currentStep": "auto-execute-messaging",
             "watchNarration.stage": "review-ready"
           },
-          "watchNarrationRule": "Say what just happened, that review-batch messages are ready, and that the next action is Settings/sender review."
+          "watchNarrationRule": "Say what just happened, that review-batch messages are ready in Messages, and that the next action is reviewing or approving generated messages before Settings."
+        },
+        {
+          "action": "ask_generated_message_review_choice",
+          "uses": "request_user_input",
+          "choices": [
+            "Approve generated messages",
+            "Revise filters",
+            "Revise message template",
+            "Pause here"
+          ],
+          "rule": "Do not advance to Settings until the generated review-batch messages have been reviewed and approved."
         }
       ],
       "allowedTools": [
@@ -1151,11 +1185,13 @@
         "proposed_token_never_persisted_in_rewrite"
       ],
       "waitFor": [
-        "review_batch_ready",
+        "generated_messages_approved",
         "sample_revision_required"
       ],
       "transitions": {
-        "review_batch_ready": "awaiting-user-greenlight",
+        "generated_messages_approved": "awaiting-user-greenlight",
+        "revise_filters": "filter-rubric",
+        "revise_messaging": "message-generation",
         "escalation_triggered": "escalation"
       }
     },
@@ -1188,7 +1224,7 @@
             "connect or select a LinkedIn sender",
             "Slack reply review",
             "recommended sequence",
-            "nothing starts until the user confirms launch"
+            "final launch confirmation is still ahead"
           ]
         },
         {

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

@@ -15,7 +15,7 @@ packet.
 
 The approval gate used to be the place where the user authorized
 spend/send-adjacent mutation. It is now compatibility-only. New runs import the
-bounded 15-row review batch after source approval, save rubrics and the approved
+bounded review batch after source approval, save rubrics and the approved
 message template after post-import review, and only then queue the cascade.
 
 If `campaign-shell.json` exists, a draft `CampaignOffer` row already exists but

package/skills/create-campaign-v2/references/filter-leads.md

@@ -174,6 +174,14 @@ If more than roughly 20% of the review batch appears to be the forbidden side,
 classify it as a list/source problem and return `revise-find-leads`; do not
 hide that problem behind narrow rubrics.
 
+## Suppression And Relationship Safety
+
+Do not put DNC or one-off relationship-safety notes into production rubrics
+unless the review batch shows that the pattern will leak at meaningful volume
+and normal DNC/domain suppression will not catch it. Former employers, existing
+customers, investors, partner lists, and one-off do-not-contact domains usually
+belong in the recommendation as DNC/suppression instructions outside the rubric JSON.
+
 ## Production Rubric Shape
 
 Confirmed rubrics must use the production `LeadScoringRubric` fields exactly:
@@ -265,6 +273,40 @@ Interpretation:
 - Density dramatically below the band: likely source contamination, ICP drift,
   or provider-side weakness; investigate before launch.
 
+## Post-Filter Signal Enrichment Pass (Sales Nav lane)
+
+Run this only for Sales Nav FIT rows when the downstream message step does not
+already have row-level post evidence. In normal campaign-backed runs, use live
+campaign-table row state as the source of truth. In explicit debug/UAT artifact
+flows, append the diagnostic copy back to `lead-sample.json`.
+
+This pass exists to protect the Earned-right and Read-as-1:1 substance filters.
+Without row-level posts, message generation is likely to fall back to generic
+category openers or presumed intent instead of evidence the recipient can
+recognize.
+
+Contract:
+
+- scope: Sales Nav FIT rows only; do not enrich MAYBE or REJECT rows for this
+  pass
+- budget cap: top 10 FIT rows by filter score
+- tool: `mcp__sellable__fetch_linkedin_posts`, called per row
+- fetch: most recent 3-5 public posts when available
+- target surface: store each result as `recent_posts[]` entries with
+  `{ url, posted_at, excerpt }`; keep `recent_posts: []` for quiet profiles
+- order of operations: run AFTER `lead-filter.md` is written, BEFORE
+  `message-validation.md` starts drafting
+
+Record enrichment outcome in the filter summary: rows attempted, rows with
+posts, rows with zero public posts, and tool failures. If more than half of the
+attempted rows have zero posts, flag low signal density and tell message
+generation to prefer trigger, peer-observation, or non-post proof instead of a
+post-quote opener.
+
+Do not convert "recently posted" or post availability into an ICP fit rubric.
+The posts are message evidence only; buyer qualification still comes from role,
+authority, account fit, capacity, geography, and exclusions.
+
 ## Decision Rules
 
 - Use `confirmed` when the source lane is viable and the rubrics are enough to