@sellable/mcp 0.1.121 → 0.1.123

package/agents/source-scout-linkedin-engagement.md

@@ -26,26 +26,36 @@ Use the inherited Sellable MCP tools when available:
 Process:
 
 1. Read the campaign brief, kickoff doc, or lane prompt supplied by the parent.
-2. Search 3-5 keyword/topic lanes, favoring fresh posts from the last 7-14 days.
+2. Generate 3-5 intersection keyword/topic lanes, favoring fresh posts from the
+   last 7-14 days. Each lane should combine the campaign anchor with the buyer
+   pain, use case, or ICP role so fit is high before sampling. For example, for
+   a Claude + GTM/outbound campaign, prefer `Claude outbound`, `Claude Code
+LinkedIn outreach`, `AI SDR Claude`, `GTM automation Claude`, and `founder-led
+sales Claude`; do not treat broad anchor-only lanes like `Claude Code`, `MCP`,
+   `AI agents`, or `agentic coding` as selectable unless they also include the
+   GTM/outbound wedge or the narrower lanes fail.
 3. Inspect finalist posts by content type before final selection. Prefer posts
    where the topic matches the campaign wedge, not generic high-engagement news.
-4. Promote the first narrow sample set when campaign-attached. If a
+4. If Round 1 produced broad anchor-only inventory, retarget immediately around
+   the wedge before sampling. Do not promote or sample broad posts when there are
+   narrower posts about the actual campaign pain/use case.
+5. Promote the first narrow sample set when campaign-attached. If a
    `campaignOfferId` was supplied, call `select_promising_posts({
 campaignOfferId, selectionMode: "replace", selections, headlineICPCriteria,
 currentStep: "signal-discovery" })` before sampling so the watched Signal
    Discovery table shows the exact posts being tested.
-5. Fetch or sample engagers for promoted posts and score rough ICP fit from
+6. Fetch or sample engagers for promoted posts and score rough ICP fit from
    visible headline/display-name cues only. Do not enrich people during
    viability estimation.
-6. Compute capacity before recommending the source: target good-fit leads
+7. Compute capacity before recommending the source: target good-fit leads
    (default 500 unless the parent supplies a target), reachable engagers,
    sampled ICP-fit rate as `n/N` plus an easy percentage/range, expected usable
    leads per right-content post after dedupe/cleanup, and posts needed to hit
    the target.
-7. Select/promote enough right-content posts to plausibly hit the target. If the
+8. Select/promote enough right-content posts to plausibly hit the target. If the
    warm Signals pool is useful but too small, return the expected warm range and
    recommend Sales Nav/Prospeo for scale instead of padding with noisy posts.
-8. Return false positives and dead ends explicitly.
+9. Return false positives and dead ends explicitly.
 
 Return a concise structured result with:
 
@@ -67,6 +77,10 @@ Evidence standards:
 
 - Do not trust raw post volume without inspecting finalist post quality.
 - Prefer sample-based pass rates over intuition.
+- Prefer narrow intersection topics over broad audience topics. A post about
+  the anchor technology alone is not enough; the post should also express the
+  GTM/outbound/buyer pain, workflow, or role context that makes the campaign
+  relevant.
 - Do not make the user infer capacity. Say, plainly, how many eligible posts
   exist, what percent of sampled engagers looked in-ICP, how many posts are
   needed for 500+ good-fit leads, and which posts you would use.

package/package.json

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

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

@@ -433,7 +433,10 @@ brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
   campaign brief. Do not wait for file-write chrome before asking for approval.
   Before Find Leads, call `update_campaign({ campaignId, campaignBrief,
   currentStep: "pick-provider", watchNarration: { ... } })` after approval so
-  the watch link moves out of Plan while the main thread compares source paths.
+  the watch link moves out of Plan while the main thread explains the source
+  path. This must be a visible Pick Provider checkpoint before the watched
+  browser moves into Signal Discovery, Sales Nav, Prospeo, or another provider
+  lane.
 
 - After the brief is approved, show the next progress line. When the user has
   not given a specific source direction, use the default sequential source
@@ -444,6 +447,11 @@ that gives the strongest message context if enough ICP-looking people are
 engaging. If that does not clear a quick viability check, I'll switch to Sales
 Nav with recent activity, then broader Sales Nav, and use Prospeo only as the
 fallback. No leads import until you approve the source.`
+  The watched campaign should still be on Pick Provider while this source logic
+  is being explained. If the default first lane is Signal Discovery, say clearly
+  that Codex is about to test Signal Discovery as a viability path, not import
+  leads: it will look for relevant posts, sample engagers, estimate ICP fit, and
+  only continue if the source math works.
 - If the user's request already points to a source, do not force the default
   funnel. Start with the matching lane and say why:
   - specific posts, creators, topics, comments, or engagement signals ->
@@ -453,8 +461,9 @@ fallback. No leads import until you approve the source.`
     search, or target accounts -> Prospeo
   - supplied CSV/profile list -> existing/supplied list preview
   - explicit compare request -> compare only the requested sources
