@sellable/mcp 0.1.154 → 0.1.155

package/skills/create-campaign/SKILL.md

@@ -70,8 +70,10 @@ CampaignOffer state and the watch link are the customer-facing source of truth.
 Disk artifacts are optional debug/UAT diagnostics; normal customer runs should
 not create, link, or surface local draft files unless the user explicitly asks
 for them. Resume, gating, and handoff read campaign state first. The
-watchable campaign exists after the short brief; lead import is bounded to the
-first review batch. After that, the user chooses whether to use filters or skip.
+watchable campaign exists after the short brief; source import copies the
+confirmed list into the campaign, then an internal first campaign-table
+execution slice configures filters and messages. After that, the user chooses
+whether to use filters or skip.
 When filters are chosen, save rubrics, get filter approval, then wait for
 message-template approval before enrichment/filtering or Generate Message cells.
 Use Template is the default message path; AI Generated is only an explicit
@@ -159,15 +161,17 @@ 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 15-row review/process sample size. For Sales
-    Nav or Prospeo, name the specific approved import lane and source lead count.
+    Signal Discovery, name how many selected posts will be scraped and the
+    target engager/source-candidate volume. For Sales Nav or Prospeo, name the
+    specific approved import lane and source lead count. Keep the internal
+    15-row campaign-table execution slice separate from source sampling.
 
 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
+    lead list, not importing only the internal execution slice. Use the provider
+    first-page/source sample
     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, keep refining/broadening filters
@@ -175,7 +179,7 @@ granted.
     with a source-list `targetLeadCount` around 1,000 by default (provider cap is
     internal when the raw pool is larger). Only after the source list is ready
     should `confirm_lead_list({ reviewBatchLimit: 15 })` copy confirmed rows into
-    the campaign table and return the first 15 review/process rows.
+    the campaign table and return the initial campaign-table execution slice rows.
 
 For Signal Discovery, the customer-facing approval card must use the exact
 action shape "Approve scraping N Signal Discovery posts?" and the chat summary
@@ -187,15 +191,16 @@ 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: after the source list exists, copy confirmed source rows
-  into the campaign and process only the first 15 for fit and message review
+- campaign setup checkpoint: after the source list exists, copy confirmed source rows
+  into the campaign and internally process the first execution slice for fit and message setup
 - 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, copy all confirmed source rows into the
-  campaign, then process only the first 15 rows before scaling
+- first pass: build the source list and copy all confirmed source rows into the
+  campaign; the campaign table then internally processes its first execution
+  slice before scaling
 - 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
+  below 10%, or if the source sample 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:
@@ -288,7 +293,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 review-batch validation. After message
+at Settings after message approval and campaign setup 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
@@ -393,7 +398,7 @@ the brief. This is only the client-prospect/bootstrap identity for
 Do not call `mcp__sellable__list_senders`, `mcp__sellable__get_sender`, or
 surface connected/missing sender state during setup, brief, source, filter, or
 message review. Sender availability belongs only to the Settings/final launch
-handoff after message approval and the review-batch validation sample.
+handoff after message approval and the campaign setup validation slice.
 
 If the invocation or user answer includes an existing `clientProspectId`, keep
 it as the preferred `create_campaign` identity input. If it includes a LinkedIn
@@ -677,13 +682,13 @@ updates.
    until `hasMore=false`. Message review requires Message Draft Builder output:
    do not draft from a checklist, local markdown artifact, or parent-thread
    intuition. Use campaign state, campaign brief content, selected source state, and
