@sellable/mcp 0.1.47 → 0.1.49

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -96,11 +96,12 @@ confidence basis. Never show a percent like "73% match" without the numerator,
 denominator, and sample basis.
 
 Every approval gate must include artifact access after the readable inline
-content. Show an `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 the
-final approval packet. The links are for deeper inspection; never use them as a
-substitute for showing the content in chat.
+content. Show an `Open artifact:` line with the one key clickable markdown link
+for that stage. Do not show raw filesystem paths unless links cannot be created
+or the user asks. Do this for brief approval, lead-source approval/review,
+lead-filter review, message review, and final approval
+packet. The link is for deeper inspection; never use it as a substitute for
+showing the decision in chat.
 
 Never mention MCP namespaces, prompt chunking, plugin cache paths, missing
 linked skill versions, runbooks, or local skill files in normal customer-facing

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

@@ -135,11 +135,12 @@ Validated draft directory:
   "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.
+  content. Show a short `Open artifact:` line with the one key clickable
+  markdown link for that stage. Do not show raw filesystem paths unless links
+  cannot be created or the user asks. Do this for brief approval, lead-source
+  approval/review, lead-filter review, message review, and final approval
+  packet. Do not use the link as a substitute for rendering the decision in
+  chat; 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:
@@ -327,7 +328,7 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   Campaign brief
 
   Target:
-  ...
+  ... (include concrete role/title names, not just a broad persona)
 
   Core pain:
   ...
@@ -707,14 +708,34 @@ usable leads after filtering, likely connection acceptance range, likely reply
 range, and estimate basis. If exact performance data is unavailable, use a
 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`, `## 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.
+When showing `lead-review.md` to the user, render a slim decision summary in
+chat, not the full evidence table. The visible response must include:
+
+- `Lead source decision`
+- `Chosen source`
+- `Why it won`
+- `Key numbers` with raw volume, sampled fit rate as `n/N`, estimated usable
+  leads, expected connection acceptance range, and expected reply rate range
+- `Sample leads` with 3-5 representative `Name — Title, Company` rows
+- `Tradeoff`
+- `Open artifact: lead-review.md`
+
+Keep `## Evidence Snapshot`, selected posts, discarded paths, full sample rows,
+and `lead-sample.json` details in artifacts. Do not show raw filesystem paths
+unless links cannot be created or the user asks.
+
+After the lead source is set, use this progress copy before the parallel
+filter/message work:
+
+```text
+Lead source is set.
+
+I’m kicking off two workstreams now:
+1. Tighten the fit filter so we only reach out to the right people.
+2. Draft the first message from the approved brief and real sample leads.
+
+These can run in parallel and usually take ~2-3 min.
+```
 
 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
@@ -786,6 +807,29 @@ Required behavior:
 - `Recommendation`
 - `Implementation Details`
 
+When showing the filter result in chat, render a slim summary before moving to
+message review:
+
+```text
+Lead filter
+
+Keep:
+{1-3 lines}
+
+Exclude:
+{1-3 lines}
+
+Why:
+{sample-backed reason}
+
+Expected impact:
+{1 line}
+
+Open artifact: lead-filter.md
+```
+
+Keep production rubric details and `rubric.json` internals in the artifact.
+
 When `rubric.json` is emitted, it must use the production rubric shape, not a
 custom sidecar schema:
 
@@ -826,6 +870,41 @@ Continue chunked-read until `hasMore=false`. Treat all chunks as one prompt load
 
 Do NOT proceed to Step 4 (message review gate) without loading and following the full generate-messages workflow. `message-validation.md` must prove the full workflow ran (all required sections present + raw sendable Selected Winner) before `message-review.md` can recommend `approve-message`. If the message review or approval packet is ready but the generate-messages prompt was not retrieved in this run, route back to message-generation instead of asking the commit gate.
 
+When showing message review in chat, lead with one fully filled sample message,
+not the tokenized template. The visible response must include:
+
+- `Message review`
+- `Subject`
+- `Sample message` with no `{{tokens}}`
+- `Why it should work`
+- `Concern`
+- `Recommendation`
+- `Open artifact: message-review.md`
+
+Keep tokenized templates, token fill basis, rendered examples, good/bad token
+fill examples, validation notes, and `message-validation.md` details in
+artifacts.
+
+## Step 4: Final Approval Packet
+
+When showing the final approval packet, render a slim "ready to create" summary
+in chat. The visible response must include:
+
+- `Ready to create campaign`
+- `Campaign`
+- `Target` with concrete role/title names
+- `Lead source` with one key metric
+- `Filter`
+- `Sample message` with one fully filled sample and no `{{tokens}}`
+- `What approval creates`
+- `Safety`
+- `Open artifact: approval-packet.md`
+
+Keep tokenized templates, evidence tables, rubrics, validation notes, and long
+implementation details in `approval-packet.md`. Do not include
+sequence/settings in the final approval packet; sequence attachment and launch
+settings happen after campaign creation and before the later greenlight.
+
 ## Tail (MANDATORY TOOL ORDER + Steps 13-16 + Threshold Trips + Hard Rules)
 
 The full tail detail (~17k chars: MANDATORY TOOL ORDER, auto-execute-leads, validate-sample loop, auto-execute-messaging, awaiting-user-greenlight, threshold-trip logging, tail hard rules) lives in a dedicated on-demand subskill to keep this entry prompt fast to load.

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

