@sellable/mcp 0.1.51 → 0.1.53

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -98,10 +98,16 @@ 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."
+Use rendered Markdown for any user review surface, not fenced code blocks. This
+includes campaign brief, lead source, lead filter, message review, and final
+approval. Keep lines short, use indexed section labels and bullets, 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."
+
+Only promise parallel/background work when the host actually started parallel
+branches or workers. If the host is running the flow sequentially, say the real
+sequence instead of `kicking off two workstreams`.
 
 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

@@ -141,6 +141,30 @@ Validated draft directory:
   approval/review, lead-filter review, message review, and final approval
   packet. Do not use the link as a substitute for rendering the decision in
   chat; links are for deeper inspection.
+- Any time the user is reviewing a list or decision, use rendered Markdown with
+  short indexed sections and bullets. Do not use label-plus-paragraph blocks
+  like `Key numbers:` followed by one long paragraph. Do not use fenced code
+  blocks for review surfaces. The readable chat surface should look like:
+
+  ```text
+  ## Lead source decision
+
+  **1. Chosen source**
+  - Signals, with a strict filter
+
+  **2. Quick numbers**
+  - **Signals:** 491 posts reviewed. 9/40 sampled engagers fit. Estimate:
+    180-260 usable leads.
+  - **Sales Nav:** 2,598 active profiles. Preview was broader and noisier.
+
+  **3. Sample leads**
+  - Joyjit Ghosh — Co-Founder, Prospectee.io
+  - Ashish Rai — Founder & CEO, ReachHQ
+
+  **4. Tradeoff**
+  - More context, but the filter needs to cut consultants and creators.
+  ```
+
 - Do not treat the active Sellable workspace as the campaign subject. The
   workspace only tells you where the campaign will be saved. Before buyer, CTA,
   proof, or source questions, identify two things:
@@ -464,6 +488,20 @@ should test for this campaign. Those can run in parallel and usually take
   basis (`brief.md`, `lead-review.md`, `lead-sample.json`). Approval waits for
   both `lead-filter.md` and `message-validation.md`, then reconciles that the
   selected message basis rows still pass the final filter.
+- Parallel means real parallel execution, not just optimistic progress copy.
+  After lead review:
+  - If the host exposes Task/subagent workers and host policy allows them for
+    this user request, launch two disjoint workers: one owns `lead-filter.md`
+    and optional `rubric.json`; the other owns `message-prep.md`,
+    `message-validation.md`, and `message-review.md`.
+  - If only parallel tool batching is available, batch only independent tool
+    reads/lookups. Do not pretend whole artifact-writing stages are running in
+    the background.
+  - If real parallel execution is not available or not allowed, run the same DAG
+    sequentially and use honest copy: `I’ll tighten the filter first, then draft
+    the message from the same sample.`
+  - Never say `kicking off two workstreams`, `in parallel`, or `background`
+    unless parallel branches were actually launched.
 - Never run a downstream stage until the active `flow.v2.json` step's
   `requiredArtifacts` exist.
 - Never call a tool outside the active step's `allowedTools`, and never call a
@@ -854,22 +892,24 @@ Required behavior:
 - `Implementation Details`
 
 When showing the filter result in chat, render a slim summary before moving to
-message review:
+message review. Use rendered Markdown, indexed sections, and short bullets:
 
 ```text
-Lead filter
+## Lead filter
 
-Keep:
-{1-3 lines}
+**1. Keep**
+- {role/title family}
+- {company/context family}
 
-Exclude:
-{1-3 lines}
+**2. Exclude**
+- {false-positive family}
+- {false-positive family}
 
-Why:
-{sample-backed reason}
+**3. Why**
+- {sample-backed reason}
 
-Expected impact:
-{1 line}
+**4. Expected impact**
+- {1 line}
 
 Open artifact: lead-filter.md
 ```