-   first review/process sample rows as the source of truth; do not read stale local
+   initial campaign-table execution slice 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. Materialize the approved
-   source list, copy confirmed rows into the campaign, and process only the
-   first 15 review rows after the source is attached to the campaign; do not
+   source list, copy confirmed rows into the campaign, and internally process the
+   first campaign-table execution slice after the source is attached to the campaign; do not
    queue workflow cells, attach a sequence, or start until saved filters and the
    message template/token rules are approved. When filters are chosen, immediately
    call `mcp__sellable__update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
@@ -691,7 +696,7 @@ updates.
    After rubrics save, keep Filter Rules visible for approval; after approval,
    move to Filter Leads and wait there for the background message recommendation.
    If filters are skipped, move to Messages/message review. Queue the bounded
-   review-batch `enrichCellId` cells only after message approval. Move to
+   campaign-table execution-slice `enrichCellId` cells only after message approval. Move to
    Messages only after at least one review row passes and one generated message
    is ready.
    Do not ask the user to approve the brief before shell creation unless they
@@ -700,14 +705,14 @@ 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 review batch, `create-icp-rubric` as soon
+   `filter-choice` after source rows are copied into the campaign table, `create-icp-rubric` as soon
    as filters are chosen and while saved filters await approval,
    `apply-icp-rubric` after filter approval and message approval while bounded
    enrichment/filter scoring runs, `validate-sample` only as a recovery/legacy
    observation state,
-   `auto-execute-messaging` after at least one row passes and review-batch
+   `auto-execute-messaging` after at least one row passes and initial campaign-row
    messages are being generated or reviewed, `awaiting-user-greenlight` only
-   after generated review-batch messages are approved, `settings` for sender
+   after generated campaign-row 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

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

@@ -1,6 +1,6 @@
 ---
 name: create-campaign-v2
-description: Execute the compact JSON-gated shell-first campaign flow: resolve campaign identity, create a watchable CampaignOffer shell with the brief, attach and approve the source, copy the confirmed source list into the campaign, process the first 15 review rows, persist rubrics and approved message template, validate the first passing generated message, then hand off to Settings, sequence, and start.
+description: Execute the compact JSON-gated shell-first campaign flow: resolve campaign identity, create a watchable CampaignOffer shell with the brief, attach and approve the source, copy the confirmed source list into the campaign, internally process the first campaign-table execution slice, persist rubrics and approved message template, validate the first passing generated message, then hand off to Settings, sequence, and start.
 visibility: internal
 ---
 
@@ -40,8 +40,10 @@ for debug output.
 4. Create the watchable campaign shell with `create_campaign` and the v1 brief.
 5. Surface the direct watch link.
 6. Choose and approve the lead source.
-7. Materialize the approved source list, confirm/copy it into the campaign, and
-   use only the first 15 rows as the initial review/process sample.
+7. Materialize the approved source list and confirm/copy it into the campaign.
+   Internally use the first 15 imported campaign-table rows as the initial
+   execution slice for filter/message setup; do not present that as source
+   sampling.
 8. Ask whether to use filters or skip them.
 9. Persist lead rubrics when filters are enabled, then ask approval while the
    app remains on Filter Rules.
@@ -74,7 +76,7 @@ offers are plausible, ask one campaign-focus choice before buyer/offer/proof.
 
 Do not call `list_senders`, do not infer the campaign from connected senders,
 and do not show a sender picker during setup. Sender availability belongs only
-to Settings after message approval and review-batch validation.
+to Settings after message approval and campaign setup validation.
 
 Use `research-sender` for concise identity/proof research and call
 `complete_sender_research` before shell creation. If WebSearch is unavailable,
@@ -178,33 +180,27 @@ reasonable refinement, move to Prospeo. Prospeo is the terminal fallback; if it
 also falls below 10%, tighten the ICP/source direction instead of inventing
 another provider.
 
-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 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 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 15-row review sample 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. Once the lane clears the target, ask
-approval to materialize the source list with
-`targetLeadCount` around 1,000 source contacts by default (use the provider cap
-internally when the raw pool is larger). After that source list is ready,
-`confirm_lead_list({ reviewBatchLimit: 15 })` copies confirmed source rows into
-the campaign table and returns the first 15 review/process row ids for fit and
-message review.
+After scouting, show a second approval gate for the concrete source action.
+For Signal Discovery, state selected-post count, target engager/source-candidate
+volume, internal campaign-table execution-slice size, cleanup risk, and fallback;
+label the approval like "Approve scraping 3 Signal Discovery posts?" For Sales
+Nav or Prospeo, name the specific search/import lane and source lead count. Do
+not call `import_leads` or `confirm_lead_list` until this gate is approved.
+
+For Sales Nav and Prospeo, do not ask to import only the internal 15-row
+campaign-table execution slice at the source-action gate. First-page samples are
+source math: sampled fit after cleanup, projected good-fit prospects, and
+whether the lane clears the campaign target. Once it clears, ask approval to
+materialize the source list with `targetLeadCount` around 1,000 source contacts
+by default. After that, `confirm_lead_list({ reviewBatchLimit: 15 })` copies
+confirmed source rows into the campaign table and returns the initial
+campaign-table execution slice row ids for filter and message setup.
 
 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 Sales Nav/Prospeo, pass `targetLeadCount` as the approved source-list
-export count, not the review-batch size. For Signal Discovery, pass
+export count, not the campaign execution-slice 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.
@@ -221,32 +217,24 @@ Use Signal Discovery first.
 **Working assumption:** ~20% of raw post engagers become good-fit prospects<br>
 **Engagers needed:** ~1,500 raw engagers<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:** after the source list exists, copy the entire confirmed source list into the campaign and process only the first 15 rows for fit and message review<br>
+**Campaign setup checkpoint:** after the source list exists, copy the entire confirmed source list into the campaign and internally process only the first execution slice for filter and message setup<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 |
+Show author/topic, why it fits, and visible engagement.
 
-**Total visible pool:** ~2,813 engagers<br>
-**Estimated good-fit pool at 20%:** ~560 prospects before dedupe/risk cleanup
+**Total visible pool:** ~2,800 engagers<br>
+**Estimated good-fit pool at 20%:** ~560 prospects before 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 and copy all confirmed source rows into
+the campaign. The campaign table then internally processes its first execution
+slice so filters and generated copy are configured before scaling.
 
-**First pass:** build the source list, copy all confirmed source rows into the
-campaign, then process only the first 15 rows so we can inspect quality before
-scaling.
-
-**Fallback:** if sampled/projected fit falls below 10%, or if the review batch
+**Fallback:** if sampled/projected fit falls below 10%, or if the source sample
 is too vendor-heavy, agency-heavy, or off-ICP, switch to Sales Nav recent
 activity.
 ```