@@ -60,18 +60,16 @@ any approve/revise question, show the relevant decision in plain language. For a
 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
-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.
+After the readable inline content, include an `Open artifact:` line with the one
+key link 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 link is 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
-prospect version, good fill example, good omit example, bad fill example, why
-the bad fill is wrong, token notes, your take, and suggested adjustment first.
-The user should be able to compare "here is the template" against "here is what
-one real prospect would receive" before approving, and understand exactly how
-the tokens should and should not be filled.
+message they cannot see. In chat, show the subject and one fully filled sample
+message with no tokens first. Keep the tokenized template, good fill example,
+good omit example, bad fill example, why the bad fill is wrong, token notes, and
+fallback rules in `message-review.md` / `message-validation.md`.
 
 Every token needs a fallback. If the row does not have clean data for a token,
 the approval view should say whether to use a safe segment-level phrase, omit
@@ -124,6 +122,20 @@ sampled engagers; 31 looked like real ICP fits, so I’d treat this as direction
 usable people if the remaining engagers behave similarly.
 ```
 
+Lead review chat should be short and numeric: chosen source, why it won, raw
+volume, sampled fit rate as `n/N`, estimated good fits, expected connection
+acceptance, expected reply rate, 3-5 sample leads, and one tradeoff. Full tables
+belong in `lead-review.md`.
+
+Lead filter chat should always show what changed: keep, exclude, why, expected
+impact, and `Open artifact: lead-filter.md`.
+
+Final approval chat should be a ready-to-create summary: campaign, target with
+concrete role/title names, lead source, filter, one filled sample message, what
+approval creates, and the safety note that nothing sends live until greenlight.
+Do not include sequence/settings in final approval; that belongs after campaign
+creation.
+
 Avoid:
 
 ```text

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

@@ -365,14 +365,12 @@
           "action": "show_lead_review",
           "artifact": "lead-review.md",
           "renderInlineSections": [
-            "## Source Decision",
-            "## Evidence Snapshot",
-            "## Selected Signal Posts",
-            "## Expected LinkedIn Funnel",
-            "## Sample Leads",
-            "## Pros",
-            "## Tradeoffs",
-            "## Discarded Paths"
+            "Lead source decision",
+            "Chosen source",
+            "Why it won",
+            "Key numbers",
+            "Sample leads",
+            "Tradeoff"
           ],
           "signalsFirstRequiredFields": [
             "post URL",
@@ -397,19 +395,19 @@
             "confidence note"
           ],
           "forbidPercentOnlyFitRates": true,
-          "requiredArtifactLinks": ["lead-review.md", "lead-sample.json"],
+          "requiredArtifactLinks": ["lead-review.md"],
           "artifactLinkTiming": "before_next_step_or_revision_question",
-          "doNotCompressToSummaryOnly": true,
-          "doNotRenderArtifactLinksOnly": true
+          "chatRenderRule": "Show a slim decision summary only: chosen source, why it won, raw volume, sampled fit rate as n/N, estimated usable leads, expected connection acceptance range, expected reply rate range, 3-5 representative sample leads, and one tradeoff. Keep evidence tables, selected posts, discarded paths, full sample rows, and lead-sample.json details in lead-review.md. Do not show plain filesystem paths unless links cannot be created."
         },
         {
           "action": "render_post_lead_parallel_progress",
           "requiredVisibleContent": [
             "Lead source is set",
-            "apply the fit filter",
-            "clean the list down to great fits",
-            "draft the first message we should test",
-            "run in parallel"
+            "kicking off two workstreams",
+            "Tighten the fit filter",
+            "Draft the first message",
+            "approved brief and real sample leads",
+            "parallel"
           ],
           "timeEstimate": "~2-3 min"
         },
@@ -470,6 +468,19 @@
           "artifacts": ["lead-filter.md"],
           "optionalArtifacts": ["rubric.json"]
         },