-- In watch mode, do not leave the user sitting on only `pick-provider` while
-  source viability is checked. Move the campaign to the first source lane that
+- In watch mode, do not skip the Pick Provider checkpoint. First move the
+  campaign to `pick-provider` and narrate the source-selection reasoning there.
+  After that visible checkpoint, move the campaign to the first source lane that
   will actually be tested (`signal-discovery`, `sales-nav`, `prospeo`, or the
   user-directed lane), then run the campaign-attached provider prompt + provider
   search in the parent thread with `campaignOfferId`, `confirmed: true`, and
@@ -807,8 +816,9 @@ Required behavior:
   then stop on the first viable source unless the user asked to compare.
   1. Start with LinkedIn Engagement / active LinkedIn posts (internal provider:
      Signals / `signal-discovery`) because recent engagement gives the strongest
-     message context and expected reply-rate upside. Search relevant keyword
-     lanes, review finalist posts, promote a narrow sample set with
+     message context and expected reply-rate upside. Search intersection keyword
+     lanes that combine the campaign anchor with the buyer pain/use case/ICP
+     role, review finalist posts, promote a narrow sample set with
      `select_promising_posts` before fetching engagers when a campaign shell
      exists, fetch top-post engagers, estimate ICP-fit rate, compute posts
      needed for the target good-fit lead count, and only then recommend the
@@ -859,6 +869,13 @@ Required behavior:
   keyword lanes; it does not mean 492 prospects. The source decision must name
   the actual posts we would use, show why they won, and estimate usable engagers
   from those posts after headline/sample filtering
+- for Signals-first campaigns, keyword lanes must be intersection-first. If the
+  campaign anchor is `Claude`, `MCP`, `AI agents`, or another broad technology,
+  do not make broad anchor-only lanes the main test. Combine the anchor with the
+  specific wedge and buyer pain, such as outbound, GTM automation, LinkedIn
+  outreach, AI SDR skepticism, founder-led sales, RevOps, or the ICP role. Treat
+  broad anchor-only lanes as fallback inventory only, and retarget before
+  sampling if the first pass is broad.
 - Signals viability is based on estimated ICP-fit reachable engagers, not raw
   post count and not whether it beats Sales Nav scale. If 5-8 selected posts can
   plausibly produce ~150+ ICP-fit warm prospects before final filtering, keep

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

@@ -546,7 +546,9 @@
             "watchNarration.stage": "find-leads"
           },
           "when": "before_sequential_source_funnel",
-          "chatRenderRule": "Move the campaign watch view to Find Leads before the main thread starts source viability work. If the user did not specify a source, explain the default order: start with warm LinkedIn post engagement because it gives stronger message context and expected reply-rate upside when enough ICP-looking engagers exist; if it is not viable, switch to Sales Nav with recent activity, then broader Sales Nav, and use Prospeo only as the fallback. If the user did specify hiring signals, domains/accounts, supplied lists, posts/comments, or titles/personas, explain that the matching source overrides the default funnel. State that no leads import until a source is approved. The watchNarration headline/body must name the lane being tested, why this lane now, the quick viability gate, and the safety boundary. Do not mention MCP or local artifacts."
+          "requiresVisibleCheckpointBeforeProviderLane": true,
+          "forbidDirectPlanToProviderLane": true,
+          "chatRenderRule": "Move the campaign watch view to the Pick Provider step before the main thread starts source viability work. This must be a distinct visible checkpoint: do not jump directly from Plan to Signal Discovery, Sales Nav, Prospeo, or another provider lane in the same visible beat. While the watched browser is on Pick Provider, explain the source-selection logic. If the user did not specify a source, explain the default order: start with warm LinkedIn post engagement because it gives stronger message context and expected reply-rate upside when enough ICP-looking engagers exist; if it is not viable, switch to Sales Nav with recent activity, then broader Sales Nav, and use Prospeo only as the fallback. If starting with Signal Discovery, explicitly say this is a viability test: Codex will look for relevant posts, sample engagers, estimate ICP fit, and only continue if the source math works. If the user did specify hiring signals, domains/accounts, supplied lists, posts/comments, or titles/personas, explain that the matching source overrides the default funnel. State that no leads import until a source is approved. The watchNarration headline/body must name the first lane being considered, why this lane now, the quick viability gate, and the safety boundary. Do not mention MCP or local artifacts."
         },
         {
           "action": "advance_watch_to_initial_source_lane",
@@ -564,8 +566,9 @@
             "existingList": "saved-lists",
             "uploadedDomains": "prospeo"
           },