@@ -258,7 +246,8 @@ 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 run a 15-row review sample.
+refine or broaden filters, not to run the internal campaign-table execution slice
+as if it were source sampling.
 
 Supplied profile CSVs, company/domain CSVs, pasted domains, and existing
 Sellable lead lists are supported, but keep provider mechanics out of the first
@@ -271,7 +260,7 @@ After `confirm_lead_list` copies a non-empty confirmed source into the campaign
 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:
+before the question should be a short campaign setup summary and the choice:
 add filters, skip filters, or revise source.
 
 If the user chooses filters, then load the post-lead registry/reference needed
@@ -305,7 +294,7 @@ get_subskill_prompt({ subskillName: "generate-messages", offset, limit }) until
 No shortcut message instructions are valid. If the host cannot launch the
 agent, the parent fallback must run the same full prompt from live campaign
 state before drafting. Do not render message review until
-`messageDraftRecommendation` proves current campaign/table/review-batch
+`messageDraftRecommendation` proves current campaign/table/execution-slice
 `generate-messages` basis.
 
 ## Hard Gates
@@ -314,7 +303,7 @@ state before drafting. Do not render message review until
 - Do not call `import_leads` or `confirm_lead_list` until the lead source is
   approved.
 - Do not queue enrichment, ICP scoring, filtering, or product Generate Message
-  cells until the review batch exists and the required message/filter approvals
+  cells until the campaign-table execution slice exists and the required message/filter approvals
   are complete.
 - Do not call `check_rubric`; persist production rubrics with `save_rubrics`.
 - Do not call `start_campaign` until the user explicitly confirms launch after
@@ -330,6 +319,6 @@ Load references only when needed:
 - `references/lead-validation-preview.md` for legacy/debug preview shapes.
 - `references/filter-leads.md` for rubric design and `save_rubrics` rules.
 - `references/step-13-import-leads.md` before source copy.
-- `references/sample-validation-loop.md` before review-batch validation.
+- `references/sample-validation-loop.md` before campaign setup validation.
 - `references/final-handoff-contract.md` for Settings, sender, sequence, and
   start.

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

@@ -52,8 +52,8 @@ turn anchored to that:
 4. Ask for brief approval before any lead import or sending-adjacent work.
 5. Find likely responders and approve the source.
 6. Copy the confirmed source list into the campaign and use the first 15 rows as
-   the review/process sample.
-7. Filter for fit and draft the reusable message template from the same sample.
+   the internal campaign-table execution slice for setup.
+7. Filter for fit and draft the reusable message template from the same slice.
 8. Queue the bounded fit cascade from saved rubrics/run conditions only after the
    message template is approved.
 9. Use Settings for sender selection, sequence attach, and final launch handoff.
