@sellable/mcp 0.1.44 → 0.1.46

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.44",
+  "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,40 +316,62 @@ 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:
+  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
+  notes`, `worth chatting`, `pick your brain`, or a bare `15 minute call` unless
+  the user explicitly asks for that. A low-friction CTA is only good when the
+  object is concrete: a checklist, workflow teardown, benchmark, sample, short
+  loom, diagnostic, bottleneck map, relevant proof asset, or a working session
+  with a clear output. If the first draft produces a vague CTA, revise it before
+  showing the brief.
+
   After rendering that brief, ask for brief approval when there is a real
   strategic choice or the user has not already made the direction obvious. The
   user-facing choice should be approve/revise language, not "looks good".
@@ -495,10 +517,17 @@ commit gate.
 Use customer-facing question wording:
 
 - target prospects: `Who should this campaign target?`
-- main CTA / offer: `What should {{sender_or_company}} offer them?`
+- main CTA / offer: `What useful thing should {{sender_or_company}} offer them?`
 - proof emphasis: `What proof should we lean on?`
 - lead source: `How should we get the people for this campaign?`
 
+Offer shortcuts must be concrete deliverables or outcomes, not meeting wrappers.
+Good examples: `send a short checklist`, `map 2-3 workflow bottlenecks`, `show a
+relevant customer example`, `teardown their public workflow`, `walk through a
+sample output`, or `diagnose where the current process slows down`. Bad
+examples: `compare notes`, `quick intro call`, `worth chatting`, `pick your
+brain`, `learn more`, or `see if it makes sense`.
+
 Ask the lead-source question as the last question in the first strategy batch,
 after buyer, offer/ask, and proof/safety are understood. Frame supplied lists as
 optional, not required. Suggested lead-source shortcuts should include:

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
@@ -103,6 +107,11 @@ Before a brief approval, the user should see:
 - risks / assumptions
 - what happens after approval
 
+The offer / CTA should be useful before it is convenient. Avoid vague
+peer-call asks like "compare notes" unless the user explicitly chose that. The
+buyer should know what they get if they reply: a checklist, teardown, diagnostic,
+sample, benchmark, relevant example, or working session with a concrete output.
+
 For lead-source decisions, confidence comes from concrete counts. Do not say
 "strong sample", "73% match", or "meaningful concentration" without showing the
 sample size and what was counted. Prefer: