@sellable/mcp 0.1.45 → 0.1.46

package/package.json

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

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

@@ -316,39 +316,52 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   Do not mention internal artifact names, local folders, shell commands, or
   persistence in this preamble.
 
-- Before asking for brief approval, render the actual readable brief in the chat.
-  Do not ask the user to approve a one-paragraph direction, a risk note, or a
-  hidden artifact they cannot inspect. The user must be able to read what they
-  are approving without opening files. Include these sections:
+- Before asking for brief approval, render a slim approval brief in the chat and
+  keep the rich brief in `brief-v1.md` / `brief.md`. 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:
 
   ```text
   Campaign brief
 
-  Who we are targeting:
+  Target:
   ...
 
-  Why they should care:
+  Core pain:
   ...
 
   Offer / CTA:
   ...
 
-  Proof to use:
+  Proof:
   ...
 
-  Lead source hypothesis:
+  Lead plan:
   ...
 
   Message angle:
   ...
 
-  Risks / assumptions:
+  Risks:
   ...
 
-	  What happens 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.
-	  ```
+  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.
+  ```
+
+  Do not paste the full rich brief into chat for approval unless the user asks.
+  Do not show long filesystem paths in the normal approval view. After the slim
+  brief, include only:
+
+  ```text
+  Open artifacts: [brief-v1.md] and [brief.md]
+  ```
+
+  If clickable links cannot be created, show one compact fallback line:
+  `Trouble opening artifacts? I can show the file paths.`
 
   The `Offer / CTA` section must name the useful thing the buyer gets by
   replying. Do not use vague peer-call framing like `compare notes`, `swap

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

@@ -57,12 +57,13 @@ 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 brief itself, not just a direction summary.
+brief approval, render the slim approval brief, not just a direction summary.
 
 Every approval should also give the user a way to inspect the source artifact.
 After the readable inline content, include an `Open artifacts:` line with links
-or plain paths to the files behind the decision. The artifact links are a backup
-for inspection, not a replacement for showing the content in chat.
+to the files behind the decision. Do not show long plain paths in normal chat;
+offer them only as a fallback if links cannot be created. The artifact links are
+a backup for inspection, not a replacement for showing the decision in chat.
 
 This applies especially to message approvals. Never ask someone to approve a
 message they cannot see. Show the subject, tokenized template, a filled sample
@@ -92,7 +93,10 @@ Every customer-facing update should answer one of these:
 - What will the user see next?
 - What is protected until approval?
 
-Before a brief approval, the user should see:
+Before a brief approval, the user should see a slim approval brief in chat. The
+rich brief still exists in `brief-v1.md` / `brief.md`; the chat view is the
+decision surface, not the full working memo. It should be skimmable in under 45
+seconds and include:
 
 - who we are targeting
 - why they should care