@@ -83,7 +83,7 @@ example, like `omit the noticed... line` or `use "operators"`. Missing data
 should never produce robotic or creepy copy.
 
 Approved token guidance is part of the campaign, not just the review. After the
-first review/process sample exists and message generation has a selected
+initial campaign-table execution slice exists and message generation has a selected
 template, the campaign brief should carry forward the token fill rules and examples before any
 workflow-table cascade is queued: good fills, good omits, bad fills, fallback
 rules, and why the bad fills are blocked.
@@ -243,7 +243,7 @@ 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, 10% planning floor,
-first-pass review batch, and fallback. The approval question should be "Approve
+first-pass campaign setup, and fallback. The approval question should be "Approve
 scraping N Signal Discovery posts?"
 
 That scrape approval is single-use. Once the user approves it, do not replay

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

@@ -20,7 +20,7 @@ into the campaign).
 
 ### `import`
 
-- **`importLimit`** — Review/process sample size used after Step 13 copies the
+- **`importLimit`** — Internal execution-slice size used after Step 13 copies the
   confirmed source rows into the campaign. The tail MUST NOT exceed this cap
   before the message template is approved and at least one generated passing
   message is reviewed.
@@ -31,18 +31,18 @@ into the campaign).
 
 ### `sample`
 
-- **`sampleSize`** — How many rows the validation loop pulls from the first
-  review/process sample. In v2 this matches the process cap (default 15), so the
+- **`sampleSize`** — How many rows the validation loop pulls from the initial
+  campaign-table execution slice. In v2 this matches the process cap (default 15), 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 one passing example from the 15-row review sample.
+  The default requires one passing example from the 15-row internal slice.
   Math:
   ```text
   projectedPass = round(passInSample / sampleSize * importLimit)
   ```
   With defaults (sampleSize=15, importLimit=15), `projectedPass` equals the
-  actual review sample pass count. One passing row is exactly at the floor.
+  actual initial-slice pass count. One passing row 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
   and retried. On stale resume the counter does NOT reset.
@@ -50,7 +50,7 @@ into the campaign).
 ### `messaging`
 
 - **`tokenContract`** — `strict` rejects unresolved/unsupported tokens
-  before handing the review batch to the user. `relaxed` logs warnings but
+  before handing generated copy to the user. `relaxed` logs warnings but
   proceeds.
   Default `strict` because live campaign state shouldn't ship messages
   with unresolved templating.
@@ -125,9 +125,9 @@ into the campaign).
 After 3-5 real campaigns complete the tail, review the threshold-trip
 logs and adjust:
 
-- `importLimit` higher only if users consistently ask for larger review
-  batches and credit spend is acceptable.
-- `sampleSize` higher if a 15-row review sample is not enough to judge
+- `importLimit` higher only if users consistently ask for larger initial
+  setup slices and credit spend is acceptable.
+- `sampleSize` higher if a 15-row internal slice is not enough to judge
   quality for a specific market.
 - `minProjectedPass` lower only if fewer than 3 passing examples is still
   enough for a confident user decision.

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 watch link are canonical. Create the watched shell, approve source, materialize and confirm the source list, process the first 15 review rows, save rubrics for approval, approve the message template, then run the bounded filter/message cascade before Settings, sequence, and explicit start.",
+  "principle": "CampaignOffer state and watch link are canonical. Create the watched shell, approve source, materialize and confirm the source list, internally process the first campaign-table execution slice, save rubrics for approval, approve the message template, then run the bounded filter/message cascade before Settings, sequence, and explicit start.",
   "normalCustomerPath": "Use campaign state, MCP responses, and concise watchNarration. Do not create, read, link, or surface local draft files.",
   "legacyCompatibility": {
     "validationSubskill": "create-campaign-v2-validation",
@@ -494,7 +494,7 @@
             "specific source action awaiting approval",
             "for Signal Discovery: compact Source Recommendation with target, raw-engager math, selected-post table, review checkpoint, estimated fit, and fallback",
             "for Signal Discovery: selected post count and target engager/source-candidate volume",
-            "15-row review/process sample size",
+            "internal campaign-table execution slice size, clearly separate from source sampling",
             "runner-up and why it lost",
             "raw volume",
             "sampled people",
@@ -923,7 +923,7 @@
             "run background post-find-leads-message-scout when available",
             "get_subskill_prompt({ subskillName: \"generate-messages\", offset, limit }) until hasMore=false"
           ],
