@sellable/mcp 0.1.46 → 0.1.48

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.46",
+  "version": "0.1.48",
   "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, sequence/settings, 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

@@ -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 /
@@ -56,6 +56,7 @@ Validated draft directory:
   lead-review.md
   lead-sample.json
   lead-filter.md
+  sequence-settings.md
   message-prep.md   # optional speed artifact
   message-candidate-drafts.md   # optional provisional message artifact
   message-validation.md
@@ -135,11 +136,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, sequence/settings, 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:
@@ -317,7 +319,7 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   persistence in this preamble.
 
 - 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
+  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
@@ -357,7 +359,7 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   brief, include only:
 
   ```text
-  Open artifacts: [brief-v1.md] and [brief.md]
+  Open artifact: [brief.md]
   ```
 
   If clickable links cannot be created, show one compact fallback line:
@@ -377,8 +379,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
@@ -412,11 +413,20 @@ 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`.
+- `sequence-settings.md` is a cheap pre-mint preview artifact. It summarizes
+  recommended sequence/settings for the user's approval packet. It must not call
+  sequence tools or rerun research; actual sequence attachment still happens
+  after campaign creation via `attach_recommended_sequence`.
 - `message-prep.md` is an optional speed artifact produced by the explicit
   message path after find-leads. It can prepare proof inventory, buyer
   objections, CTA options, gold-standard strategy maps, and candidate angles
@@ -703,14 +713,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
@@ -782,6 +812,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:
 
@@ -822,6 +875,68 @@ 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: Sequence + Settings Preview
+
+Before the final approval packet, write a cheap `sequence-settings.md` preview.
+This is a planning artifact only. Do not call `attach_sequence` or
+`attach_recommended_sequence` here, and do not rerun research or message
+generation. Actual sequence attachment happens after campaign creation at
+`awaiting-user-greenlight`.
+
+Show this slim chat summary:
+
+```text
+Sequence + settings
+
+Recommended sequence:
+Recommended LinkedIn sequence based on the connected sender’s tier and limits.
+
+Review batch:
+First review batch only.
+
+Launch state:
+Paused / review-gated. Nothing sends live until final greenlight.
+
+Safety checks:
+Sender and workspace will be checked again before start.
+
+Open artifact: sequence-settings.md
+```
+
+## Step 5: 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`
+- `Lead source` with one key metric
+- `Filter`
+- `Sample message` with one fully filled sample and no `{{tokens}}`
+- `Sequence/settings`
+- `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`.
+
 ## 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
@@ -94,9 +92,10 @@ Every customer-facing update should answer one of these:
 - What is protected until approval?
 
 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:
+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
@@ -123,6 +122,18 @@ 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, lead
+source, filter, sequence/settings, one filled sample message, what approval
+creates, and the safety note that nothing sends live until greenlight.
+
 Avoid:
 
 ```text

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"
         },
@@ -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,
@@ -724,11 +727,60 @@
       "watchRequired": false,
       "waitFor": ["message_approved", "revise_messaging"],
       "transitions": {
-        "message_approved": "approval-packet",
+        "message_approved": "sequence-settings-preview",
         "revise_messaging": "message-generation"
       },
       "interruptOnly": true
     },
+    {
+      "id": "sequence-settings-preview",
+      "label": "Sequence and settings preview",
+      "normalFlow": true,
+      "resumeOnly": false,
+      "onEnter": [
+        {
+          "action": "write_sequence_settings_preview",
+          "artifact": "sequence-settings.md",
+          "requiredInlineMarker": "Status: sequence-settings-preview",
+          "inputs": ["brief.md", "lead-review.md", "lead-filter.md", "message-review.md"],
+          "mustBeFast": true,
+          "doNotCallTailTools": true,
+          "requiredSections": [
+            "Recommended sequence",
+            "Review batch",
+            "Launch state",
+            "Safety checks"
+          ],
+          "chatRenderRule": "Show a slim sequence/settings summary: recommended LinkedIn sequence based on connected sender tier and limits, first review batch only, paused/review-gated launch state, nothing sends live until final greenlight, and sender/workspace checked again before start. Keep any details in sequence-settings.md. Do not show plain filesystem paths unless links cannot be created."
+        }
+      ],
+      "requiredArtifacts": [
+        "brief.md",
+        "lead-review.md",
+        "lead-filter.md",
+        "message-review.md",
+        "message-review-decision.md"
+      ],
+      "producesArtifacts": ["sequence-settings.md"],
+      "allowedTools": ["AskUserQuestion", "request_user_input"],
+      "doNotAllow": [
+        "attach_sequence",
+        "attach_recommended_sequence",
+        "create_campaign",
+        "save_rubrics",
+        "import_leads",
+        "confirm_lead_list",
+        "update_campaign",
+        "queue_cells",
+        "start_campaign"
+      ],
+      "watchRequired": false,
+      "waitFor": "sequence_settings_ready",
+      "transitions": {
+        "sequence_settings_ready": "approval-packet"
+      },
+      "interruptOnly": true
+    },
     {
       "id": "approval-packet",
       "label": "Approval packet",
@@ -744,7 +796,8 @@
             "lead-filter.md",
             "message-validation.md",
             "message-review.md",
-            "message-review-decision.md"
+            "message-review-decision.md",
+            "sequence-settings.md"
           ],
           "optionalFiles": ["rubric.json"]
         },
@@ -761,19 +814,16 @@
           "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",
+            "sequence and settings",
+            "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, lead source with one key metric, filter summary, sequence/settings 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 plain filesystem paths unless links cannot be created.",
           "userFacing": true,
           "doNotUseWords": ["anchor", "validation anchor", "lane"]
         },
@@ -791,7 +841,8 @@
         "lead-filter.md",
         "message-validation.md",
         "message-review.md",
-        "message-review-decision.md"
+        "message-review-decision.md",
+        "sequence-settings.md"
       ],
       "producesArtifacts": ["approval-packet.md"],
       "optionalProducesArtifacts": ["customer-roleplay.md"],
@@ -865,17 +916,15 @@
           "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",
+            "sequence and settings",
+            "sample message",
+            "what approval creates"
           ],
+          "requiredArtifactLinks": ["approval-packet.md"],
+          "chatRenderRule": "Same slim approval packet as approval-packet. Include one fully filled sample message without tokens. 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,9 @@ 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
+sequence-settings.md
 approval-packet.md
 commit-gate-decision.md
 ```

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

@@ -121,29 +121,32 @@ 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`
+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. **sequence/settings** — conservative defaults from `sequence-settings.md`:
+   recommended sequence, first review batch, paused/review-gated launch state,
+   nothing sends live until greenlight, sender/workspace checked again before
+   start
+6. **sample message** — one fully filled sample message with no `{{tokens}}`
+7. **what approval creates** — campaign draft + review batch preparation, not
+   live sending
+
+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 +166,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.