@sellable/mcp 0.1.52 → 0.1.54

package/package.json

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

package/skills/create-campaign/SKILL.md

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

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

@@ -164,6 +164,7 @@ Validated draft directory:
   **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:
@@ -487,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

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

@@ -95,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

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",
@@ -973,7 +973,18 @@
         },
         {
           "action": "surface_watch_link",
-          "requires": ["create_campaign_succeeded", "save_rubrics_succeeded"]
+          "requires": ["create_campaign_succeeded", "save_rubrics_succeeded"],
+          "reference": "references/watch-link-handoff.md",
+          "requiredVisibleContent": [
+            "Campaign created",
+            "approved brief",
+            "Open this to watch",
+            "lead sourcing",
+            "rubric scoring",
+            "messaging populate live",
+            "Watch link:"
+          ],
+          "watchUrlSource": "create_campaign.watchUrl"
         }
       ],
       "allowedTools": [

package/skills/create-campaign-v2/references/watch-link-handoff.md

@@ -37,14 +37,18 @@ between the two calls. Never print the link if either call fails.
 After both tool calls succeed, print exactly one user-facing block. The block
 must contain:
 
+- a plain confirmation that the campaign was created and the approved brief was
+  saved
 - a one-line orientation sentence: `Open this to watch lead sourcing, rubric
-scoring, and messaging populate live.`
+  scoring, and messaging populate live.`
 - the `watchUrl` captured from the `create_campaign` response
 
 Example skeleton:
 
 ```text
-Campaign minted. Open this to watch lead sourcing, rubric scoring, and messaging populate live.
+Campaign created. I saved the approved brief too.
+
+Open this to watch lead sourcing, rubric scoring, and messaging populate live.
 
 Watch link: {watchUrl}
 ```