@sellable/mcp 0.1.45 → 0.1.47

package/package.json

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

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

@@ -34,8 +34,8 @@ The JSON flow is the source of truth for stage order, `requiredArtifacts`,
 replace them.
 
 Each stage writes its own artifact into the draft directory before the next
-stage starts. `brief-v1.md` is the customer-facing brief output; `brief.md` is
-the canonical downstream campaign thesis input.
+stage starts. `brief-v1.md` is an internal first-draft snapshot; `brief.md` is
+the current customer-facing and downstream campaign thesis input.
 
 After validation artifacts are complete, show the user a commit gate with 6
 choices (approve / revise-brief / revise-leads / revise-rubric /
@@ -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 current brief in `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 artifact: [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
@@ -364,8 +377,7 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   user-facing choice should be approve/revise language, not "looks good".
   Approval options should refer to what the user just read, e.g. `Approve this
 brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
-  Include `Open artifacts:` links to `brief-v1.md` and `brief.md` before the
-  approval question.
+  Include an `Open artifact:` link to `brief.md` before the approval question.
 
 - After the brief is approved or auto-confirmed, show the next progress line:
   `Cool. Now I'm going to find people who are both a good fit and likely to
@@ -399,8 +411,13 @@ should test for this campaign. Those can run in parallel and usually take
   `npx`), call APIs, query databases, inspect prompt dumps, run git, or
   synthesize artifact content. Use `Read`/`Write`/`Edit` for artifact files and
   MCP tools for product actions.
-- `brief-v1.md` is the user-facing brief. `brief.md` is the stable downstream
-  input and remains the thesis source.
+- `brief-v1.md` is only an internal first-draft snapshot. Do not show it in the
+  normal user-facing approval view. `brief.md` is the stable downstream input,
+  current user-facing brief, and thesis source.
+- On brief edits or revisions, update `brief.md` directly. Do not run another
+  long brief-generation pass just to create `brief-v2.md`. If version history is
+  ever needed, create it only as a cheap local copy after the edit; never spend
+  model/research time writing duplicate versions.
 - `lead-review.md` and `lead-sample.json` are the required outputs of `find leads`.
 - `lead-filter.md` is the primary output of `filter leads`.
 - `rubric.json` is optional and secondary to `lead-filter.md`.

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,11 @@ 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 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
+part of the normal approval UI. It should be skimmable in under 45 seconds and
+include:
 
 - who we are targeting
 - why they should care

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

@@ -206,26 +206,26 @@
       "onEnter": [
         {
           "action": "show_brief_summary",
-          "artifact": "brief-v1.md"
+          "artifact": "brief.md"
         },
         {
           "action": "render_brief_approval_checkpoint",
           "requiredVisibleContent": [
             "Campaign brief",
-            "Who we are targeting",
-            "Why they should care",
+            "Target",
+            "Core pain",
             "Offer / CTA",
-            "Proof to use",
-            "Lead source hypothesis",
+            "Proof",
+            "Lead plan",
             "Message angle",
-            "Risks / assumptions",
-            "What happens after approval",
+            "Risks",
+            "After approval",
             "approve this brief",
             "revise the brief",
             "then I will find good-fit leads"
           ],
-          "minimumVisibleBriefDetail": "full_readable_brief_before_question",
-          "requiredArtifactLinks": ["brief-v1.md", "brief.md"],
+          "minimumVisibleBriefDetail": "slim_approval_brief_before_question",
+          "requiredArtifactLinks": ["brief.md"],
           "artifactLinkTiming": "before_approval_question",
           "avoidQuestionWhenOnlyUsefulAnswerIs": "looks good"
         },