@sellable/mcp 0.1.143 → 0.1.144

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,20 @@ 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:
+
+- goal: about 300 good-fit prospects after cleanup, enrichment, and filters
+- working assumption: about 15% of raw post engagers become good-fit prospects
+- engagers needed: about 2,000 raw engagers
+- 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 15 leads into 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 +188,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
@@ -412,7 +430,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
@@ -609,9 +627,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
@@ -621,14 +641,14 @@ updates.
    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.
+   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.
+
+**Goal:** ~300 good-fit prospects after cleanup, enrichment, and filters<br>
+**Working assumption:** ~15% of raw post engagers become good-fit prospects<br>
+**Engagers needed:** ~2,000 raw engagers
+
+### 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 target ~300 good-fit prospects after cleanup, 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 15 leads into the
+review batch so we can inspect quality 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 ~300 good-fit prospect goal, 15% raw-engager assumption, selected-post
+table, total visible pool, estimated good-fit pool, first-pass 15-row 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/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 goal ~300 good-fit prospects, ~15% raw-engager fit assumption, ~2,000 raw engagers needed, 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"
           }
@@ -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/final-handoff-contract.md

@@ -33,8 +33,8 @@ order (all before waiting for the user):
    `get_campaign_navigation_state` when available so the watch link visibly
    lands on Settings before sender setup.
 4. Explain sender setup and Slack in normal customer language: Sellable needs a
-   connected LinkedIn sender before anything can send, and Slack reply review
-   matters because replies and approvals need a channel the team will monitor.
+   connected LinkedIn sender for launch, and Slack reply review matters because
+   replies and approvals need a channel the team will monitor.
 5. If no connected sender exists, surface the campaign Settings link
    `/campaign-builder/{campaignId}/settings?mode=claude`, tell the user to
    connect a sender there, and STOP. Do not attach sequence and do not start.
@@ -70,7 +70,7 @@ The final handoff must answer five customer questions in plain language:
 - why the selected LinkedIn sender and Slack reply review matter before launch
 - what clicking Start does (approves/starts the campaign send path)
 - how to revise (reply with what to change, or use the campaign UI)
-- whether anything has started yet (nothing sends until the user starts)
+- current launch status and what the final Start action does
 
 When `lead-source-intake.json` exists, also answer:
 
@@ -84,8 +84,8 @@ When `lead-source-intake.json` exists, also answer:
 
 Use the exact state name `awaiting-user-greenlight` so logs and UX artifacts
 can verify the state-machine stop point, but explain it in normal words: the
-campaign is built, sender/sequence setup is being completed, and nothing sends
-until the user's final start decision. The watched UI may advance through
+campaign is built, sender/sequence setup is being completed, and the final
+start decision is still ahead. The watched UI may advance through
 Settings, Sequence, and Send while this state-machine step remains the final
 handoff.
 

package/skills/create-campaign-v2/references/message-review-safety-gate.md

@@ -91,19 +91,94 @@ but the [topic] thread felt close enough to send`. Otherwise omit the
 
 ## Customer-Facing Message Review
 
-Render this in chat before asking:
-
-- `Status: message-review`
-- `Subject:`
-- `Message:` with the tokenized template or approved AI-native message
-- `Rendered examples:`
-- `Good token fill:`
-- `Good omit:`
-- `Token notes:`
-- `My take:`
-- `Suggested adjustment:`
-- `Question: approve-message or revise-messaging?`
-- `Recommendation: approve-message` or `Recommendation: revise-messaging`
+Render this in chat before asking. Use Markdown structure so the approval target
+is visually scannable:
+
+````markdown
+Status: message-review
+
+## Message Template
+
+**Subject**
+
+```text
+{{tokenized_subject}}
+```
+
+**Body**
+
+```text
+{{tokenized_message_body}}
+```
+
+## Rendered Examples
+
+### Good token fill
+
+Use when the row has a clean, supported fill.
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+
+### Good omit / fallback
+
+Use when a row signal or company context is missing, weak, or awkward.
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+
+### Bad fill to avoid
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+
+**Why this is wrong:** one sentence naming the exact token-fill failure.
+
+## Token Notes
+
+| Token            | Use when                 | Fallback |
+| ---------------- | ------------------------ | -------- |
+| `{{first_name}}` | Clean first name exists. | `there`  |
+
+## Recommendation
+
+**My take:** ...
+
+**Suggested adjustment:** ...
+
+**Question:** approve-message or revise-messaging?
+
+**Recommendation:** approve-message
+````
+
+Formatting requirements:
+
+- Put the tokenized template and every rendered example in fenced `text` blocks
+  so chat gives them a distinct background.
+- `Good token fill` and `Good omit / fallback` must each contain a complete
+  rendered subject + body, not a bullet list of token names or a single
+  bridge-line fragment.
+- Include `Bad fill to avoid` when the row sample has a tempting but unsafe
+  source-mechanics or raw-headline fill; otherwise include `Bad fill to avoid:
+none found`.
+- Use a token notes table, not paragraph-only token notes.
+- 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.

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

@@ -20,7 +20,9 @@ auto-revise leads.
 
 ## Inputs
 
-- `CampaignOffer.currentStep === "validate-sample"` (set at end of Step 13)
+- `CampaignOffer.currentStep === "apply-icp-rubric"` (the watched app is
+  already on Filter Leads after `save_rubrics`; `validate-sample` is the
+  logical loop name, not a visible route)
 - Imported review batch from Step 13 (size: `importLimit`, default 15)
 - Config from `auto-execute.yaml`: `sample.sampleSize`,
   `sample.minProjectedPass`, `sample.maxRevisionRounds`
@@ -48,7 +50,8 @@ auto-revise leads.
    the enrichment batch ids; NOT by calling wait_for_rubric_results
    before rubric was scheduled)
 
-5. check_rubric(sample)
+5. do not call `check_rubric`; the product cascade runs enrichment and rubric
+   scoring from the queued Enrich Prospect cells
 
 6. wait_for_rubric_results(sample, targetCount = <cohortSize>, minPassedCount = 1)
    - cohortSize = stats.totalRows of the enrichment batch, or the

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

@@ -2,8 +2,7 @@
 
 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_messages` call has
-already run.
+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.
@@ -25,7 +24,7 @@ Re-cascade runs whenever ALL of the following are true:
 
 1. Step 15 has already observed the initial review-batch message cascade.
 2. A subsequent check of rubric state shows rows that were pending at
-   first generate_messages time are now passed.
+   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`.