@sellable/mcp 0.1.59 → 0.1.61

package/package.json

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

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

@@ -573,7 +573,10 @@ Required behavior:
 - do not mutate DB-backed campaign state
 - run a real parallel source-angle scout when the source is not supplied and at
   least two viable source angles exist. Treat source scouting as independent
-  branches, then compare the outputs in `lead-review.md`.
+  branches, then compare the outputs in `lead-review.md`. If the realistic
+  source set is Signals + Sales Nav, run both. If it is Signals + Prospeo, run
+  both. If all three are credible, run all three when the host/runtime supports
+  it.
   - Branch A: Signals / active LinkedIn posts. Search relevant keyword lanes,
     review finalist posts, fetch top-post engagers, and estimate warm-fit
     volume.
@@ -589,7 +592,7 @@ Required behavior:
     lanes and fetch top-post engagers in parallel when tool batching allows it.
     For Sales Nav-first or Prospeo/account-first campaigns, run multiple preview
     lanes for that provider in parallel and use Signals only as a warmth/quality
-    check when relevant
+    check when relevant.
 - after every Sales Nav preview, validate that filters actually applied before
   using the lane in `lead-review.md`: `searchUrl` should include filters, the
   first page should match the intended roles/companies, and the result count
@@ -606,6 +609,16 @@ 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
+- 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
+  Signals as a viable focused option. If stricter cleanup likely reduces that to
+  ~100 usable prospects, say so plainly instead of discarding it.
+- When Signals is viable-but-smaller and Sales Nav or Prospeo is more scalable,
+  the user-facing lead review must present the choice: Signals for a warmer,
+  smaller, higher-reply-upside first batch versus Sales Nav/Prospeo for broader
+  scale. Recommend the source you believe should win, often Sales Nav when scale
+  matters, but keep the smaller Signals lane available as a real option.
 - user-facing source logic must use numbers, not vibes. Never write a percentage
   such as `73% match` without the numerator, denominator, and sample basis, e.g.
   `8 of 11 sampled engagers fit the ICP (73%)`. If the sample is small, say it is
