@sellable/mcp 0.1.103 → 0.1.104

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.103",
+  "version": "0.1.104",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

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

@@ -1,6 +1,6 @@
 ---
 name: create-campaign-v2
-description: Execute the JSON-gated shell-first campaign flow with chained Phase 84 artifacts: create a watchable campaign shell with a v1 brief, attach the source with campaignId, import the first 10-row review batch, save rubrics and approved message template, then queue the review cascade and hand off to settings/sequence/start.
+description: Execute the JSON-gated shell-first campaign flow with chained Phase 84 artifacts: create a watchable campaign shell with a v1 brief, attach the source with campaignId, import the first 15-row review batch, save rubrics and approved message template, then queue the review cascade and hand off to settings/sequence/start.
 visibility: internal
 ---
 
@@ -11,7 +11,7 @@ You are the create-campaign-v2 orchestrator. Your job is to execute the
 configured `core/flow.v2.json` state machine from scratch: (1) interview the
 user, resolve campaign identity/client-prospect context, and create a watchable
 campaign shell with the v1 brief already attached, (2) use that campaign id for
-source selection, (3) import/confirm the first 10-row review batch to establish
+source selection, (3) import/confirm the first 15-row review batch to establish
 `workflowTableId`, (4) create rubrics and message artifacts from that campaign
 table sample, (5) sync the approved message set into the campaign brief, and
 (6) queue/observe the bounded cascade before settings, sequence, and start.
@@ -23,12 +23,12 @@ Run the configured JSON flow in durable stages:
 0. client identity/source intake + watchable campaign shell with v1 brief
 1. create-campaign-brief
 2. find leads with the campaign id
-3. import/confirm the first 10-row review batch
+3. import/confirm the first 15-row review batch
 4. filter leads from the campaign table sample
 5. generate message from the same campaign table sample
 6. message review gate
 7. sync approved message set into the campaign brief
-8. queue and validate the 10-row cascade
+8. queue and validate the 15-row cascade
 9. settings/sender, sequence, and start handoff
 
 The JSON flow is the source of truth for stage order, artifact policy,
@@ -94,9 +94,9 @@ Optional debug/UAT draft directory, disabled in normal customer runs:
   stage, call `update_campaign({ campaignId, currentStep })` with the visible UI
   step the user should be watching, then continue the work from MCP/product
   state. Use `create-offer` for the brief, `pick-provider` or the selected
-  provider step while sourcing, `filter-choice` after the 10-row review batch is
+  provider step while sourcing, `filter-choice` after the 15-row review batch is
   imported, `messages`/`auto-execute-messaging` for message work,
-  `validate-sample` for the 10-row validation cascade, and
+  `validate-sample` for the 15-row validation cascade, and
   `awaiting-user-greenlight` for Settings. Do not advance `currentStep` backward.
 - After the shell is minted, normal resume paths read the CampaignOffer first.
   Use debug files to explain or reconstruct work, not to decide whether a
@@ -172,7 +172,7 @@ Optional debug/UAT draft directory, disabled in normal customer runs:
   "Sellable token".
   "Quick question panel" is only acceptable when explaining a Codex/Claude setup
   blocker.
-- Before the 10-lead import/test batch, do not call `check_rubric`; Phase 84
+- Before the 15-lead import/test batch, do not call `check_rubric`; Phase 84
   only writes and validates artifacts, saves rubrics, and syncs campaign setup
   state.
 - Never narrate local draft housekeeping to the user. If you create directories,
@@ -201,7 +201,7 @@ Optional debug/UAT draft directory, disabled in normal customer runs:
 - Do not call `list_senders`, `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
-  `approve-message` and the 10-lead validation sample. The first user-visible
+  `approve-message` and the 15-lead validation sample. The first user-visible
   sender blocker should be at `awaiting-user-greenlight`/Settings.
 - If the invocation or user answer includes an existing `clientProspectId`, keep
   it as the preferred `create_campaign` identity input. If it includes a
@@ -434,7 +434,7 @@ usually takes ~3-5 min, and I'll show you the source decision + sample before
 anything goes live.`
 - After the lead sample/source decision is ready and approved,
   show the next progress line:
