@sellable/mcp 0.1.153 → 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
@@ -458,6 +463,32 @@ required field is missing, the supplied inputs conflict, or the campaign focus i
 genuinely ambiguous. It is fine to include an explicit assumption line in the
 brief; the approval gate lets the user revise it.
 
+### YOLO Mode
+
+If the invocation or any later user message explicitly asks for "yolo mode",
+"YOLO", `--yolo`, `mode=yolo`, "autopilot", "use best guesses", "answer for
+me", "use best estimates", or "just run it", enable YOLO mode for the rest of
+the run. Treat YOLO as `interactionMode: "autonomous"` plus an intake policy:
+
+- If campaign identity is missing, ask only for the LinkedIn profile or company
+  website in normal chat; do not ask buyer, offer, proof, source, or filter setup
+  questions before that.
+- Treat any freeform directions already provided, or added later by the user, as
+  operator directions for the rest of the run. If directions conflict, the newest
+  user direction wins.
+- After the lightweight identity/company lookup, infer the buyer segment,
+  offer/CTA, proof to use or avoid, first lead source, filter choice, and message
+  direction with best estimates from public/company context plus operator
+  directions. State the important assumptions in the brief and watch narration.
+- Do not use structured setup questions in YOLO mode. For pre-launch approval
+  gates, choose the recommended path yourself when confidence is sufficient, show
+  the assumed choice briefly, and continue.
+- Pause only when no reasonable estimate exists, a tool requires missing
+  credentials/data, the source/message quality floor fails, or the next action
+  would start the live campaign.
+- Never call `start_campaign` from YOLO mode without explicit user launch
+  confirmation. Do not invent proof; mark proof gaps and use safer claims.
+
 Before the identity gate, use this customer-facing shape:
 
 ```text
@@ -651,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 })`
@@ -665,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
@@ -674,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,13 +76,25 @@ 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,
 use the available Sellable profile/company/post tools and carry explicit proof
 gaps into the brief.
 
+## YOLO Mode
+
+Enable YOLO mode when the user asks for yolo/autopilot, passes `--yolo` or
+`mode=yolo`, or says to use best guesses/estimates and answer for them. Ask only
+for the LinkedIn profile or company website if identity is missing. After the
+identity lookup, infer buyer, offer/CTA, proof, source, filters, and message
+direction from company evidence plus user directions; newest directions win.
+Set `interactionMode: "autonomous"` once `campaignId` exists. Auto-select
+pre-launch choices when confidence is sufficient, but show the assumed choice
+briefly. Pause for missing credentials/data, failed quality floors, or final
+launch. Never call `start_campaign` without explicit launch confirmation.
+
 ## Structured Questions
 
 Use the host-native structured question gate (`request_user_input` or
@@ -166,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.
@@ -209,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, copy all confirmed source rows into the
-campaign, then process only the first 15 rows so we can inspect quality 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 so filters and generated copy are configured 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.
 ```
@@ -246,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
@@ -259,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
@@ -293,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
@@ -302,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
@@ -318,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.