-          "stateSource": "campaignBrief, source, selectedLeadListId, workflowTableId, review-batch row ids/hash",
+          "stateSource": "campaignBrief, source, selectedLeadListId, workflowTableId, execution-slice row ids/hash",
           "outputState": "messageDraftRecommendation"
         }
       ],
@@ -945,7 +945,7 @@
         "Run post-find-leads-message-scout when available; otherwise parent fallback must load get_subskill_prompt({ subskillName: \"generate-messages\" }) from live state.",
         "brief.md, lead-review.md, and lead-sample.json are optional debug context only.",
         "messageDraftRecommendation returns templateRecommendation, tokenFillRules, renderedSample, concerns, status, basisToken, outputAt, outputHash, and error/retry detail.",
-        "If campaign/source/table/review-batch basis does not match, classify the output stale or blocked."
+        "If campaign/source/table/execution-slice basis does not match, classify the output stale or blocked."
       ],
       "doNotAllow": [
         "create_campaign",
@@ -1052,7 +1052,7 @@
     },
     {
       "id": "validate-sample",
-      "label": "Validate first review/process sample",
+      "label": "Validate campaign-table execution slice",
       "currentStepValue": "apply-icp-rubric",
       "reference": "references/sample-validation-loop.md",
       "visibleStepRule": "Filter Leads is reached only after saved-filter approval. On approve-message, save the template, refresh apply-icp-rubric narration, then queue bounded Enrich Prospect cells.",
@@ -1068,7 +1068,7 @@
         },
         {
           "tool": "queue_cells",
-          "purpose": "queue ICP/enrichment cells for the first 15 review/process rows only",
+          "purpose": "queue ICP/enrichment cells for the internal campaign-table execution slice only",
           "requiredFields": [
             "workflowTableId",
             "reviewBatchRowIds",
@@ -1148,7 +1148,7 @@
     },
     {
       "id": "auto-execute-messaging",
-      "label": "Generate review-batch messages",
+      "label": "Generate initial campaign-row messages",
       "currentStepValue": "auto-execute-messaging",
       "references": [
         "references/parallel-critique-protocol.md",

package/skills/create-campaign-v2/core/policy.md

@@ -71,7 +71,7 @@ Revision choices route back to the exact upstream stage:
 
 ## 6) Post-Message Tail
 
-After message approval, queue only the first review/process sample cells needed to move
+After message approval, queue only the initial campaign-table execution-slice cells needed to move
 the watched app through enrichment, ICP filtering, and approved-template message
 generation. Keep the tail observable through watch narration.
 

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

@@ -49,8 +49,8 @@ gate; route back to message generation.
 the user intentionally supplied a source. If present, the approval packet must
 summarize the source type, input mode, supplied profile/domain/list count,
 sampled count, what will be materialized after approval, and that only the
-review batch will be enriched/messaged before greenlight.
-Use the phrase "only the review batch" plainly enough that the operator
+initial campaign rows will be enriched/messaged before greenlight.
+Use the phrase "only the initial campaign rows" plainly enough that the operator
 understands approval is not permission to process the full supplied source.
 
 If any required artifact is missing, do NOT show the gate. Route back to the

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

@@ -21,7 +21,7 @@ Use only live campaign inputs supplied by the parent thread or scoped MCP tools:
 - campaign brief content
 - approved source decision and selected lead list/source state
 - `workflowTableId`
-- first review/process sample rows, including row ids/hash when available
+- initial campaign-table execution slice rows, including row ids/hash when available
 - user's filter choice and any explicit exclusions or tradeoffs
 
 The filter may inspect campaign-table rows through scoped tools such as
@@ -112,7 +112,7 @@ prospect can afford this specific offer at this specific price point. Use a
 reasonable public proxy such as funding, headcount, revenue band, team maturity,
 current tool spend, practice size, location count, consumer purchasing power,
 job-to-be-done intensity, or buyer budget ownership. If no reliable proxy exists
-in the review batch or normal enrichment path, return `confirm-with-user` and
+in the initial campaign rows or normal enrichment path, return `confirm-with-user` and
 ask the parent to get the budget proxy before message approval.
 
 ## Table-Stakes Gates
@@ -141,7 +141,7 @@ the gate is irrelevant for this campaign:
 ## Competitor / Vendor Exclusion
 
 Every confirmed filter should include a competitor / vendor / wrong-side
-exclusion unless the brief and review batch make it clearly irrelevant.
+exclusion unless the brief and campaign rows make it clearly irrelevant.
 
 Use this test:
 
@@ -149,11 +149,11 @@ Use this test:
   or marketplace participant appear on the same comparison page as the client?
 - Would they compete for the same customer budget, sell into the same buyer
   workflow, or sit on the wrong side of the marketplace?
-- Did the review batch show adjacent companies that the customer would likely
+- Did the campaign rows show adjacent companies that the customer would likely
   reject only after seeing the list?
 
 If yes, add an explicit exclude rule. Include named competitors from the brief,
-review batch, or user context when available, plus the general category
+campaign rows, or user context when available, plus the general category
 exclusion so new lookalike competitors are also blocked.
 
 ## Marketplace Safety
@@ -170,14 +170,14 @@ Examples:
 - Supply-side acquisition campaign: exclude demand-side buyers or employers when
   they are not the outbound target.
 
-If more than roughly 20% of the review batch appears to be the forbidden side,
+If more than roughly 20% of the initial campaign rows appear 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
+unless the campaign rows show 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.
@@ -231,19 +231,19 @@ Recommended grouping:
 
 For each proposed rule:
 
-1. Inspect matching and failing review-batch rows.
+1. Inspect matching and failing campaign rows.
 2. Decide whether the rule removes real noise or blocks real buyers.
 3. Mark the rule as necessary, loosen, or remove.
 4. Estimate the resulting pass rate and yield impact.
 
 Repeated false positives should become explicit exclude rules whenever the same
-pattern appears more than once in the review batch. Preview-card missingness is
+pattern appears more than once in the campaign rows. Preview-card missingness is
 not a hard production exclusion unless the same missing evidence will remain
 missing after normal enrichment/public research.
 
 ## Source Contradictions
 
-If review-batch evidence contradicts the approved source thesis, do not rewrite
+If campaign-row evidence contradicts the approved source thesis, do not rewrite
 the campaign brief silently. Return one of these instead:
 
 - `confirm-with-user` when a viable alternative source or filter tradeoff needs
@@ -319,7 +319,7 @@ authority, account fit, capacity, geography, and exclusions.
 - Do not save rubrics for `confirm-with-user` or `revise-find-leads`.
 - Do not loosen the filter just to preserve volume.
 - Do not make the filter so narrow that it contradicts the approved source
-  unless review-batch evidence clearly requires it.
+  unless campaign-row evidence clearly requires it.
 
 ## Prohibited During Normal Create-Campaign
 

package/skills/create-campaign-v2/references/final-handoff-contract.md

@@ -18,7 +18,7 @@ CampaignOffer state and the watch link are canonical. Disk artifacts are
 optional debug/UAT diagnostics, and normal customer runs should not expose local
 draft files. Resume, gating, and handoff read campaign state first. At this
 point, `workflowTableId` is the campaign table, while `selectedLeadListId`
-remains the source list that produced the review batch.
+remains the source list that produced the campaign rows.
 
 ## Step 16 Setup
 
@@ -64,7 +64,7 @@ currentStep: "sequence" })` to attach the sender via the v3 senders route and
 The final handoff must answer five customer questions in plain language:
 
 - where to inspect the campaign (`watchUrl`)
-- what is ready now (brief, filters/rubrics, review-batch leads, messages, and
+- what is ready now (brief, filters/rubrics, campaign rows, messages, and
   sequence after a sender is attached)
 - whether the next UI step is Settings, Sequence, or Send
 - why the selected LinkedIn sender and Slack reply review matter before launch
@@ -77,8 +77,8 @@ When `lead-source-intake.json` exists, also answer:
 - which source was materialized (`supplied-linkedin-profiles`,
   `supplied-domains`, or `existing-lead-list`)
 - how many rows/accounts were supplied
-- how many rows were imported into the first review batch
-- that only the first review batch was enriched and messaged before
+- how many rows were imported into the initial campaign setup slice
+- that only the initial campaign rows were enriched and messaged before
   greenlight, not the full supplied list
 - for `existing-lead-list`, that the source list was reused, not recreated