-  `Lead source is set. I'll import the first 10-row review batch into the
+  `Lead source is set. I'll import the first 15-row review batch into the
 campaign table, then use that same batch to tighten the fit filter and draft the
 message we should test.`
 - During long post-intake work, show concise progress checkpoints before the
@@ -509,7 +509,7 @@ message we should test.`
   and `message-validation.md`, then reconciles that the selected message basis
   rows still pass the final filter.
   If a legacy/resume host starts message prep from preview rows before import,
-  it still needs at least 5 probable good-fit rows and must reconcile the final
+  it still needs at least 3 probable good-fit rows and must reconcile the final
   winner against the imported review batch before message review.
 - `lead-sample.json` from `find leads` is always the message sample source.
   `filter leads` must not create a different message sample or cause message
@@ -556,7 +556,7 @@ workstreams`, `in parallel`, or `background` unless parallel branches were
 - Never call a tool outside the active step's `allowedTools`, and never call a
   tool listed in the active step's `doNotAllow`.
 - Before the source is approved, `import_leads` and `confirm_lead_list` are
-  forbidden. After source approval, import/confirm only the bounded 10-row
+  forbidden. After source approval, import/confirm only the bounded 15-row
   review batch. Before rubrics and the approved message set are both on the
   campaign, the spend/send-adjacent cascade tools are forbidden: `queue_cells`,
   `enrich_with_prospeo`, `bulk_enrich_with_prospeo`,
@@ -565,7 +565,7 @@ workstreams`, `in parallel`, or `background` unless parallel branches were
   the active `flow.v2.json` step allows them.
 - During pre-import validation, do not call `check_rubric`; use the lead-filter
   artifacts and only use campaign-backed scoring after Step 13 imports the
-  10-lead test batch.
+  15-lead test batch.
 - Resume state is based on CampaignOffer state first, then the presence and
   completeness of the chained debug artifacts. Never treat file presence as the
   durable source of truth after the campaign exists.
@@ -574,8 +574,8 @@ workstreams`, `in parallel`, or `background` unless parallel branches were
 - Exception: brief-validated may rewrite §3 Campaign Thesis AND §12 Next Steps
   when Phase-84 lead-yield data clearly contradicts a Phase-83 UNVALIDATED
   decision on primary lead-source. "Clearly contradicts" = the Phase-83
-  primary source yields 0 FIT while an alternative source yields ≥ 5 FIT in
-  the same 10-row test sample (or an equivalent ≥ 5× ratio at larger samples).
+  primary source yields 0 FIT while an alternative source yields ≥ 3 FIT in
+  the same 15-row test sample (or an equivalent ≥ 5× ratio at larger samples).
   Every rewrite MUST cite specific yield numbers from `lead-review.md`. All
   other Phase-83 brief sections remain read-only. See
   `references/filter-leads.md` § Brief-Validated Rewrite Authority for the
@@ -584,14 +584,14 @@ workstreams`, `in parallel`, or `background` unless parallel branches were
   artifact intact.
 - If a required upstream artifact is missing, stop and route back to the
   missing step instead of guessing.
-- Before importing the 10-lead test batch, persist a customer-facing
+- Before importing the 15-lead test batch, persist a customer-facing
   `message-review.md` and `message-review-decision.md` so the message decision
   can be inspected later.
 - The message review must show one concrete sample message rendered as the
   recipient would see it, in addition to the approved message template. Do not
   make the user mentally expand `{{tokens}}`.
 - Do not include sequence, cadence, sending-window, mailbox, or campaign
-  settings review in `message-review.md`. Those come after the 10-lead test
+  settings review in `message-review.md`. Those come after the 15-lead test
   batch, in the settings/sequence handoff.
 - Do not include post-accept DMs, connection-accepted follow-ups, day-2 / day-7
   follow-ups, second touches, reply branches, or any other sequence-shaped copy