@@ -621,9 +634,10 @@ usable leads`.
   last 30 days, prefer the last 7-14 days when quality is comparable, and call
   out any older post as a deliberate tradeoff. Do not hide post age inside the
   raw search count
-- default source quality target is 300-500+ likely usable leads; accept
-  150-300 only for an explicit beta/design-partner motion and name that
-  volume tradeoff in `lead-review.md` and the approval packet
+- default source quality target is 300-500+ likely usable leads for scalable
+  outbound; accept ~150+ likely ICP-fit warm prospects as viable for a focused
+  Signals-first campaign or first review batch. Name the volume tradeoff in
+  `lead-review.md` and the approval packet rather than forcing a discard.
 - if `lead-source-intake.json` is present, read `sourceType`,
   `sourceInputMode`, file path or existing lead-list ID, selected columns,
   confirmation token, normalized counts, and any preview-created

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

@@ -301,7 +301,7 @@
           "action": "run_subskill",
           "target": "find-leads",
           "mode": "campaignless-preview",
-          "sourceScoutRule": "When source is not user-supplied and at least two viable source angles exist, scout independent source angles in parallel when host/tooling permits: Signals active-post branch, Sales Nav title/company branch, and Prospeo/domain branch only when relevant. If real parallel execution is unavailable, run the same scouts sequentially and do not claim parallel execution. Compare outputs by raw volume, n/N sampled fit, estimated good-fit range, expected reply range, and tradeoff."
+          "sourceScoutRule": "When source is not user-supplied and at least two viable source angles exist, scout independent source angles in real parallel when host/tooling permits: Signals active-post branch + Sales Nav title/company branch, Signals + Prospeo when domains/accounts are relevant, or all three when credible. If real parallel execution is unavailable, run the same scouts sequentially and do not claim parallel execution. Compare outputs by raw volume, n/N sampled fit, estimated good-fit range, expected reply range, and tradeoff. Keep Signals as viable when selected posts can produce ~150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable; when both are viable, present the choice and recommend the stronger default."
         },
         {
           "action": "write_artifacts",

package/skills/find-leads/SKILL.md

@@ -235,6 +235,11 @@ Use the existing provider tools to run a small, directional probe:
 
 If the first probe is weak or noisy and enough context exists, try 1-2 alternate hypotheses before returning.
 If the first probe has good quality but insufficient scale, iterate 1-2 times to widen intelligently before returning.
+When two or more source angles are viable, run the provider probes in real
+parallel when the host/runtime allows it. Examples: Signals + Sales Nav,
+Signals + Prospeo, or Sales Nav + Prospeo. If the host cannot run them in
+parallel, run the same probes sequentially and do not claim they ran in
+parallel.
 
 Treat refinement as a measured loop:
 
@@ -262,10 +267,23 @@ Use first when the value is in conversation opportunity, competitor engagers, co
 - Favor ICP-fit conversation density over raw post volume.
 - Capture counts, false-positive patterns, and notable examples.
 - If Signals is materially in the running, do not stop at post-level quality alone.
-- Pick 1-2 promising posts, then call `fetch_post_engagers` on those posts.
+- Pick enough promising posts to estimate campaign viability. Start with 1-3
+  strong posts for a spot check; if the sampled pass rate is good but the
+  projected pool is below target, expand to 5-8 selected posts before
+  discarding Signals.
 - Sample a representative first page only, scoring the first 25-40 engagers across the chosen posts against a rough yes/no headline rubric or `headlineICPCriteria`.
 - Use headline and display-name cues only for the spot-check sample; do not enrich people during this phase.
 - Base `estimatedReachableLeads` on the sampled engager pass rate, not only on a guessed discount from post themes.
+- A Signals lane with ~150+ estimated ICP-fit reachable engagers from selected
+  posts is viable for a focused warm campaign, even if Sales Nav is more
+  scalable. Do not discard that lane solely for being smaller. If post-level
+  filtering likely reduces 150 good fits to ~100 after stricter cleanup, say so
+  plainly and treat it as a viable-but-smaller option.
+- When Signals and Sales Nav/Prospeo are both viable, present the tradeoff and
+  ask for the user's source preference if the decision changes campaign
+  strategy: Signals = warmer, smaller, higher reply upside; Sales Nav/Prospeo =
+  more scalable, usually colder or less signal-rich. Recommend the source you
+  believe is better, but keep the viable alternate as a real option.
 - If you cannot fetch engagers in the current runtime, say the estimate is inferred and lower confidence.
 - If Signals is too sparse, too noisy, or clearly below campaign scale after the spot check, fall back to `Sales Nav` rather than forcing a weak conversation-led lane.
 
@@ -279,6 +297,9 @@ Use first when LinkedIn activity plus tighter role / company filters matter.
   `CURRENT_TITLE` lookups. Seniority filters are supporting constraints, not a
   substitute for target roles. Example: VP Sales / VP Revenue / Head of Growth
   should use title filters, not only `SENIORITY_LEVEL: Vice President`.
+- When a title lookup returns multiple options, choose the option that most
+  closely matches the intended role, not the first option by position. If
+  `Head of Growth` appears after `Head of Marketing`, use `Head of Growth`.
 - For reply-likelihood-first outbound, Sales Nav is the second choice after Signals: use it when the TAM is not active enough on LinkedIn, when Signals cannot sustain enough good fits, or when the targeting thesis depends on tighter role/company control than Signals can provide.
 - For InMail or LinkedIn-send motions, establish the baseline TAM first, then test a `POSTED_ON_LINKEDIN` slice when the pool can still sustain a campaign.
 - Treat recent posters as a preferred first-send slice, not just a nice-to-have proxy. When the recently-posted slice still yields enough projected good fits, prefer it because reply / acceptance performance is usually materially better than the cold full-TAM pool.

package/skills/providers/sales-nav.md

@@ -57,6 +57,12 @@ Example search name: "Active CXOs at 201-500 companies"
    business development, partnerships, marketing, operations, and other noisy
    roles.
 
+   Do not blindly use the first `lookup_sales_nav_filter` result. Review the
+   returned options and choose the closest semantic title match. If the first
+   result for "Head of Growth" is "Head of Marketing" but a later option is
+   "Head of Growth", use "Head of Growth". If no close title match exists,
+   retry with a tighter title query or omit that role and call out the tradeoff.
+
    Dynamic filters (REQUIRE lookup):
 
    - REGION: "United States", "California", "London"