@sellable/mcp 0.1.116 → 0.1.117

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -165,47 +165,31 @@ linked skill versions, runbooks, npm/package details, repo-local files, VPS or
 browser automation limitations, or local skill files in normal customer-facing
 copy.
 
-## Watch Link Handoff
-
-When a campaign tool returns `watchUrl`, treat it as a user-opened watch link.
-A valid handoff link must be a safe direct
-`/campaign-builder/{campaignId}?mode=claude|codex|watch` URL.
-`create_campaign.watchUrl`, `create_campaign({ campaignId }).watchUrl`, and
-`get_campaign.watchUrl` are all acceptable only when they return that direct
-campaign-builder shape, with `workspaceId` used only as a safe routing hint when
-needed.
-
-Do not claim Sellable can force every host to open links in a specific browser.
-The host controls link-click behavior. Do not call Chrome, browser automation,
-shell `open`, Computer Use, or in-app browser-control tools just because a
-watch link exists.
-
-- In Codex Desktop, clicking a URL can open the Codex in-app browser, but that
-  browser is only reliable for unauthenticated/public pages. Sellable campaign
-  watch pages may need a signed-in session. Tell the user to click the link
-  first; if it lands on sign-up/auth, they should open the same link in their
-  regular browser to watch real-time updates.
-- In Claude Code, provide the link and direct the user to open it in their
-  browser. If their Claude Code setup opens links in an in-app/preview browser,
-  that is fine, but do not attempt to open Chrome for them.
-
-Make the direct watch link easy to copy/open, then continue with explicit
-customer-facing campaign progress and `get_campaign_navigation_state`
-orientation checks. Use this fallback shape:
+## Codex Watch Link Handoff
+
+When a campaign tool returns `watchUrl`, treat it as a user-opened app link, not
+as permission to drive the browser. A valid handoff link must be a direct
+`/campaign-builder/{campaignId}?mode=claude|codex` URL with the auth token and
+workspace routing needed for auto-login. `create_campaign.watchUrl`,
+`create_campaign({ campaignId }).watchUrl`, and `get_campaign.watchUrl` are all
+acceptable only when they return that direct campaign-builder shape.
+
+Never call browser-opening tools, shell `open`, Computer Use, or in-app browser
+automation just because a watch link exists. Print the link and tell the user to
+Command-Enter/click it when they want to watch in the app. Use this shape:
 
 ```text
-Watch link: [Open campaign]({watchUrl})
+Watch link: {watchUrl}
 
-Click that link to watch the campaign. If it opens in an in-app browser and asks
-you to sign in, open the same link in your regular browser so you can watch
-real-time updates from your signed-in session. I’ll keep the brief, lead source,
-and message-review steps explicit here as I build.
+Command-Enter or click that link to watch the campaign in Sellable. I’ll keep
+the brief, lead source, and message-review steps explicit here as I build.
 ```
 
-If the user reports that the watch link lands on auth, 404, permission, blank,
-or an error state, recover a fresh watch link once with
-`create_campaign({ campaignId })` or `get_campaign`, then print the recovered
-link. Do not claim the browser was opened, inspected, or synchronized.
+The watch link should auto-login through the token in the URL. If the user says
+the link lands on auth, 404, permission, blank, or a visible error state, recover
+a fresh watch link once with `create_campaign({ campaignId })` or `get_campaign`
+and print that link. Do not claim the browser was opened, inspected, or
+synchronized.
 
 Never print a placeholder watch link such as "Open campaign" or "link will
 update once the shell is created." If the shell is not created yet, call
@@ -214,7 +198,7 @@ and surface the missing watch-link error before lead sourcing.
 
 After every `update_campaign({ campaignId, currentStep })`, use
 `get_campaign_navigation_state` when available as a compact orientation check:
-match the expected watch-link step to the saved campaign state, explain the
+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 10-row validation. After message
 validation, use Settings to help the user connect or select a LinkedIn sender.

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

@@ -437,9 +437,10 @@ brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
 
 - After the brief is approved, show the next progress line:
   `Cool. Now I'm going to find people who are both a good fit and active enough
-to be worth a LinkedIn test. I'll compare source paths by expected volume,
-sampled ICP fit, activity/warmth signal, cleanup risk, and tradeoffs. This
-will end with a source decision + sample before anything goes live.`
+to be worth a LinkedIn test. I see two promising source paths: {source path 1}
+and {source path 2}. I'll launch background source checks for both so we can
+confirm which one is viable before I show results. No leads import until you
+approve the source.`
 - In watch mode, do not leave the user sitting on only `pick-provider` while
   source scouts run. Move the campaign to the likely primary source lane
   (`signal-discovery`, `sales-nav`, or `prospeo`) before background source
@@ -450,8 +451,9 @@ will end with a 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 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.`
+campaign table, then add fit filters and draft the first message from that same
+sample. You can inspect filters once they are saved, but enrichment and message
+checks wait until the message draft is ready and approved.`
 - During long post-intake work, show concise progress checkpoints before the
   next expensive stage: source being checked, source switch/tradeoff if any,
   lead sample usable, filter/message drafting, and message-review rule loading.
@@ -1006,6 +1008,25 @@ The first sentence of the visible decision must make the actual choice clear:
 is {source} because {reason}.` Do not make the user infer the decision from
 numbers alone.
 
