@sellable/mcp 0.1.50 → 0.1.51

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.50",
+  "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

@@ -98,6 +98,11 @@ 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
 for that stage. Do not show raw filesystem paths unless links cannot be created

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.
@@ -714,7 +738,9 @@ 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`
@@ -733,13 +759,13 @@ unless links cannot be created or the user asks.
 Use this chat shape for the quick-number bullets:
 
 ```text
-Quick numbers:
-- Signals / AI outbound posts: 249 posts found. Sampled 40 engagers; 18/40
+**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
+- **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,
+- **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%.
 ```

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

@@ -122,17 +122,17 @@ 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. It must include bullet-pointed
-provider/source-angle estimates, one bullet per angle, so the sourcing logic is
-easy to scan:
+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
-Quick numbers:
-- Signals / AI outbound posts: 249 posts found. Sampled 40 engagers; 18/40
+**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
+- **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:
+- **Sales Nav / agencies + GTM consultants:** Smaller but higher intent. Estimate:
   150-400 good fits.
 ```
 

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"
         },
         {
@@ -400,7 +401,7 @@
           "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, 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."
+          "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

@@ -133,7 +133,9 @@ 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, for example:
+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`