@sellable/mcp 0.1.56 → 0.1.58

package/package.json

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

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

@@ -588,6 +588,11 @@ Required behavior:
   should be plausible. If Sales Nav returns a giant unfiltered pool, drops the
   filters, or errors after one clean retry, call it out as a provider/tool
   issue and do not recommend Sales Nav.
+- when the brief or user names target roles, Sales Nav must preserve those role
+  names through `CURRENT_TITLE` lookups. Do not use broad seniority as a
+  substitute for role intent. VP Sales, VP Revenue, CRO, Head of Growth, and
+  similar targets should stay visible in the filter recipe and the source
+  explanation.
 - for Signals-first campaigns, raw post search volume is only inventory, not
   lead volume. `492 post results` means matching LinkedIn posts found across
   keyword lanes; it does not mean 492 prospects. The source decision must name

package/skills/create-campaign-v2/references/approval-gate-framing.md

@@ -141,6 +141,19 @@ summary.
 4. **message validation** — the `Selected Winner` from `message-validation.md`,
    rendered as it will appear in the outbound, plus the `Findings` + `Recommendation`
 
+The inline approval packet must include exactly one concrete sample message
+rendered as the recipient would see it. Do not make the user mentally expand
+tokens at the final approval moment. If the selected winner contains supported
+prospect-row `{{tokens}}`, show the template in `## Approved Message Template`
+and also include a short `## Sample Message` section with one realistic filled
+example from the lead sample. Keep the full token rules in the artifact, not in
+the top chat summary.
+
+Do not include sequence, cadence, sending-window, mailbox, or campaign settings
+review in the pre-mint approval packet. Those are configured and reviewed after
+the campaign is created in the autonomous tail. The pre-mint packet approves
+only the brief, lead source, lead filter/rubric, and first message direction.
+
 The packet must include a dedicated `## Message Review` section immediately
 before `## Approved Message Template`. This is the customer-facing messaging
 gate. It should not be a raw validation dump; it should answer:

package/skills/find-leads/SKILL.md

@@ -275,6 +275,10 @@ Use first when LinkedIn activity plus tighter role / company filters matter.
 
 - Always call `lookup_sales_nav_filter` before dynamic filters.
 - Start with a broad-but-reasonable baseline: company size + core roles + core industries.
+- If the campaign gives specific target role names, preserve them with
+  `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`.
 - 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

@@ -50,6 +50,13 @@ Example search name: "Active CXOs at 201-500 companies"
 2. LOOKUP DYNAMIC FILTERS - Get IDs for geography, industry, titles, etc.
    Before using ANY dynamic filter, you MUST call lookup_sales_nav_filter.
 
+   When the campaign names target roles, use CURRENT_TITLE lookups for those
+   role names. Seniority alone is not enough. For example, "VP Sales / VP
+   Revenue / Head of Growth" should become title filters plus seniority, not
+   only `SENIORITY_LEVEL: Vice President`, because generic VP seniority pulls
+   business development, partnerships, marketing, operations, and other noisy
+   roles.
+
    Dynamic filters (REQUIRE lookup):
 
    - REGION: "United States", "California", "London"