+        {
+          "action": "show_lead_filter_summary",
+          "artifact": "lead-filter.md",
+          "renderInlineSections": [
+            "Lead filter",
+            "Keep",
+            "Exclude",
+            "Why",
+            "Expected impact"
+          ],
+          "requiredArtifactLinks": ["lead-filter.md"],
+          "chatRenderRule": "Show a slim filter summary before message review: who we keep, who we exclude, sample-backed reason, and expected impact. Keep production rubric fields and rubric.json details in lead-filter.md/rubric.json. Do not show plain filesystem paths unless links cannot be created."
+        },
         {
           "action": "ask_revise_only_if_filter_is_not_confirmed",
           "autoContinueWhen": {
@@ -601,19 +612,15 @@
           "requiredInlineMarker": "Status: message-review",
           "panels": [
             "subject",
-            "tokenized template",
             "sample prospect fill",
             "my take",
-            "suggested adjustment",
+            "concern",
             "question",
             "recommendation"
           ],
           "mustRenderInlineBeforeQuestion": true,
-          "minimumVisibleMessageDetail": "tokenized_template_plus_sample_fill_only",
-          "requiredArtifactLinks": [
-            "message-review.md",
-            "message-validation.md"
-          ],
+          "minimumVisibleMessageDetail": "filled_sample_message_no_tokens",
+          "requiredArtifactLinks": ["message-review.md"],
           "artifactLinkTiming": "before_approval_question",
           "requiredFileLabels": [
             "Subject:",
@@ -635,15 +642,13 @@
           "requiredChatLabels": [
             "Status: message-review",
             "Subject:",
-            "Tokenized template:",
             "Sample prospect fill:",
-            "Token fill basis:",
             "My take:",
-            "Suggested adjustment:",
+            "Concern:",
             "Question: approve-message or revise-messaging?",
             "Recommendation:"
           ],
-          "chatRenderRule": "Show ONLY the tokenized template and one filled sample prospect version (with Token fill basis), then My take, Suggested adjustment, Question, Recommendation, and Open artifacts links. Do NOT inline Rendered examples, Good token fill, Good omit, Bad token fill, Why bad, Fallback if missing, or Token notes — those live in message-review.md and message-validation.md only.",
+          "chatRenderRule": "Show one fully filled sample message with no {{tokens}} before asking for approval. Include subject, sample message, why it should work, one concern or None, recommendation, and Open artifact: message-review.md. Keep tokenized template, token fill basis, rendered examples, good/bad token fill examples, validation notes, and message-validation.md details in artifacts. Do not show plain filesystem paths unless links cannot be created.",
           "allowedRecommendations": ["approve-message", "revise-messaging"],
           "judgeAgainst": [
             "generate-messages rules",
@@ -676,11 +681,9 @@
           "questionPrerequisiteVisibleLabels": [
             "Status: message-review",
             "Subject:",
-            "Tokenized template:",
             "Sample prospect fill:",
-            "Token fill basis:",
             "My take:",
-            "Suggested adjustment:",
+            "Concern:",
             "Recommendation:"
           ],
           "forbiddenWhenMissingVisibleMessage": true,
@@ -761,19 +764,15 @@
           "mustRenderInlineBeforeCommitGate": true,
           "panels": [
             "campaign direction",
-            "lead source and sample",
-            "filters and rubrics",
-            "message review",
-            "messages",
-            "risks and next action"
-          ],
-          "requiredArtifactLinks": [
-            "approval-packet.md",
-            "message-review.md",
-            "lead-review.md",
-            "brief.md"
+            "lead source",
+            "filter",
+            "sample message",
+            "what approval creates"
           ],
+          "minimumVisibleDetail": "slim_final_approval_summary",
+          "requiredArtifactLinks": ["approval-packet.md"],
           "artifactLinkTiming": "before_commit_gate_question",
+          "chatRenderRule": "Show a slim final approval packet only. Include target with concrete role/title names, lead source with one key metric, filter summary, one fully filled sample message with no {{tokens}}, what approval creates, and safety note that nothing sends live until the review/greenlight step. Keep tokenized templates, evidence tables, rubrics, and validation details in approval-packet.md. Do not show sequence/settings in final approval; that comes after campaign creation. Do not show plain filesystem paths unless links cannot be created.",
           "userFacing": true,
           "doNotUseWords": ["anchor", "validation anchor", "lane"]
         },
@@ -865,17 +864,14 @@
           "requiredInlineMarker": "Status: approval-packet",
           "sameTurnAsCommitQuestion": true,
           "panels": [
-            "brief",
-            "lead sample",
-            "lead filter",
-            "message validation"
-          ],
-          "requiredArtifactLinks": [
-            "approval-packet.md",
-            "message-review.md",
-            "lead-review.md",
-            "brief.md"
+            "campaign direction",
+            "lead source",
+            "filter",
+            "sample message",
+            "what approval creates"
           ],
+          "requiredArtifactLinks": ["approval-packet.md"],
+          "chatRenderRule": "Same slim approval packet as approval-packet. Include target with concrete role/title names and one fully filled sample message without tokens. Do not include sequence/settings. Do not repeat tokenized template or long evidence tables in chat.",
           "artifactLinkTiming": "same_turn_before_commit_question"
         },
         {

package/skills/create-campaign-v2/core/policy.md

@@ -59,6 +59,8 @@ lead-filter.md
 message-prep.md (optional)
 message-candidate-drafts.md (optional, generated from find-leads basis rows)
 message-validation.md
+message-review.md
+message-review-decision.md
 approval-packet.md
 commit-gate-decision.md
 ```

package/skills/create-campaign-v2/references/approval-gate-framing.md

@@ -121,29 +121,33 @@ rerun `$sellable:create-campaign`. A normal chat question is acceptable only for
 non-interactive `codex exec` smoke/rehearsal runs because structured user input
 is unavailable by design there.
 
-The packet should read like an AI GTM engineer explaining the campaign, not an
-internal validation report. Start with the practical direction in plain
-language: who we will contact, why this buyer should care, what lead source we
-will use, what the first message says, and what happens if the user approves.
-Keep implementation details available, but move them below the customer-facing
-summary.
-
-1. **brief** — `brief.md` thesis, product, ICP, offer
-2. **lead sample** — first 5-10 rows from `lead-sample.json` rendered as
-   `Name / Title / Company` lines, plus the `lead-review.md` pass-rate
-   and supplied-source framing when `lead-source-intake.json` exists:
-   supplied people list, existing Sellable lead list, or supplied account list
-   plus people search
-3. **lead filter** — the `Decision`, `Who We'll Keep`, `Who We'll Exclude`,
-   `Pass Rate`, and `Recommendation` blocks from `lead-filter.md`; keep
-   rubric internals in `Implementation Details` unless the user asks to inspect
-   the saved filter criteria
-4. **message validation** — the `Selected Winner` from `message-validation.md`,
-   rendered as it will appear in the outbound, plus the `Findings` + `Recommendation`
-
-The packet must include a dedicated `## Message Review` section immediately
-before `## Approved Message Template`. This is the customer-facing messaging
-gate. It should not be a raw validation dump; it should answer:
+The packet should read like an AI GTM engineer asking for one final creation
+decision, not an internal validation report. Chat should show a slim approval
+surface only:
+
+1. **campaign** — company + sender
+2. **target** — concise ICP summary from `brief.md`, including concrete
+   role/title names so the user can verify we are aiming at the right buyers
+3. **lead source** — selected source plus one key metric from `lead-review.md`
+   (for example `17/25 sampled fits`, `520 active profiles`, or estimated usable
+   leads). Put the full evidence table in `lead-review.md`, not chat.
+4. **filter** — one-line keep/exclude summary from `lead-filter.md`
+5. **sample message** — one fully filled sample message with no `{{tokens}}`
+6. **what approval creates** — campaign draft + review batch preparation, not
+   live sending
+
+Do not include sequence/settings in the pre-mint final approval packet. Sequence
+attachment and launch settings happen after campaign creation and before the
+later greenlight.
+
+Keep implementation details, tokenized templates, lead tables, rubric JSON, and
+validation notes available in `approval-packet.md` and the supporting artifacts.
+Do not show raw filesystem paths unless links cannot be created or the user asks.
+Use one normal chat link: `Open artifact: approval-packet.md`.
+
+The packet artifact must include a dedicated `## Message Review` section
+immediately before `## Approved Message Template`. This is the customer-facing
+messaging gate. It should not be a raw validation dump; it should answer:
 
 - `Verdict:` strong / usable-but-could-improve / needs-revision
 - `What works:` why the message is likely to earn replies
@@ -163,6 +167,10 @@ message from the brief. If no winner/template can be extracted, this exact-match
 gate is skipped, but the packet still needs a usable approved template unless
 the user explicitly chose AI-generated messages.
 
+The chat render must not lead with `## Approved Message Template` or token fill
+rules. Show one filled sample first. The artifact can contain the tokenized
+template and fill basis.
+
 Do NOT render the packet as a bundle of opaque validation anchors or a dump
 of raw JSON. The user is approving a live campaign — they need to see what
 they are approving.