+Before asking for lead-source approval, make the watched campaign show the
+recommended primary source lane. Call
+`update_campaign({ campaignId, leadSourceType: "new", leadSourceProvider,
+currentStep, watchNarration })` with `currentStep` set to the provider lane
+being recommended (`sales-nav`, `signal-discovery`, or `prospeo`). If the last
+sampled lane was Signals but the recommendation is Sales Nav, switch the
+watched provider page to Sales Nav before asking the question so the user can
+see what they are approving and why. No leads import until the user approves.
+
+After the user approves a lead source, the approved provider must remain the
+active watched provider before any materialization work starts. Immediately
+call `update_campaign` again if needed with the approved `leadSourceProvider`
+and matching `currentStep` before `lookup_sales_nav_filter`,
+`get_provider_prompt`, `search_sales_nav`, `search_prospeo`, `import_leads`, or
+`confirm_lead_list`. For example, if the user approves Sales Nav while the
+browser is still showing Signal Discovery, set `leadSourceProvider: "sales-nav"`
+and `currentStep: "sales-nav"` first so the browser switches to the Sales Nav
+lane and the user can watch the approved source progress.
+
 If you ask for lead-source approval, the question and choices must name the
 source decision. Prefer `Approve Sales Nav with founder/CEO filters, or use
 warmer Signals posts instead?` over `Approve this lead source?`. Option labels

package/skills/create-campaign-v2/core/flow.v2.json

@@ -522,7 +522,7 @@
             "watchNarration.stage": "find-leads"
           },
           "when": "before_source_scouts_or_provider_search",
-          "chatRenderRule": "Move the campaign watch view to Find Leads before the main thread starts comparing source paths. The watchNarration headline/body must name the likely provider or lane being tested and why it fits this campaign. Do not mention MCP or local artifacts."
+          "chatRenderRule": "Move the campaign watch view to Find Leads before the main thread starts comparing source paths. In chat, name the two promising source paths the agent thinks may work, say it is launching background source checks/agents to confirm viability before showing results, and state that no leads import until a source is approved. The watchNarration headline/body must name the likely provider or lane being tested and why it fits this campaign. Do not mention MCP or local artifacts."
         },
         {
           "action": "advance_watch_to_initial_source_lane",
@@ -745,7 +745,7 @@
           "artifactLinkTiming": "before_next_step_or_revision_question",
           "doNotCompressToSummaryOnly": false,
           "doNotRenderArtifactLinksOnly": true,
-          "sourceRecommendationReadyWatchRule": "When the source recommendation decision card is ready in chat with counts and sample quality, update watchNarration to a find-leads chat-handoff frame. Use a headline like `Review the source in Codex`, body copy that says the browser is showing the evaluated source/results, and nextAction like `Approve in Codex`. Do not keep future-tense copy like `I'll show a source recommendation` after the decision is visible. Include a safety note that no leads import until the user approves the source.",
+          "sourceRecommendationReadyWatchRule": "When the source recommendation decision card is ready in chat with counts and sample quality, and before asking for source approval, call update_campaign with leadSourceType `new`, leadSourceProvider set to the recommended primary provider, currentStep set to that provider lane (`sales-nav`, `signal-discovery`, or `prospeo`), and find-leads watchNarration. If the recommendation changed from the lane last sampled, switch the watched provider page to the recommended lane first so the user can inspect what they are approving. Use a headline like `Review the source in Codex`, body copy that says the browser is showing the evaluated source/results, and nextAction like `Approve in Codex`. Do not keep future-tense copy like `I'll show a source recommendation` after the decision is visible. Include a safety note that no leads import until the user approves the source.",
           "chatRenderRule": "Show a slim rendered-Markdown decision summary only, never a fenced code block. The first sentence must make the decision explicit: 'I recommend {primary source} using {exact filter/source recipe}. The runner-up is {source} because {reason}.' Use indexed sections and short bullets: recommendation, Primary source and filters, Runner-up sources, why it won, Quick numbers with one provider/source angle per bullet, raw volume, sampled fit count as n/N only (no percentages), estimated good-fit range after cleanup, activity/warmth basis, confidence note, 3-5 representative sample leads, and one tradeoff. Do not forecast connection acceptance rates, reply rates, meetings, pipeline, revenue, or ROI unless the user supplied verified benchmark data for this exact workspace/sender. If Signals was searched or considered, include two compact inline Markdown tables before the recommendation is treated as final: Signal keyword lanes with keyword lane, timeframe, posts found, and finalist posts reviewed; and LinkedIn posts sampled with post URL/title, author/topic, age, engagers, sampled engagers, good fits as n/N only, estimated usable prospects per post, and use/discard decision. Default to selecting a few promising Signals posts for the first sample instead of trying to prove full Signals scale up front; if the sample is good but volume is low, say how many more posts to add/scrape next. Do not skip or discard Signals based only on raw post count or vibes; show the post-level math first, or explicitly say no engagers could be fetched and lower confidence. Keep discarded paths, full sample rows, and lead-sample.json details in lead-review.md. Do not show plain filesystem paths unless links cannot be created."
         },
         {
@@ -796,6 +796,7 @@
             "watchNarration: find-leads source recommendation ready, or review-batch import starting when source approval already happened",
             "selectedLeadListId as source list id only for existing-list or supplied-list preview"
           ],