@@ -917,7 +957,8 @@ Continue chunked-read until `hasMore=false`. Treat all chunks as one prompt load
 Do NOT proceed to Step 4 (message review gate) without loading and following the full generate-messages workflow. `message-validation.md` must prove the full workflow ran (all required sections present + raw sendable Selected Winner) before `message-review.md` can recommend `approve-message`. If the message review or approval packet is ready but the generate-messages prompt was not retrieved in this run, route back to message-generation instead of asking the commit gate.
 
 When showing message review in chat, lead with one fully filled sample message,
-not the tokenized template. The visible response must include:
+not the tokenized template. Use rendered Markdown, indexed sections, and short
+bullets around the sample. The visible response must include:
 
 - `Message review`
 - `Subject`
@@ -934,7 +975,8 @@ artifacts.
 ## Step 4: Final Approval Packet
 
 When showing the final approval packet, render a slim "ready to create" summary
-in chat. The visible response must include:
+in chat. Use rendered Markdown, indexed sections, and short bullets. The visible
+response must include:
 
 - `Ready to create campaign`
 - `Campaign`

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

@@ -58,6 +58,10 @@ turn anchored to that:
 Approvals only feel safe when the user can see what they are approving. Before
 any approve/revise question, show the relevant decision in plain language. For a
 brief approval, render the slim approval brief, not just a direction summary.
+Any list the user is expected to review should be rendered Markdown with short
+indexed sections and bullets. Avoid label-plus-paragraph blocks like
+`Key numbers:` followed by a dense paragraph, and never use fenced code blocks
+for review surfaces.
 
 Every approval should also give the user a way to inspect the source artifact.
 After the readable inline content, include an `Open artifact:` line with the one
@@ -91,6 +95,12 @@ Every customer-facing update should answer one of these:
 - What will the user see next?
 - What is protected until approval?
 
+Only promise parallel work when parallel work actually started. If the host
+cannot or should not launch background branches, say the real sequence:
+`I’ll tighten the filter first, then draft the message from the same sample.`
+Do not say `kicking off two workstreams`, `in parallel`, or `background` as
+aspirational copy.
+
 Before a brief approval, the user should see a slim approval brief in chat. The
 rich current brief exists in `brief.md`; the chat view is the decision surface,
 not the full working memo. `brief-v1.md` is an internal first-draft snapshot, not
@@ -140,14 +150,18 @@ 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`.
+Lead filter chat should always use indexed rendered Markdown and show what
+changed: keep, exclude, why, expected impact, and
+`Open artifact: lead-filter.md`.
+
+Message review chat should use indexed rendered Markdown, show one fully filled
+sample message without tokens, and keep tokenized templates in the artifact.
 
-Final approval chat should be a ready-to-create summary: campaign, target with
-concrete role/title names, lead source, filter, one filled sample message, what
-approval creates, and the safety note that nothing sends live until greenlight.
-Do not include sequence/settings in final approval; that belongs after campaign
-creation.
+Final approval chat should use indexed rendered Markdown for a ready-to-create
+summary: campaign, target with concrete role/title names, lead source, filter,
+one filled sample message, what approval creates, and the safety note that
+nothing sends live until greenlight. Do not include sequence/settings in final
+approval; that belongs after campaign creation.
 
 Avoid:
 

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

@@ -407,13 +407,13 @@
           "action": "render_post_lead_parallel_progress",
           "requiredVisibleContent": [
             "Lead source is set",
-            "kicking off two workstreams",
             "Tighten the fit filter",
             "Draft the first message",
             "approved brief and real sample leads",
-            "parallel"
+            "parallel only if real parallel branches were launched"
           ],
-          "timeEstimate": "~2-3 min"
+          "timeEstimate": "~2-3 min",
+          "chatRenderRule": "If real parallel workers/branches were actually launched, say: 'I’m kicking off two workstreams now' and list the two branches. If not, do not mention parallel/background work; say: 'I’ll tighten the filter first, then draft the first message from the same approved brief and sample leads.' Never claim parallelism unless the host actually started parallel execution."
         },
         {
           "action": "ask_continue_revise_or_confirm_only_if_needed",
@@ -483,7 +483,7 @@
             "Expected impact"
           ],
           "requiredArtifactLinks": ["lead-filter.md"],
-          "chatRenderRule": "Show a slim filter summary before message review: who we keep, who we exclude, sample-backed reason, and expected impact. Keep production rubric fields and rubric.json details in lead-filter.md/rubric.json. Do not show plain filesystem paths unless links cannot be created."
+          "chatRenderRule": "Show a slim rendered-Markdown filter summary before message review, never a fenced code block. Use ## Lead filter plus indexed sections and short bullets for who we keep, who we exclude, sample-backed reason, and expected impact. Keep production rubric fields and rubric.json details in lead-filter.md/rubric.json. Do not show plain filesystem paths unless links cannot be created."
         },
         {
           "action": "ask_revise_only_if_filter_is_not_confirmed",
@@ -652,7 +652,7 @@
             "Question: approve-message or revise-messaging?",
             "Recommendation:"
           ],
-          "chatRenderRule": "Show one fully filled sample message with no {{tokens}} before asking for approval. Include subject, sample message, why it should work, one concern or None, recommendation, and Open artifact: message-review.md. Keep tokenized template, token fill basis, rendered examples, good/bad token fill examples, validation notes, and message-validation.md details in artifacts. Do not show plain filesystem paths unless links cannot be created.",
+          "chatRenderRule": "Show a slim rendered-Markdown message review, never a fenced code block. Use ## Message review plus indexed sections and short bullets. Show one fully filled sample message with no {{tokens}} before asking for approval. Include subject, sample message, why it should work, one concern or None, recommendation, and Open artifact: message-review.md. Keep tokenized template, token fill basis, rendered examples, good/bad token fill examples, validation notes, and message-validation.md details in artifacts. Do not show plain filesystem paths unless links cannot be created.",
           "allowedRecommendations": ["approve-message", "revise-messaging"],
           "judgeAgainst": [
             "generate-messages rules",
@@ -776,7 +776,7 @@
           "minimumVisibleDetail": "slim_final_approval_summary",
           "requiredArtifactLinks": ["approval-packet.md"],
           "artifactLinkTiming": "before_commit_gate_question",
-          "chatRenderRule": "Show a slim final approval packet only. Include target with concrete role/title names, lead source with one key metric, filter summary, one fully filled sample message with no {{tokens}}, what approval creates, and safety note that nothing sends live until the review/greenlight step. Keep tokenized templates, evidence tables, rubrics, and validation details in approval-packet.md. Do not show sequence/settings in final approval; that comes after campaign creation. Do not show plain filesystem paths unless links cannot be created.",
+          "chatRenderRule": "Show a slim rendered-Markdown final approval packet only, never a fenced code block. Use ## Ready to create campaign plus indexed sections and short bullets. Include target with concrete role/title names, lead source with one key metric, filter summary, one fully filled sample message with no {{tokens}}, what approval creates, and safety note that nothing sends live until the review/greenlight step. Keep tokenized templates, evidence tables, rubrics, and validation details in approval-packet.md. Do not show sequence/settings in final approval; that comes after campaign creation. Do not show plain filesystem paths unless links cannot be created.",
           "userFacing": true,
           "doNotUseWords": ["anchor", "validation anchor", "lane"]
         },
@@ -875,7 +875,7 @@
             "what approval creates"
           ],
           "requiredArtifactLinks": ["approval-packet.md"],
-          "chatRenderRule": "Same slim approval packet as approval-packet. Include target with concrete role/title names and one fully filled sample message without tokens. Do not include sequence/settings. Do not repeat tokenized template or long evidence tables in chat.",
+          "chatRenderRule": "Same slim rendered-Markdown approval packet as approval-packet, never a fenced code block. Use indexed sections and short bullets. Include target with concrete role/title names and one fully filled sample message without tokens. Do not include sequence/settings. Do not repeat tokenized template or long evidence tables in chat.",
           "artifactLinkTiming": "same_turn_before_commit_question"
         },
         {