@sellable/mcp 0.1.49 → 0.1.51

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -92,8 +92,16 @@ clear business decisions, tradeoffs, and approval gates. Use product language:
 When explaining lead-source decisions, show the concrete counts behind the
 logic: lanes searched, timeframe, raw result counts, finalist posts or preview
 rows, sampled people, sampled fits as n/N (%), estimated usable people, and the
-confidence basis. Never show a percent like "73% match" without the numerator,
-denominator, and sample basis.
+confidence basis. Break estimates out by provider/source angle in bullet form
+instead of showing only one raw total. Each angle should show raw pool, sampled
+fits as n/N, estimated good-fit range after cleanup, expected reply-rate range,
+and confidence basis. Never show a percent like "73% match" without the
+numerator, denominator, and sample basis.
+
+Use rendered Markdown for campaign brief and lead-source chat, not fenced code
+blocks. Keep lines short, use indexed section labels, and translate internal
+sourcing terms into plain language. For example, explain "signal discovery" as
+"looking for LinkedIn activity from people already talking about this problem."
 
 Every approval gate must include artifact access after the readable inline
 content. Show an `Open artifact:` line with the one key clickable markdown link

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

@@ -318,39 +318,63 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   persistence in this preamble.
 
 - Before asking for brief approval, render a slim approval brief in the chat and
-  keep the rich current brief in `brief.md`. Do not ask the user to
+  keep the rich current brief in `brief.md`. Use rendered Markdown directly:
+  `##` heading, bold field labels, numbered section labels, and short bullets.
+  Do not wrap the user-facing approval view in a fenced code block because that
+  creates horizontal scrolling in Claude Code and Codex. Do not ask the user to
   approve a one-paragraph direction, a risk note, or hidden artifact they cannot
   inspect. The chat approval view should be skimmable in under 45 seconds; full
   reasoning, source notes, and robustness stay in the artifacts. Include these
-  sections, with 1-2 short lines each:
+  sections, with short wrapped lines:
 
   ```text
-  Campaign brief
+  ## Campaign brief
 
-  Target:
-  ... (include concrete role/title names, not just a broad persona)
+  **Decision:** ... (one sentence)
 
-  Core pain:
-  ...
+  **1. Target**
+  - ... (include concrete role/title names, not just a broad persona)
+  - ...
 
-  Offer / CTA:
-  ...
+  **2. Pain**
+  - ...
+  - ...
 
-  Proof:
-  ...
+  **3. Offer**
+  - ...
+  - ...
 
-  Lead plan:
-  ...
+  **4. Proof**
+  - ...
+  - ...
 
-  Message angle:
-  ...
+  **5. Lead plan**
+  I’ll look for people who are already showing signs this problem matters:
+  - people talking about ...
+  - people with roles like ...
+  - companies likely to feel ...
 
-  Risks:
-  ...
+  If that pool is too small or noisy, I’ll switch to broader LinkedIn title and
+  company filters.
 
-  After approval:
-  I’ll find good-fit LinkedIn leads, show you the source decision and sample, then
-  draft the first message for review before anything goes live.
+  **6. Risks**
+  - ...
+  - ...
+
+  **7. After approval**
+  I’ll find good-fit LinkedIn leads, show the source decision and sample, then
+  draft the first message for review. Nothing goes live without approval.
+  ```
+
+  In the `Lead plan` section, do not expose internal provider shorthand as the
+  explanation. Avoid bare phrases like `signal discovery`, `founder-led GTM`,
+  `RevOps`, `outbound systems`, or `pipeline architecture` unless they are
+  translated into what the user can understand. For example:
+
+  ```text
+  I’ll start by looking for LinkedIn activity from founders and revenue leaders
+  who are talking about pipeline problems, CRM handoffs, outbound tooling, or
+  messy sales processes.
   ```
 
   Do not paste the full rich brief into chat for approval unless the user asks.
@@ -691,12 +715,17 @@ table with one row per selected or finalist post:
 `## Evidence Snapshot` must include a compact numbers-first table:
 
 - source lane / keyword or filter
+- provider/source angle label, e.g. `Signals / AI outbound posts`,
+  `Sales Nav / active SaaS founders + GTM leaders`, or
+  `Prospeo / domain-filtered agencies`
 - timeframe searched
 - raw results found
 - finalist posts or preview rows reviewed
 - sampled people
 - sampled fits, shown as `n/N (%)`
 - estimated usable people
+- estimated good-fit range after cleanup
+- expected reply-rate range
 - confidence note (`sample-backed`, `directional`, or `needs more sample`)
 
 For Signals-first campaigns, `## Sample Leads` must group representative sample
@@ -709,13 +738,16 @@ range, and estimate basis. If exact performance data is unavailable, use a
 directional range and label it `directional`, not definitive.
 
 When showing `lead-review.md` to the user, render a slim decision summary in
-chat, not the full evidence table. The visible response must include:
+chat, not the full evidence table. Use rendered Markdown directly with short
+bullet lines; do not use fenced code blocks for the user-facing lead review.
+The visible response must include:
 
 - `Lead source decision`
 - `Chosen source`
 - `Why it won`
-- `Key numbers` with raw volume, sampled fit rate as `n/N`, estimated usable
-  leads, expected connection acceptance range, and expected reply rate range
+- `Quick numbers` as bullet points, with one provider/source angle per bullet.
+  Each bullet must include raw volume, sampled fit rate as `n/N`, estimated
+  good-fit range after cleanup, and expected reply-rate range when available.
 - `Sample leads` with 3-5 representative `Name — Title, Company` rows
 - `Tradeoff`
 - `Open artifact: lead-review.md`