-          "when": "before_first_source_attempt",
-          "rule": "Choose the first visible source lane from explicit source direction when present, otherwise default to Signal Discovery. Send watchNarration with stage find-leads that says why this lane is being tried now, what quick sample or filter gate will pass/fail it, and why that helps this campaign. For Signal Discovery sampling, promote/select the first narrow sample posts with select_promising_posts before fetch_post_engagers so the watched table shows the exact posts being sampled; the guide copy should say Codex is pulling sample engagers from these posts to confirm the ICP is actually engaging and estimate whether enough right-content posts exist for the target lead count. Before final source approval, compute eligible posts, sampled ICP-fit rate, target good-fit lead count, posts needed, selected posts, expected good-fit range, and scale fallback. If the lane fails, update currentStep and watchNarration before moving to Sales Nav recent activity, normal Sales Nav, or Prospeo."
+          "when": "after_source_selection_checkpoint_before_first_source_attempt",
+          "requiresPriorVisibleStep": "pick-provider",
+          "rule": "Choose the first visible source lane from explicit source direction when present, otherwise default to Signal Discovery. Only run this after the Pick Provider source-selection checkpoint has been made visible and explained in chat/watchNarration. Send watchNarration with stage find-leads that says why this lane is being tried now, what quick sample or filter gate will pass/fail it, and why that helps this campaign. For Signal Discovery sampling, make it clear this is a viability path before lead import: generate intersection-first keyword lanes that combine the campaign anchor with the buyer pain/use case/ICP role, not broad anchor-only lanes. For Claude/GTM campaigns, prefer lanes like Claude outbound, Claude Code LinkedIn outreach, AI SDR Claude, GTM automation Claude, and founder-led sales Claude over generic Claude Code, MCP, AI agents, or agentic coding. If the first pass is broad, retarget around the campaign wedge before selecting posts. Promote/select the first narrow sample posts with select_promising_posts before fetch_post_engagers so the watched table shows the exact posts being sampled; the guide copy should say Codex is pulling sample engagers from these posts to confirm the ICP is actually engaging and estimate whether enough right-content posts exist for the target lead count. Before final source approval, compute eligible posts, sampled ICP-fit rate, target good-fit lead count, posts needed, selected posts, expected good-fit range, and scale fallback. If the lane fails, update currentStep and watchNarration before moving to Sales Nav recent activity, normal Sales Nav, or Prospeo."
         },
         {
           "action": "run_first_campaign_attached_source_search",
@@ -614,7 +617,7 @@
           "action": "run_subskill",
           "target": "find-leads",
           "mode": "campaign-attached-required",
-          "sourceScoutRule": "Shell-first flow requires the CampaignOffer campaignId from durable state. Pass campaignId as campaignOfferId into every provider prompt/search that can persist source state (`get_provider_prompt({ provider, campaignOfferId, confirmed: true })`, `search_signals`, `search_sales_nav`, `search_prospeo`) and include currentStep for tools that accept it so the user can watch the selected source inside the campaign. Use the default sequential source viability funnel when the user did not specify a source: Signal Discovery first, then Sales Nav with recent activity, then general Sales Nav, then Prospeo only as fallback. For Signal Discovery, do not recommend from raw post count; sample engagers, calculate ICP-fit rate, target good-fit lead count, posts needed, selected posts, expected good-fit range, and scale fallback. Stop on the first viable source unless the user explicitly asked to compare. If the user names hiring signals, domains/accounts, supplied lists, posts/comments, or title/persona filters, start with the matching source instead. Parallel source scouts only when the user requested comparison, an existing parallel run is being resumed, or the first viable source is borderline and one cheap fallback check is needed. The later import_leads call must use the same campaignOfferId. Do not import, confirm, enrich, queue, or start leads during source discovery."
+          "sourceScoutRule": "Shell-first flow requires the CampaignOffer campaignId from durable state. Pass campaignId as campaignOfferId into every provider prompt/search that can persist source state (`get_provider_prompt({ provider, campaignOfferId, confirmed: true })`, `search_signals`, `search_sales_nav`, `search_prospeo`) and include currentStep for tools that accept it so the user can watch the selected source inside the campaign. Use the default sequential source viability funnel when the user did not specify a source: Signal Discovery first, then Sales Nav with recent activity, then general Sales Nav, then Prospeo only as fallback. For Signal Discovery, use intersection-first keyword lanes that combine the campaign anchor with the buyer pain/use case/ICP role; broad anchor-only lanes are fallback inventory, not selectable source lanes while narrower wedge lanes exist. Do not recommend from raw post count; sample engagers, calculate ICP-fit rate, target good-fit lead count, posts needed, selected posts, expected good-fit range, and scale fallback. Stop on the first viable source unless the user explicitly asked to compare. If the user names hiring signals, domains/accounts, supplied lists, posts/comments, or title/persona filters, start with the matching source instead. Parallel source scouts only when the user requested comparison, an existing parallel run is being resumed, or the first viable source is borderline and one cheap fallback check is needed. The later import_leads call must use the same campaignOfferId. Do not import, confirm, enrich, queue, or start leads during source discovery."
         },
         {
           "action": "optional_debug_artifacts",

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

@@ -79,14 +79,27 @@ Default source funnel:
 ```json
 {
   "stage": "find-leads",
-  "headline": "Testing warm LinkedIn activity",
-  "visibleState": "Codex is starting with recent post engagement because it gives the strongest message context if enough ICP-looking people are active there.",
-  "agentIntent": "If this lane does not clear the quick sample gate, it will switch to Sales Nav with recent activity, then broader Sales Nav, and use Prospeo only as the fallback.",
+  "headline": "Choosing the lead source",
+  "visibleState": "The browser is on Pick Provider while Codex explains the source path before opening a provider lane.",
+  "agentIntent": "Codex will start with Signal Discovery when warm LinkedIn engagement looks plausible, then switch to Sales Nav or Prospeo only if the quick viability math fails.",
   "nextAction": "Review source",
   "safety": "No leads import until you approve the source."
 }
 ```
 
+Signal Discovery viability handoff:
+
+```json
+{
+  "stage": "find-leads",
+  "headline": "Checking Signal Discovery viability",
+  "visibleState": "The browser is moving from Pick Provider into Signal Discovery so the exact posts and sample math are visible.",
+  "agentIntent": "Codex is testing whether relevant posts have enough ICP-looking engagers before recommending this as the source.",
+  "nextAction": "Review source math",
+  "safety": "No leads import until you approve the source."
+}
+```
+
 Source direction override:
 
 ```json

package/skills/providers/signal-discovery.md

@@ -43,6 +43,9 @@ When `find-leads` is using Signals during preview, treat this as a spot check:
 ### Round 1: Initial Discovery
 
 - Generate 5 strategic keywords based on their ICP
+- Prefer intersection keywords that combine the campaign's anchor topic with
+  the ICP pain/use case/role. Do not lead with broad anchor-only terms when the
+  campaign is narrower.
 - Cast a slightly wider net to understand the landscape
 - After results, analyze what's working
 - Estimate whether the results are likely to produce a usable conversation lane
@@ -122,6 +125,27 @@ Use conservative logic:
 
 You're NOT looking for generic buying intent keywords. You're looking for topics that attract YOUR SPECIFIC ICP:
 
+### Intersection-First Rule
+
+When the campaign has an anchor technology, category, community, or named tool,
+do not search only the anchor. Combine it with the campaign's buyer pain, use
+case, workflow, or role so the resulting posts are likely to attract the right
+ICP before any engager filtering.
+
+For a campaign about Claude/AI workflows for GTM, better first-round keywords
+look like:
+
+- "Claude outbound"
+- "Claude Code LinkedIn outreach"
+- "AI SDR Claude"
+- "GTM automation Claude"
+- "founder led sales Claude"
+
+Broad anchor-only keywords such as "Claude Code", "MCP", "AI agents", or
+"agentic coding" are inventory probes only. Use them after narrow lanes fail or
+as diagnostic context; do not select/promote broad posts when narrower
+campaign-wedge posts exist.
+
 ### For Founder/Executive ICPs:
 
 - "founder mode", "founder led sales", "founder brand"
@@ -149,6 +173,10 @@ You're NOT looking for generic buying intent keywords. You're looking for topics
 - Each round must have DIFFERENT keywords (no repeats across rounds)
 - Use SINGLE keywords or short phrases only
 - DO NOT use boolean operators (OR, AND, NOT)
+- At least 3 first-round keywords must be intersection keywords that include
+  both the anchor topic and the campaign pain/use case/ICP context.
+- If search results come back broad, immediately run a refined round around the
+  campaign wedge before selecting posts or sampling engagers.
 
 Examples of GOOD keywords: