@sellable/mcp 0.1.17 → 0.1.19

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.17 --host codex --token skt_live_your_token_here --workspace-id your_workspace_id
+npx -y @sellable/install@0.1.19 --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.17 --host codex
+npx -y @sellable/install@0.1.19 --host codex
 sellable --verify-only --host codex
 ```
 

package/package.json

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

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

@@ -280,9 +280,46 @@ 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.
 
-- After rendering the brief summary, ask for brief approval when there is a real
+- 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:
+
+  ```text
+  Campaign brief
+
+  Who we are targeting:
+  ...
+
+  Why they should care:
+  ...
+
+  Offer / CTA:
+  ...
+
+  Proof to use:
+  ...
+
+  Lead source hypothesis:
+  ...
+
+  Message angle:
+  ...
+
+  Risks / assumptions:
+  ...
+
+  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 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".
+  Approval options should refer to what the user just read, e.g. `Approve this
+brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
+
 - 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
 reply on LinkedIn. I'll compare source paths by expected volume, likely
@@ -307,6 +344,7 @@ should test for this campaign. Those can run in parallel and usually take
   because the brief becomes the source of truth for the leads and messages. I’ll
   show you the draft next so you can approve it or change it.
   ```
+
 - In hosted/rehearsal runs, `Bash` is only for safe local draft-directory
   housekeeping before approval: `mkdir`, `ls`, `find`, `test`, `pwd`, `echo`,
   `cat`, or copying `brief-v1.md` to `brief.md` inside the repo. Do not use
@@ -480,6 +518,17 @@ Required behavior:
   keyword lanes; it does not mean 492 prospects. The source decision must name
   the actual posts we would use, show why they won, and estimate usable engagers
   from those posts after headline/sample filtering
+- user-facing source logic must use numbers, not vibes. Never write a percentage
+  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`.
+- 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,
+  estimated usable leads, and what is still unknown. Do not wait until the final
+  approval packet to show those numbers.
 - Signals source decisions should prefer fresh posts. Default to posts from the
   last 30 days, prefer the last 7-14 days when quality is comparable, and call
   out any older post as a deliberate tradeoff. Do not hide post age inside the
@@ -508,12 +557,14 @@ Required behavior:
 - validation status: `confirmed`, `rejected`, or `unclear`
 - confidence
 - provider path used
+- search lanes tested, with keyword/filter names and the timeframe used
+- post/result counts by lane for discovery sources
 - supplied source type when applicable (`normal-discovery`,
   `supplied-linkedin-profiles`, `supplied-domains`, or `existing-lead-list`)
 - row/domain counts, invalid counts, duplicate counts, and sample method for
   supplied sources
 - preview count
-- ICP match rate
+- ICP match rate with numerator/denominator and sample basis; never percent-only
 - volume comparison
 - expected LinkedIn funnel: likely connection acceptance range, likely reply
   range, and whether the estimate is sample-backed, historical, founder-supplied,
@@ -523,6 +574,11 @@ Required behavior:
   sampled engager count per selected post, sampled fit count per selected post,
   estimated usable engagers per selected post, and why each selected post is
   better than discarded posts
+- for Signals-first paths: total raw post results by lane, number of finalist
+  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`.
 - source decision: best path, why it won, pros, cons/tradeoffs, and discarded
   source paths with the reason each lost
 - repeated false-positive patterns
@@ -534,6 +590,7 @@ For normal LinkedIn discovery, `lead-review.md` must include these
 customer-visible sections with literal headings:
 
 - `## Source Decision`
+- `## Evidence Snapshot`
 - `## Selected Signal Posts` for Signals-first campaigns
 - `## Expected LinkedIn Funnel`
 - `## Sample Leads` for Signals-first campaigns
@@ -554,6 +611,17 @@ table with one row per selected or finalist post:
 - estimated usable leads
 - why use / why discard
 
+`## Evidence Snapshot` must include a compact numbers-first table:
+
+- source lane / keyword or filter
+- timeframe searched
+- raw results found
+- finalist posts or preview rows reviewed
+- sampled people
+- sampled fits, shown as `n/N (%)`
+- estimated usable people
+- confidence note (`sample-backed`, `directional`, or `needs more sample`)
+
 For Signals-first campaigns, `## Sample Leads` must group representative sample
 rows by source post when possible, so the user can see not just that the search
 found posts, but which posts produce believable prospects.
@@ -565,10 +633,10 @@ directional range and label it `directional`, not definitive.
 
 When showing `lead-review.md` to the user, render the customer-visible sections
 inline. Do not compress it to a short summary or artifact links only. The
-visible response must include `## Source Decision`, `## Expected LinkedIn
-Funnel`, `## Pros`, `## Tradeoffs`, and `## Discarded Paths`. For
-Signals-first campaigns it must also include `## Selected Signal Posts` and
-`## Sample Leads`.
+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`.
 
 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

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

@@ -55,6 +55,10 @@ turn anchored to that:
 8. Ask for approval.
 9. Create the campaign.
 
+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.
+
 ## Progress Updates
 
 Every customer-facing update should answer one of these:
@@ -64,6 +68,34 @@ 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:
+
+- who we are targeting
+- why they should care
+- the offer / CTA
+- proof to use
+- lead source hypothesis
+- message angle
+- risks / assumptions
+- what happens after approval
+
+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:
+
+```text
+I searched 4 signal lanes over the last 30 days. The best 5 posts produced 62
+sampled engagers; 31 looked like real ICP fits, so I’d treat this as directional
+50% sample fit, not a guaranteed audience. That gives us roughly 150-300 likely
+usable people if the remaining engagers behave similarly.
+```
+
+Avoid:
+
+```text
+The sample passed roughly 73% headline fit.
+```
+
 Good:
 
 ```text

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

@@ -213,10 +213,20 @@
         {
           "action": "render_brief_approval_checkpoint",
           "requiredVisibleContent": [
+            "Campaign brief",
+            "Who we are targeting",
+            "Why they should care",
+            "Offer / CTA",
+            "Proof to use",
+            "Lead source hypothesis",
+            "Message angle",
+            "Risks / assumptions",
+            "What happens after approval",
             "approve this brief",
             "revise the brief",
             "then I will find good-fit leads"
           ],
+          "minimumVisibleBriefDetail": "full_readable_brief_before_question",
           "avoidQuestionWhenOnlyUsefulAnswerIs": "looks good"
         },
         {
@@ -267,6 +277,10 @@
             "likely reply rate",
             "signal quality",
             "tradeoffs",
+            "search lanes",
+            "timeframe",
+            "sample size",
+            "estimated usable leads",
             "source decision + sample",
             "before anything goes live"
           ],
@@ -352,6 +366,7 @@
           "artifact": "lead-review.md",
           "renderInlineSections": [
             "## Source Decision",
+            "## Evidence Snapshot",
             "## Selected Signal Posts",
             "## Expected LinkedIn Funnel",
             "## Sample Leads",
@@ -367,9 +382,21 @@
             "engagement or estimated engagers",
             "sampled engagers",
             "sampled fits",
+            "sampled fits as n/N",
             "estimated usable leads",
             "why use or discard"
           ],
+          "evidenceSnapshotRequiredFields": [
+            "source lane or keyword",
+            "timeframe searched",
+            "raw results found",
+            "finalist posts or preview rows reviewed",
+            "sampled people",
+            "sampled fits as n/N (%)",
+            "estimated usable people",
+            "confidence note"
+          ],
+          "forbidPercentOnlyFitRates": true,
           "doNotCompressToSummaryOnly": true,
           "doNotRenderArtifactLinksOnly": true
         },