@@ -724,6 +756,20 @@ Keep `## Evidence Snapshot`, selected posts, discarded paths, full sample rows,
 and `lead-sample.json` details in artifacts. Do not show raw filesystem paths
 unless links cannot be created or the user asks.
 
+Use this chat shape for the quick-number bullets:
+
+```text
+**1. Quick numbers**
+- **Signals / AI outbound posts:** 249 posts found. Sampled 40 engagers; 18/40
+  looked usable. Estimate: 100-250 good warm fits. Expected reply: 6-12%.
+- **Sales Nav / active SaaS founders + GTM leaders:** 27,454 active profiles before
+  filtering. First 25 had 12 strong/probable fits. Estimate: 300-800 good fits
+  after title/company cleanup. Expected reply: 4-9%.
+- **Prospeo / domain-filtered agencies:** 1,000+ likely contacts if we need scale,
+  but weaker LinkedIn activity. Estimate: 500-1,000 contacts. Expected reply:
+  2-5%.
+```
+
 After the lead source is set, use this progress copy before the parallel
 filter/message work:
 

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

@@ -122,10 +122,23 @@ sampled engagers; 31 looked like real ICP fits, so I’d treat this as direction
 usable people if the remaining engagers behave similarly.
 ```
 
-Lead review chat should be short and numeric: chosen source, why it won, raw
-volume, sampled fit rate as `n/N`, estimated good fits, expected connection
-acceptance, expected reply rate, 3-5 sample leads, and one tradeoff. Full tables
-belong in `lead-review.md`.
+Lead review chat should be short and numeric. It must use rendered Markdown,
+not a fenced code block, and include bullet-pointed provider/source-angle
+estimates, one bullet per angle, so the sourcing logic is easy to scan:
+
+```text
+**1. Quick numbers**
+- **Signals / AI outbound posts:** 249 posts found. Sampled 40 engagers; 18/40
+  looked usable. Estimate: 100-250 good warm fits.
+- **Sales Nav / active SaaS founders + GTM leaders:** 27,454 active profiles before
+  filtering. First 25 had 12 strong/probable fits. Estimate: 300-800 good fits.
+- **Sales Nav / agencies + GTM consultants:** Smaller but higher intent. Estimate:
+  150-400 good fits.
+```
+
+Then show chosen source, why it won, expected connection acceptance, expected
+reply rate, 3-5 sample leads, and one tradeoff. Full tables belong in
+`lead-review.md`.
 
 Lead filter chat should always show what changed: keep, exclude, why, expected
 impact, and `Open artifact: lead-filter.md`.

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

@@ -227,6 +227,7 @@
           "minimumVisibleBriefDetail": "slim_approval_brief_before_question",
           "requiredArtifactLinks": ["brief.md"],
           "artifactLinkTiming": "before_approval_question",
+          "chatRenderRule": "Show the brief as rendered Markdown, never as a fenced code block. Use ## Campaign brief, a one-sentence bold Decision, indexed bold section labels, and short bullets. In Lead plan, translate provider shorthand into plain user-facing language about who will be searched for and why; do not rely on bare terms like signal discovery, RevOps, outbound systems, or pipeline architecture.",
           "avoidQuestionWhenOnlyUsefulAnswerIs": "looks good"
         },
         {
@@ -385,6 +386,7 @@
             "why use or discard"
           ],
           "evidenceSnapshotRequiredFields": [
+            "provider/source angle label",
             "source lane or keyword",
             "timeframe searched",
             "raw results found",
@@ -392,12 +394,14 @@
             "sampled people",
             "sampled fits as n/N (%)",
             "estimated usable people",
+            "estimated good-fit range after cleanup",
+            "expected reply-rate range",
             "confidence note"
           ],
           "forbidPercentOnlyFitRates": true,
           "requiredArtifactLinks": ["lead-review.md"],
           "artifactLinkTiming": "before_next_step_or_revision_question",
-          "chatRenderRule": "Show a slim decision summary only: chosen source, why it won, raw volume, sampled fit rate as n/N, estimated usable leads, expected connection acceptance range, expected reply rate range, 3-5 representative sample leads, and one tradeoff. Keep evidence tables, selected posts, 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."
+          "chatRenderRule": "Show a slim rendered-Markdown decision summary only, never a fenced code block. Use indexed sections and short bullets: chosen source, why it won, bullet-pointed Quick numbers with one provider/source angle per bullet, raw volume, sampled fit rate as n/N, estimated good-fit range after cleanup, expected connection acceptance range, expected reply rate range, 3-5 representative sample leads, and one tradeoff. Keep evidence tables, selected posts, 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."
         },
         {
           "action": "render_post_lead_parallel_progress",

package/skills/create-campaign-v2/references/validation-criteria.md

@@ -131,6 +131,20 @@ usable leads after filtering, likely connection acceptance range, likely reply
 range, and estimate basis. If exact performance data is unavailable, use a
 directional range and label it `directional`, not definitive.
 
+`## Evidence Snapshot` and the visible lead-review chat must break estimates out
+by provider/source angle. Do not collapse everything into one raw count. Use
+one row or bullet per angle. The visible chat version should be rendered
+Markdown with indexed sections and short bullets, not a fenced code block. For
+example:
+
+- `Signals / AI outbound posts`
+- `Sales Nav / active SaaS founders + GTM leaders`
+- `Sales Nav / agencies + GTM consultants`
+- `Prospeo / domain-filtered agencies`
+
+Each angle must show raw pool, sampled fits as `n/N`, estimated good-fit range
+after cleanup, expected reply-rate range, and confidence basis.
+
 `lead-sample.json` must include enough structured lead data for downstream
 filtering: