@sellable/mcp 0.1.19 → 0.1.20

package/README.md

@@ -83,14 +83,14 @@ The token is provided when you generate it. Use `list_workspaces` +
 For customer/package installs, use the public installer:
 
 ```bash
-npx -y @sellable/install@0.1.19 --host codex --token skt_live_your_token_here --workspace-id your_workspace_id
+npx -y @sellable/install@0.1.20 --host codex --token skt_live_your_token_here --workspace-id your_workspace_id
 ```
 
 If you already have `~/.sellable/config.json`, rerun/verify without rewriting
 auth:
 
 ```bash
-npx -y @sellable/install@0.1.19 --host codex
+npx -y @sellable/install@0.1.20 --host codex
 sellable --verify-only --host codex
 ```
 

package/package.json

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

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

@@ -120,6 +120,12 @@ Validated draft directory:
   or safe launch. Do not say "persist", "local draft folder", "artifact",
   "mkdir", "campaign thesis", or "same approved campaign thesis" in
   customer-facing progress copy.
+- Every approval gate must include artifact access after the readable inline
+  content. Show a short `Open artifacts:` line with clickable markdown links
+  using absolute paths when the host supports them, plus the plain path for CLI
+  users. Do this for brief approval, lead-source approval/review, message review,
+  and final approval packet. Do not use the links as a substitute for rendering
+  the content inline; links are for deeper inspection.
 - 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:
@@ -318,7 +324,9 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   strategic choice or the user has not already made the direction obvious. The
   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`.
+  brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
+  Include `Open artifacts:` links to `brief-v1.md` and `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
@@ -522,8 +530,8 @@ Required behavior:
   such as `73% match` without the numerator, denominator, and sample basis, e.g.
   `8 of 11 sampled engagers fit the ICP (73%)`. If the sample is small, say it is
   directional. If an estimate depends on assumptions, show the math: `5 selected
-  posts x ~40-80 reachable engagers/post x 25-40% expected fit = ~50-160 likely
-  usable leads`.
+posts x ~40-80 reachable engagers/post x 25-40% expected fit = ~50-160 likely
+usable leads`.
 - source progress updates should expose the confidence-building numbers as soon
   as they exist: keyword lanes searched, timeframe used, post results by lane,
   finalist posts reviewed, engagers fetched, sampled engagers, sampled fits,
@@ -578,7 +586,7 @@ Required behavior:
   posts reviewed, number of selected posts, total engagers fetched, deduped
   sampled people count, sampled fit count, and the estimated likely usable people
   range. Explicitly distinguish `posts found`, `engagers sampled`, and `usable
-  people estimated`.
+people estimated`.
 - source decision: best path, why it won, pros, cons/tradeoffs, and discarded
   source paths with the reason each lost
 - repeated false-positive patterns
@@ -637,6 +645,8 @@ visible response must include `## Source Decision`, `## Evidence Snapshot`,
 `## Expected LinkedIn Funnel`, `## Pros`, `## Tradeoffs`, and `## Discarded
 Paths`. For Signals-first campaigns it must also include `## Selected Signal
 Posts` and `## Sample Leads`.
+Include `Open artifacts:` links to `lead-review.md` and `lead-sample.json`
+before moving to filter/message drafting or asking for any source revision.
 
 For supplied profile CSVs and existing lead lists, `lead-review.md` must not
 describe a generic TAM estimate or pretend the rows came from Sales Nav/Prospeo
@@ -860,6 +870,16 @@ Orchestration requirements:
   `My take: ...`, `Suggested adjustment: ...`,
   `Question: approve-message or revise-messaging?`, `Recommendation:
 approve-message|revise-messaging`.
+- Never ask the message approval question until the full message review is
+  visible in the chat. A summary like `Message review is ready` or `the draft
+  avoids a generic pitch` is not enough. The user must see the actual subject,
+  the actual tokenized message template, at least one good filled example, one
+  good omit example, token notes, your take, and the suggested adjustment before
+  any `approve-message` / `revise-messaging` question appears. If you catch
+  yourself wanting to offer `show me message` as a choice, stop: render the
+  message review first, then ask only `approve-message` or `revise-messaging`.
+  Include `Open artifacts:` links to `message-review.md` and
+  `message-validation.md` before the approval question.
 - `My take:` and `Suggested adjustment:` are mandatory customer-facing decision
   fields, not optional summary text. They must appear after `Token notes:` and
   before the question in every rendered message review. They must each be
@@ -981,6 +1001,9 @@ proof:`, `p.s. useful proof:`, `p.s. proof:`, or `p.s. social proof:`.
   summarize the customer checkpoint from `message-review.md` and preserve the
   same literal `My take:`, `Suggested adjustment:`, and `Recommendation:`
   labels.
+  Include `Open artifacts:` links to `approval-packet.md`,
+  `message-review.md`, `lead-review.md`, and `brief.md` before the commit-gate
+  question.
 - if `message-validation.md` contains an extractable `Selected Winner`, use
   that exact winner as the `## Approved Message Template` in
   `approval-packet.md` and in the campaign brief passed to `create_campaign`.

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

@@ -59,6 +59,15 @@ 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.
 
+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.
+
+This applies especially to message approvals. Never ask someone to approve a
+message they cannot see. Show the subject, message body/template, filled example,
+omit example, token notes, your take, and suggested adjustment first.
+
 ## Progress Updates
 
 Every customer-facing update should answer one of these:

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

@@ -227,6 +227,8 @@
             "then I will find good-fit leads"
           ],
           "minimumVisibleBriefDetail": "full_readable_brief_before_question",
+          "requiredArtifactLinks": ["brief-v1.md", "brief.md"],
+          "artifactLinkTiming": "before_approval_question",
           "avoidQuestionWhenOnlyUsefulAnswerIs": "looks good"
         },
         {
@@ -397,6 +399,8 @@
             "confidence note"
           ],
           "forbidPercentOnlyFitRates": true,
+          "requiredArtifactLinks": ["lead-review.md", "lead-sample.json"],
+          "artifactLinkTiming": "before_next_step_or_revision_question",
           "doNotCompressToSummaryOnly": true,
           "doNotRenderArtifactLinksOnly": true
         },
@@ -607,6 +611,13 @@
             "question",
             "recommendation"
           ],
+          "mustRenderInlineBeforeQuestion": true,
+          "minimumVisibleMessageDetail": "full_message_review_before_question",
+          "requiredArtifactLinks": [
+            "message-review.md",
+            "message-validation.md"
+          ],
+          "artifactLinkTiming": "before_approval_question",
           "requiredLabels": [
             "Subject:",
             "Message:",
@@ -644,6 +655,20 @@
         {
           "action": "ask_message_review_choice",
           "choices": ["approve-message", "revise-messaging"],
+          "questionPrerequisiteVisibleLabels": [
+            "Status: message-review",
+            "Subject:",
+            "Message:",
+            "Rendered examples:",
+            "Good token fill:",
+            "Good omit:",
+            "Token notes:",
+            "My take:",
+            "Suggested adjustment:",
+            "Recommendation:"
+          ],
+          "forbiddenWhenMissingVisibleMessage": true,
+          "doNotOfferShowMessageChoice": true,
           "stopAfterQuestion": true
         },
         {
@@ -726,6 +751,13 @@
             "messages",
             "risks and next action"
           ],
+          "requiredArtifactLinks": [
+            "approval-packet.md",
+            "message-review.md",
+            "lead-review.md",
+            "brief.md"
+          ],
+          "artifactLinkTiming": "before_commit_gate_question",
           "userFacing": true,
           "doNotUseWords": ["anchor", "validation anchor", "lane"]
         },
@@ -821,7 +853,14 @@
             "lead sample",
             "lead filter",
             "message validation"
-          ]
+          ],
+          "requiredArtifactLinks": [
+            "approval-packet.md",
+            "message-review.md",
+            "lead-review.md",
+            "brief.md"
+          ],
+          "artifactLinkTiming": "same_turn_before_commit_question"
         },
         {
           "action": "ask_commit_choice",