@sellable/mcp 0.1.88 → 0.1.90

package/dist/tools/leads.js

@@ -2350,7 +2350,7 @@ export async function selectPromisingPosts(input) {
         selectedCount: selectionResult.selectedCount,
         unselectedCount: selectionResult.unselectedCount,
         criteriaCount: selectionResult.criteriaCount,
-        message: `Selected ${selectionResult.selectedCount} posts with ${selectionResult.criteriaCount} ICP criteria (persisted). Ask the user to confirm, then call import_leads with provider: "signal-discovery". Criteria are already saved to the campaign.`,
+        message: `Selected ${selectionResult.selectedCount} posts with ${selectionResult.criteriaCount} ICP criteria (persisted). Criteria are already saved to the campaign. If the user has already approved the lead-source decision for create-campaign-v2, call import_leads with provider: "signal-discovery", confirmed: true, and the approved bounded targetLeadCount. Otherwise ask the user to confirm before importing.`,
     };
 }
 export async function setHeadlineICPCriteria(input) {

package/package.json

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

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

@@ -616,6 +616,12 @@ claims as setup proof options unless the user supplied verified benchmark data
 for this exact workspace/sender. If such claims appear in research, label them
 as unavailable/unsupported and use founder/operator credibility, product
 capability, or verified customer proof instead.
+This is a hard guardrail for both option labels and option descriptions: never
+write setup proof option text with numeric outcome language such as `25% reply`,
+`25%-reply`, `reply-rate`, `meeting-rate`, `pipeline`, `revenue`, or `ROI`
+unless that exact benchmark is verified for this workspace/sender. If a profile
+or case study contains that language, strip the number and convert the option to
+non-quantified founder/operator credibility or product capability.
 
 Ask the lead-source question as the last question in the first strategy
 batch, after buyer, offer/ask, and proof/safety are understood. Frame supplied

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

@@ -218,6 +218,9 @@ campaignOfferId, confirmed: true })` -> `search_signals({ campaignOfferId,
 selectionMode: "replace", selections, headlineICPCriteria })` ->
      `import_leads({ campaignOfferId, provider: "signal-discovery",
 targetLeadCount: importLimit })`.
+     Source approval is the explicit confirmation for this bounded review
+     batch; do not ask for a second yes/no gate between
+     `select_promising_posts` and `import_leads`.
    - Sales Nav: `get_provider_prompt({ provider: "sales-nav", campaignOfferId,
 confirmed: true })` -> rebuild/verify filter IDs -> `search_sales_nav({
 campaignOfferId, filters, confirmed: true })` -> `import_leads({

package/skills/providers/signal-discovery.md

@@ -364,8 +364,18 @@ set_headline_icp_criteria({
 ### import_leads
 
 Start scraping and populate a lead list. **Only call after explicit user confirmation.**
-Never call `import_leads` in the same turn as `select_promising_posts`.
-Ask a clear yes/no question and wait for the user to say **yes**.
+For standalone Signal Discovery use, never call `import_leads` in the same turn
+as `select_promising_posts`; ask a clear yes/no question and wait for the user
+to say **yes**.
+
+For `create-campaign-v2` after the user has already approved the lead-source
+decision, that approval is the explicit confirmation for the bounded review
+batch. In that tail flow, follow `create-campaign-v2-tail`: call
+`select_promising_posts({ campaignOfferId, selectionMode: "replace",
+selections, headlineICPCriteria })`, then call
+`import_leads({ campaignOfferId, provider: "signal-discovery",
+targetLeadCount })` for the approved review batch without asking for another
+yes/no gate. Do not import more than the approved bounded batch.
 
 ```json
 import_leads({
@@ -407,9 +417,15 @@ Then run post-confirm routing in this order:
    - Recency (≤6 weeks = active LinkedIn users who will see outreach)
    - **Include 3-5 headline filtering criteria**
 4. If you are estimating whether Signals is viable before import, fetch engagers for 1-3 promising posts and compute a sampled headline pass rate before estimating reachable leads.
-5. Ask for explicit confirmation to import leads (e.g., "Does this look right? Should I import leads now?")
-6. If user confirms, call `import_leads`. If not, refine selections/criteria and ask again.
-7. When the lead list finishes and the user confirms it looks good, call `confirm_lead_list`.
+5. Standalone Signal Discovery flow: ask for explicit confirmation to import
+   leads (e.g., "Does this look right? Should I import leads now?").
+   `create-campaign-v2` tail flow: if the user already approved the source
+   decision, that approval is the import confirmation for the bounded review
+   batch; do not ask again.
+6. If confirmation exists, call `import_leads`. If not, refine
+   selections/criteria and ask again.
+7. When the lead list finishes and the user confirms it looks good, call
+   `confirm_lead_list`.
    </search_flow>
 
 <selection_rules>
@@ -490,6 +506,8 @@ select_promising_posts({
 1. Search signals (Round 1) → Get raw post data
 2. (Optional) Search signals (Round 2) → More keywords, more posts
 3. Select `selectionTarget` promising posts with headlineICPCriteria
-4. Ask the user to confirm before importing leads
-5. If user confirms, call `import_leads`
+4. Standalone flow: ask the user to confirm before importing leads.
+   `create-campaign-v2` after source approval: continue without a second
+   import confirmation gate.
+5. If confirmation exists, call `import_leads`
    </correct_flow>