@@ -620,7 +620,7 @@ There are four customer-visible gates in the net-new hosted flow:
   only whether to proceed with the selected message (`approve-message`) or run
   one more messaging revision (`revise-messaging`). `approve-message` authorizes
   syncing the approved message set into the campaign brief, saving rubrics,
-  importing the bounded 10-lead test batch, and queueing/observing that sample.
+  importing the bounded 15-lead test batch, and queueing/observing that sample.
 - The sender/settings/sequence handoff is the launch gate. 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

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

@@ -81,7 +81,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. Before
-the 10-lead test batch imports, the campaign brief should carry forward the
+the 15-lead test batch imports, the campaign brief should carry forward the
 token fill rules and examples: good fills, good omits, bad fills, fallback
 rules, and why the bad fills are blocked.
 The campaign brief must carry forward the token fill rules from review into the

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 25), so the user sees enough real rows to judge the campaign
+  (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 5 passing examples from the 25-row review batch.
+  The default requires 3 passing examples from the 15-row review batch.
   Math:
   ```text
   projectedPass = round(passInSample / sampleSize * importLimit)
   ```
-  With defaults (sampleSize=25, importLimit=25), `projectedPass` equals
-  the actual review-batch pass count. 5 passing rows is exactly at the
+  With defaults (sampleSize=15, importLimit=15), `projectedPass` equals
+  the actual review-batch pass count. 3 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
@@ -130,7 +130,7 @@ logs and adjust:
   batches and credit spend is acceptable.
 - `sampleSize` higher if a 25-row review batch is not enough to judge
   quality for a specific market.
-- `minProjectedPass` lower only if fewer than 5 passing examples is still
+- `minProjectedPass` lower only if fewer than 3 passing examples is still
   enough for a confident user decision.
 - `maxRevisionRounds` should rarely change; 3 is already generous. If
   brief revision is hitting the cap often, the brief template upstream

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: 10
+  importLimit: 15
   # 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: 10
+  sampleSize: 15
   # 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: 5
+  minProjectedPass: 3
   # 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 10 enriched leads and messages. If they look good,
+    Review the first 15 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",
   "workflow": "create-campaign-v2",
-  "principle": "CampaignOffer state and the watch link are canonical from the first brief onward. Disk artifacts are optional debug/UAT diagnostics, not the normal customer surface. Resume, gating, and handoff read campaign state first. Start from user intake, create a watchable campaign shell with a v1 brief, update currentStep before major visible work, attach source/search state to that CampaignOffer, import the bounded review batch before post-import fit/message scouts, save rubrics and an approved message template, then queue the 10-row cascade and hand off to settings/sequence/start.",
+  "principle": "CampaignOffer state and the watch link are canonical from the first brief onward. Disk artifacts are optional debug/UAT diagnostics, not the normal customer surface. Resume, gating, and handoff read campaign state first. Start from user intake, create a watchable campaign shell with a v1 brief, update currentStep before major visible work, attach source/search state to that CampaignOffer, import the bounded review batch before post-import fit/message scouts, save rubrics and an approved message template, then queue the 15-row cascade and hand off to settings/sequence/start.",
   "artifactPolicy": {
     "normalCustomerPath": "Use CampaignOffer state, MCP responses, provider search state, and campaign table rows. Do not create, read, link, or surface local draft files unless debug/UAT mode is explicit or the user asks for them.",
     "debugArtifactsAreOptional": true,
@@ -725,11 +725,11 @@
             "approved brief and real sample leads",
             "no import or enrichment until rubrics and message set are ready",
             "parallel only if real parallel branches were launched",
-            "import the first 10-row review batch before fit/message work",
+            "import the first 15-row review batch before fit/message work",
             "selectedLeadListId stays the source list and workflowTableId is the campaign table"
           ],
           "timeEstimate": "~2-3 min",
-          "chatRenderRule": "Lead source is set. Next import and confirm only the first 10-row review batch into the campaign table. After workflowTableId exists, run the fit-filter and message-generation workstreams from the campaign table sample. If real parallel MCP/tool branches or host subagents were actually launched, say so; otherwise say the branches will run sequentially. Never claim parallelism unless parallel execution actually started."
+          "chatRenderRule": "Lead source is set. Next import and confirm only the first 15-row review batch into the campaign table. After workflowTableId exists, run the fit-filter and message-generation workstreams from the campaign table sample. If real parallel MCP/tool branches or host subagents were actually launched, say so; otherwise say the branches will run sequentially. Never claim parallelism unless parallel execution actually started."
         },
         {
           "action": "ask_continue_revise_or_confirm_only_if_needed",
@@ -808,7 +808,7 @@
     },
     {
       "id": "auto-execute-leads",
-      "label": "Step 13: Confirm source and import 10 lead review batch",
+      "label": "Step 13: Confirm source and import 15 lead review batch",
       "currentStepValue": "confirm-lead-list",
       "reference": "references/step-13-import-leads.md",
       "onEnter": [
@@ -848,7 +848,7 @@
             "campaignOfferId",
             "targetLeadCount"
           ],
-          "targetLeadCountFromConfig": "import.importLimit (10)",
+          "targetLeadCountFromConfig": "import.importLimit (15)",
           "onZeroLeads": "escalate_hard_fail",
           "modeAddHandshake": {
             "firstCallReturns": "needsModeSelection=true + existingLeadListId",
@@ -872,7 +872,7 @@
         },
         {
           "tool": "confirm_lead_list",
-          "targetLeadCountFromConfig": "import.importLimit (10)",
+          "targetLeadCountFromConfig": "import.importLimit (15)",
           "sourceBranches": [
             "normal-discovery",
             "supplied-domains",
@@ -896,7 +896,7 @@
           "tool": "get_rows_minimal",
           "purpose": "read_imported_review_batch_from_workflowTableId",
           "stripCarryData": true,
-          "sampleSizeFromConfig": "sample.sampleSize (10)"
+          "sampleSizeFromConfig": "sample.sampleSize (15)"
         },
         {
           "tool": "update_campaign",
@@ -999,7 +999,7 @@
               "ownership": "proof inventory, token strategy, angle drafting, skeptical-prospect review, and selected winner only"
             }
           ],
-          "earlyMessageStartRule": "After auto-execute-leads confirms the 10-row review batch and workflowTableId is ready, launch message-generation from brief.md, lead-review.md, lead-sample.json, and the imported campaign table sample. The message worker carries the campaign-launch message rules in its agent prompt; parent-thread fallback loads references/message-review-safety-gate.md. Legacy/resume preview prep still requires at least 5 probable good-fit rows. It may run beside filter-leads, but the cascade cannot queue until save_rubrics and update_campaign_brief both succeed.",
+          "earlyMessageStartRule": "After auto-execute-leads confirms the 15-row review batch and workflowTableId is ready, launch message-generation from brief.md, lead-review.md, lead-sample.json, and the imported campaign table sample. The message worker carries the campaign-launch message rules in its agent prompt; parent-thread fallback loads references/message-review-safety-gate.md. Legacy/resume preview prep still requires at least 3 probable good-fit rows. It may run beside filter-leads, but the cascade cannot queue until save_rubrics and update_campaign_brief both succeed.",
           "finalMessageReconcileRule": "message-validation.md may start before lead-filter.md exists, but before message-review it must cite only imported review-batch rows that still pass lead-filter.md. If the selected winner depends on a row later excluded by lead-filter.md, revise message-generation before message review.",
           "claudeRule": "In Claude Code, launch both returned post-find-leads scouts with Task/Agent subagents in the same assistant message only when the current session lists those agent names. Do not run filter first and then message generation unless subagents/background work are unavailable.",
           "codexRule": "In Codex, launch both returned post-find-leads scout names as disjoint subagents in the same assistant turn only when the host exposes those custom agents for this run. If the host cannot spawn them, run the same branches sequentially and say so.",
@@ -1879,7 +1879,7 @@
     },
     {
       "id": "validate-sample",
-      "label": "Step 14: Validate 10-lead test batch",
+      "label": "Step 14: Validate 15-lead test batch",
       "currentStepValue": "validate-sample",
       "reference": "references/sample-validation-loop.md",
       "counter": {
@@ -1895,13 +1895,13 @@
         },
         {
           "tool": "queue_cells",
-          "cellSource": "ten_lead_review_batch_after_rubrics_and_message_set",
-          "batchSize": 10,
+          "cellSource": "fifteen_lead_review_batch_after_rubrics_and_message_set",
+          "batchSize": 15,
           "requiredBeforeCall": [
             "rubrics_saved_to_campaign",
             "message_set_synced_to_brief"
           ],
-          "note": "Queue only the 10-lead review batch after rubrics are saved and the approved message set is in campaignBrief. This starts the workflow-table cascade for DNC Check -> ICP Score -> Passes Rubric -> Generate Message."
+          "note": "Queue only the 15-lead review batch after rubrics are saved and the approved message set is in campaignBrief. This starts the workflow-table cascade for DNC Check -> ICP Score -> Passes Rubric -> Generate Message."
         },
         {
           "tool": "wait_for_campaign_table_ready",
@@ -1911,7 +1911,7 @@
           "tool": "get_rows_minimal",
           "purpose": "read_passes_rubric_and_generate_message_status",
           "stripCarryData": true,
-          "sampleSizeFromConfig": "sample.sampleSize (10)"
+          "sampleSizeFromConfig": "sample.sampleSize (15)"
         },
         {
           "tool": "wait_for_rubric_results",
@@ -1922,7 +1922,7 @@
           "requiredValues": {
             "includeRows": false
           },
-          "note": "The shell-first flow tests 10 leads first; always pass cohortSize explicitly instead of relying on default 25 behavior.",
+          "note": "The shell-first flow tests 15 leads first; always pass cohortSize explicitly instead of relying on default 25 behavior.",
           "readVia": "stats_only_tool_result",
           "extractFields": [
             "ready",
@@ -2009,7 +2009,7 @@
     },
     {
       "id": "auto-execute-messaging",
-      "label": "Step 15: Complete messages for 10-lead test batch",
+      "label": "Step 15: Complete messages for 15-lead test batch",
       "currentStepValue": "auto-execute-messaging",
       "references": [
         "references/parallel-critique-protocol.md",

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 10-row review batch after source approval, save rubrics and the approved
+bounded 15-row 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/lead-validation-preview.md

@@ -47,7 +47,7 @@ Supplied-source preview:
 - `normal-discovery` is the default when the user does not already know the
   people/accounts.
 - `supplied-linkedin-profiles` uses `load_csv_linkedin_leads` before the
-  10-lead import batch only as preview/source attachment. Pre-import calls
+  15-lead import batch only as preview/source attachment. Pre-import calls
   must omit provider-import parameters. Use `campaignOfferId` only to attach the
   preview/list choice to the campaign UI.
 - `supplied-domains` uses `load_csv_domains` to create or reuse a

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

@@ -6,7 +6,7 @@ on every revision round.
 
 ## Principle
 
-We spend a bounded review batch (default 25 rows) to prove fit before the
+We spend a bounded review batch (default 15 rows) to prove fit before the
 user spends credits on hundreds more leads. The sample loop has one job:
 answer the question "do we have enough real passing examples for the user to
 judge this campaign?"
@@ -19,7 +19,7 @@ auto-revise leads.
 ## Inputs
 
 - `CampaignOffer.currentStep === "validate-sample"` (set at end of Step 13)
-- Imported review batch from Step 13 (size: `importLimit`, default 25)
+- Imported review batch from Step 13 (size: `importLimit`, default 15)
 - Config from `auto-execute.yaml`: `sample.sampleSize`,
   `sample.minProjectedPass`, `sample.maxRevisionRounds`
 - Persisted counter `revisionRound` (starts at 0 on first entry; persists
@@ -51,7 +51,7 @@ auto-revise leads.
 6. wait_for_rubric_results(sample, targetCount = <cohortSize>)
    - cohortSize = stats.totalRows of the enrichment batch, or the
      imported batch count
-   - default targetCount=25 matches the default review batch, but pass the
+   - default targetCount=15 matches the default review batch, but pass the
      explicit batch count anyway so future larger expansion batches do not
      accidentally stop early
      (see §Known Tool Behaviors #3)
@@ -161,8 +161,8 @@ company, enrichCellId, enrichStatus) over the default shape.
 
 ### 5. `wait_for_rubric_results` can timeout with enough signal to decide
 
-Observed: a 10-row review batch may return `ready=false`, `reason="timeout"`,
-and partial stats such as 9/10 scored, 2 passing, 2 messages generated. That is
+Observed: a 15-row review batch may return `ready=false`, `reason="timeout"`,
+and partial stats such as 13/15 scored, 2 passing, 2 messages generated. That is
 enough to diagnose an underperforming sample. Waiting again without active
 processing makes the experience feel frozen.
 
@@ -178,16 +178,16 @@ or wait once only if active processing is still visible.
 projectedPass = round(passInSample / sampleSize * importLimit)
 ```
 
-Worked examples with defaults (sampleSize=25, importLimit=25):
+Worked examples with defaults (sampleSize=15, importLimit=15):
 
-| passInSample | projectedPass | Handoff? (minProjectedPass=5) |
+| passInSample | projectedPass | Handoff? (minProjectedPass=3) |
 | ------------ | ------------- | ----------------------------- |
 | 0            | 0             | No — escalate or revise       |
-| 4            | 4             | No — escalate or revise       |
-| 5            | 5             | Yes — exactly at floor        |
+| 2            | 2             | No — escalate or revise       |
+| 3            | 3             | Yes — exactly at floor        |
+| 4            | 4             | Yes                           |
 | 10           | 10            | Yes                           |
 | 15           | 15            | Yes                           |
-| 25           | 25            | Yes                           |
 
 When non-default importLimit/sampleSize are configured, the math scales
 the same way. In the default review-batch mode, the sample size equals the
@@ -251,8 +251,8 @@ rate is zero with no pattern that brief editing could fix.
 
 Signal examples:
 
-- 10/10 rows are wrong function / wrong seniority / wrong geo.
-- 8/10 rows enrich to empty strings for the tokens the brief needs.
+- 15/15 rows are wrong function / wrong seniority / wrong geo.
+- 12/15 rows enrich to empty strings for the tokens the brief needs.
 - Rubric passes 0 rows and the failure reasons are all "not ICP."
 - **Marketplace supply-side contamination:** >20% of sample rows match
   the brief §14 forbidden side (e.g. Skillsync sample contains

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

@@ -95,7 +95,7 @@ Default case — no existing lead list bound to the campaign:
 ```text
 import_leads({
   campaignOfferId,
-  targetLeadCount: <importLimit from auto-execute.yaml; default 10>
+  targetLeadCount: <importLimit from auto-execute.yaml; default 15>
 })
 ```
 

package/skills/create-campaign-v2/references/watch-link-handoff.md

@@ -69,7 +69,7 @@ orient the user after a meaningful step change:
 - source selected: the campaign should point at the primary provider step
 - rubrics saved: the campaign should show filter/rubric state
 - message set approved: the campaign should show message state
-- 10-lead test batch imported/generated: the campaign should show the test rows
+- 15-lead test batch imported/generated: the campaign should show the test rows
 - settings handoff: the campaign should open to Settings for sender attachment
 - running: the campaign is live