+          "sourceApprovalWatchRule": "Immediately after the user approves a source, and before lookup_sales_nav_filter, get_provider_prompt, search_sales_nav, search_prospeo, import_leads, or confirm_lead_list, persist the approved source as the active provider on the CampaignOffer. For Sales Nav approval, call update_campaign with leadSourceType `new`, leadSourceProvider `sales-nav`, currentStep `sales-nav`, and current-tense watchNarration so the browser switches off the previous Signal Discovery lane and the user can continue watching the approved provider setup. Apply the same rule for signal-discovery and prospeo approvals.",
           "fallback": "Stop if campaignId is missing; the source must be attached to the existing CampaignOffer before import.",
           "readsCampaignStateFirst": true
         }
@@ -875,7 +876,7 @@
         },
         {
           "action": "watch_mode_orient",
-          "watchNarrationRule": "Before import_leads or confirm_lead_list starts, align the guide with chat by setting review-batch watchNarration to current-tense import copy. Use a headline like `Importing the review batch`; explain that the browser may still show the approved source leads while Codex imports only the bounded 15-row review batch; include a no-launch safety note."
+          "watchNarrationRule": "Before import_leads or confirm_lead_list starts, align the guide with chat by setting review-batch watchNarration to current-tense import copy. Also persist the approved source provider/currentStep first: Sales Nav approval must set leadSourceProvider `sales-nav` and currentStep `sales-nav`, Signals approval must set `signal-discovery`, and Prospeo approval must set `prospeo`. Use a headline like `Importing the review batch`; explain that the browser is on the approved source lane while Codex imports only the bounded 15-row review batch; include a no-launch safety note."
         },
         {
           "tool": "import_leads",
@@ -943,8 +944,10 @@
           ],
           "requiredValues": {
             "currentStep": "filter-choice",
-            "watchNarration.stage": "fit-message"
-          }
+            "watchNarration.stage": "fit-message",
+            "watchNarration.headline": "Added to Campaign"
+          },
+          "watchNarrationRule": "After the bounded review batch is present, update the watched guide to `Added to Campaign`. Say Codex is adding fit filters so every send stays qualified while drafting the first message in the background. This persists add-filters intent by currentStep/watchNarration only; do not set enableICPFilters=true until save_rubrics succeeds with active criteria. Nothing enriches, validates, or sends until the first message is ready and approved."
         }
       ],
       "allowedTools": [

package/skills/create-campaign-v2/references/watch-guide-narration.md

@@ -134,6 +134,27 @@ current-tense import copy. Do not leave the guide in source-approved or
 future-tense copy such as `I'll show the review-batch outcome`; that makes the
 browser guide describe a different moment than chat.
 
+After review batch import:
+
+```json
+{
+  "stage": "fit-message",
+  "headline": "Added to Campaign",
+  "visibleState": "The first review batch is in the campaign.",
+  "agentIntent": "Codex is adding fit filters to keep every send qualified while drafting the first message in the background.",
+  "nextAction": "Review fit rules and message",
+  "safety": "Nothing enriches, validates, or sends until the message is ready and approved.",
+  "workerStatuses": {
+    "leadFitBuilder": "running",
+    "messageDraftBuilder": "running"
+  }
+}
+```
+
+Use this after the selected review rows are present and before filters are
+saved. This is add-filters intent, not active filtering. `enableICPFilters`
+only becomes true after active filter criteria are saved.
+
 Fit + message:
 
 ```json

package/skills/research/config.json

@@ -0,0 +1,9 @@
+{
+  "parallelMode": "wide",
+  "agentCount": 6,
+  "maxToolCallsPerAgent": 2,
+  "senderMaxAgents": 2,
+  "senderMaxToolCallsPerAgent": 3,
+  "progressMode": true,
+  "debugMode": true
+}