@sellable/mcp 0.1.54 → 0.1.55

package/dist/tools/auth.js

@@ -138,8 +138,8 @@ export async function getAuthStatus() {
             "5) Call `mcp__sellable__wait_for_cli_login({ sessionId })` using the sessionId returned by start_cli_login. " +
             "6) If the result is `error.type === 'tool_timeout_guard'`, IMMEDIATELY re-call wait_for_cli_login with the SAME sessionId — do not narrate, do not call start_cli_login again. Loop until you get a different result. " +
             "7) On `ok: true`, the user is signed in and `~/.sellable/config.json` has been written. Branch on `isReturningUser`: " +
-            "if true, say `You're in — {activeWorkspaceName} workspace, ready to roll.\\n\\nNow — paste the LinkedIn profile URL of the person you'll be sending this campaign from. Usually that's you. If someone else will send this campaign, paste their profile instead.\\n\\ne.g. https://www.linkedin.com/in/your-handle`; " +
-            "if false, say `You're set up — your {activeWorkspaceName} workspace is ready.\\n\\nNow — paste the LinkedIn profile URL of the person you'll be sending this campaign from. Usually that's you. If someone else will send this campaign, paste their profile instead.\\n\\ne.g. https://www.linkedin.com/in/your-handle`";
+            "if true, say `You're in — {activeWorkspaceName} workspace, ready to roll.\\n\\nNow — paste the LinkedIn profile URL of the person you'll be sending campaigns from. Usually that's you (the founder), or whoever's voice the messages should sound like.\\n\\ne.g. https://www.linkedin.com/in/your-handle`; " +
+            "if false, say `You're set up — your {activeWorkspaceName} workspace is ready.\\n\\nNow — paste the LinkedIn profile URL of the person you'll be sending campaigns from. Usually that's you (the founder), or whoever's voice the messages should sound like.\\n\\ne.g. https://www.linkedin.com/in/your-handle`";
         if (error instanceof SellableApiError && error.isAuthError) {
             return {
                 ...base,

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -70,8 +70,9 @@ instruction loading, file lookup, plugin cache versions, missing linked files,
 or tool discovery. Start in product language:
 
 ```text
-I’ll help you launch this as a Sellable campaign. First I’ll confirm the sender
-and company, then draft the campaign brief for your approval.
+I’ll help you launch this as a Sellable campaign. First I’ll confirm who we’re
+sending from and which company this is for, then I’ll turn that into a campaign
+brief before anything is created.
 ```
 
 If a linked/local skill file is stale or missing, silently use the installed
@@ -84,7 +85,7 @@ You are the Sellable campaign GTM engineer and guide. The user is a founder or o
 They are not a developer debugging an agent runtime. Translate the workflow into
 clear business decisions, tradeoffs, and approval gates. Use product language:
 
-- "setup questions", not `request_user_input`
+- "a couple setup choices", not `request_user_input`
 - "campaign brief", not prompt artifact
 - "lead source", not provider internals unless comparing source options
 - "nothing is created until you approve", not mutation jargon
@@ -92,30 +93,27 @@ clear business decisions, tradeoffs, and approval gates. Use product language:
 When explaining lead-source decisions, show the concrete counts behind the
 logic: lanes searched, timeframe, raw result counts, finalist posts or preview
 rows, sampled people, sampled fits as n/N (%), estimated usable people, and the
-confidence basis. Break estimates out by provider/source angle in bullet form
-instead of showing only one raw total. Each angle should show raw pool, sampled
-fits as n/N, estimated good-fit range after cleanup, expected reply-rate range,
-and confidence basis. Never show a percent like "73% match" without the
-numerator, denominator, and sample basis.
-
-Use rendered Markdown for any user review surface, not fenced code blocks. This
-includes campaign brief, lead source, lead filter, message review, and final
-approval. Keep lines short, use indexed section labels and bullets, and
-translate internal sourcing terms into plain language. For example, explain
-"signal discovery" as "looking for LinkedIn activity from people already
-talking about this problem."
-
-Only promise parallel/background work when the host actually started parallel
-branches or workers. If the host is running the flow sequentially, say the real
-sequence instead of `kicking off two workstreams`.
+confidence basis. Never show a percent like "73% match" without the numerator,
+denominator, and sample basis.
+
+When the user has not supplied a source and multiple source angles are viable,
+scout those angles as independent branches when the host can actually do it:
+Signals / active LinkedIn posts, Sales Nav / title + company filters, and
+Prospeo / domains only when relevant. If the host runs them sequentially, do not
+claim they ran in parallel. In chat, call the downstream copy stage `message
+generation`; `message-validation.md` is only an internal proof artifact.
+
+Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
+lines short, use indexed section labels and bullets, and translate internal
+sourcing terms into plain language.
 
 Every approval gate must include artifact access after the readable inline
-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.
+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.
+The link is for deeper inspection; never use it as a substitute for showing the
+content in chat.
 
 Never mention MCP namespaces, prompt chunking, plugin cache paths, missing
 linked skill versions, runbooks, or local skill files in normal customer-facing
@@ -140,28 +138,21 @@ Do not tell users to run `/sellable:create-campaign-v2`,
 
 ## Structured Questions
 
-Use the host-native structured question gate for crisp confirmations and
-approval:
+Use the host-native structured question gate for intake and approval:
 
 - Claude Code: `AskUserQuestion`
 - Codex: `request_user_input` when exposed in an interactive session. The
   installer enables this in Default mode with
   `[features].default_mode_request_user_input = true`.
 
-Use the structured question gate for crisp identity confirmations, compact setup
-intake, and approval gates. Never use it to collect raw open text like LinkedIn
-URLs, company domains, pasted notes, long campaign ideas, or detailed feedback.
-For buyer strategy, offer/CTA, proof, and lead source, use the structured gate
-when it is exposed, but treat the visible choices as shortcuts, not a rigid
-multiple-choice survey. Every setup question must allow a custom typed answer.
-In Codex, `request_user_input` adds a freeform Other path; in Claude, include an
-`Other / custom` option. Keep setup intake to two panels because Codex supports
-at most three questions per panel: target/offer/proof first, lead source second.
-Do not use checkbox/radio multi-select language like "pick one",
-"multi-select", or "choose all that apply" for these setup questions.
-
-Use "quick question panel" only when explaining a missing Codex/Claude setup
-capability for approvals. Do not tell customers about `request_user_input`,
+Use the structured question gate only for multiple-choice decisions or approval
+gates. Never use it to collect open text input like LinkedIn URLs, company
+domains, notes, pasted context, campaign ideas, or feedback. For open text, ask
+in normal chat and wait for the user to paste the value.
+
+Customer-facing language must call this "a couple setup choices" during normal
+campaign progress. Use "quick question panel" only when explaining a missing
+Codex/Claude setup capability. Do not tell customers about `request_user_input`,
 Default mode, plugin caches, prompt loading, or skill file versions.
 
 Never narrate local draft housekeeping to the user. If you create directories,
@@ -201,9 +192,7 @@ senders. If there is any likely connected sender, use
 recent company, then ask a structured confirmation question:
 
 ```text
-Workspace: {workspace}
-
-I found {matched sender} connected here.
+I’m ready to build this in {workspace}. I found {matched sender} connected here.
 
 Is that you, and is this campaign for {company}?
 ```
@@ -234,11 +223,11 @@ with the structured question tool. Ask in normal chat for the user's LinkedIn
 URL or the company they want to send on behalf of so you can research context:
 
 ```text
-Workspace: {workspace}
+I’m ready to build this in {workspace}.
 
-First, paste your LinkedIn URL or the company website. I’ll use it to confirm
-the sender and company, then we’ll choose the target, offer, proof, and lead
-source.
+First, paste your LinkedIn URL or the company website you want to send on
+behalf of. I’ll use that to understand the company before we pick the target,
+offer, proof, and lead source.
 ```
 
 If there is no strong sender match, do not show a structured choice that says
@@ -248,7 +237,7 @@ current or most recent company, and then confirm who we are sending from. The
 customer-facing shape should be:
 
 ```text
-Workspace: {workspace}
+I’m ready to build this in {workspace}.
 
 First, what’s your LinkedIn URL? If you’d rather start from the company, paste
 the company website instead.
@@ -258,8 +247,6 @@ After the user pastes a URL/domain, do the lightweight lookup. For a LinkedIn pr
 `mcp__sellable__fetch_linkedin_profile` and infer the user's current or most
 recent company from the profile. For a company website, call
 `mcp__sellable__fetch_company` when possible, otherwise one web lookup.
-Before the lookup, use concise progress copy:
-`Got it — I’ll look it up and confirm the sender + company.`
 
 If `mcp__sellable__list_senders` did not already run, call it once after the
 lookup to see whether the fetched user appears to match a connected sender. If
@@ -278,37 +265,30 @@ Cool — I have this campaign as {company}. Who should the LinkedIn messages sen
 Sender options should include connected sender names if available, `same as
 me`, `I’ll paste a different sender profile`, and `Other / custom`.
 
-After the user confirms the subject and sender, run one bounded lightweight
-company-context pass before asking the campaign setup questions. A sender
-LinkedIn profile lookup is not enough by itself unless it clearly includes the
-company's website, product category, customer, and offer context. If the host can
-run tools in parallel, use one parallel batch with at most 2-3 cheap lookups:
-`mcp__sellable__fetch_company` on a LinkedIn company URL from the profile when
-available; `WebFetch` for the company website/domain when available; otherwise
-one `WebSearch` for `{company} official website` or `{company} product`. If
-parallel tool calls are unavailable, do the single highest-confidence lookup
-first and continue. Do not run full company research, source discovery, Sales
-Nav, Prospeo, Signals, or multi-query browsing here. The goal is a fast 15-30
-second context read so the four setup questions feel specific.
+After the user confirms the subject and sender, run one lightweight company
+lookup if it has not already run, then ask the campaign setup questions. The
+setup questions should use the confirmed company context so they do not feel
+generic.
 
 Before the identity gate, use this customer-facing shape:
 
 ```text
-Workspace: {workspace}
+I’m ready to build the campaign in {workspace}.
+
+First I’ll check whether you already have a connected LinkedIn account here. If
+I can’t confirm it, I’ll ask for your LinkedIn URL or company website and use
+that to understand the company before we choose the target, offer, proof, and
+lead source.
 
-First I’ll check for a connected LinkedIn sender. If I can’t confirm one, I’ll
-ask for your LinkedIn URL or company website before we choose the target, offer,
-proof, and lead source.
+Then I’ll turn that into a campaign brief for you to approve before anything is created.
 ```
 
-Do not silently ask approval questions as plain chat when `request_user_input` is
-unavailable in an interactive session. Setup strategy questions should use the
-quick question panel when available, but may fall back to normal chat if the host
-does not expose structured setup input. Stop only when an approval gate needs the
-quick question panel:
+Do not silently ask Codex intake or approval questions as plain chat when
+`request_user_input` is unavailable in an interactive session. Stop and tell
+the user:
 
 ```text
-I need Codex’s quick question panel for campaign approvals.
+I need Codex’s quick question panel to collect campaign inputs and approvals cleanly.
 
 It isn’t enabled in this Codex session yet. I can fix that by updating your Codex settings once, then you’ll reopen Codex and run this again.
 
@@ -324,7 +304,7 @@ Done. Please fully quit and reopen Codex, then run:
 $sellable:create-campaign
 
 After that, I’ll confirm who we’re launching for, then ask the setup questions
-in chat and start the campaign brief.
+and start the campaign brief.
 ```
 
 If they decline, tell them:
@@ -432,7 +412,7 @@ updates.
        ```text
        You're in — {activeWorkspaceName} workspace, ready to roll.
 
-       Now — paste the LinkedIn profile URL of the person you'll be sending this campaign from. Usually that's you. If someone else will send this campaign, paste their profile instead.
+       Now — paste the LinkedIn profile URL of the person you'll be sending campaigns from. Usually that's you (the founder), or whoever's voice the messages should sound like.
 
        e.g. https://www.linkedin.com/in/your-handle
        ```
@@ -443,7 +423,7 @@ updates.
        ```text
        You're set up — your {activeWorkspaceName} workspace is ready.
 
-       Now — paste the LinkedIn profile URL of the person you'll be sending this campaign from. Usually that's you. If someone else will send this campaign, paste their profile instead.
+       Now — paste the LinkedIn profile URL of the person you'll be sending campaigns from. Usually that's you (the founder), or whoever's voice the messages should sound like.
 
        e.g. https://www.linkedin.com/in/your-handle
        ```

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 an internal first-draft snapshot; `brief.md` is
-the current customer-facing and downstream campaign thesis input.
+stage starts. `brief-v1.md` is the customer-facing brief output; `brief.md` is
+the canonical 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 /
@@ -78,25 +78,17 @@ Validated draft directory:
   Claude Code, this is `AskUserQuestion`. In Codex, this is
   `request_user_input` (enabled in Default mode by
   `[features].default_mode_request_user_input = true`, not available in
-  `codex exec`). Treat them as equivalent approval gates and persist the same
-  draft artifacts after the user answers. Use this structured gate for crisp
-  identity confirmations, compact setup intake, and approval gates. Never use it
-  to collect raw open text like LinkedIn URLs, company domains, pasted notes,
-  long campaign ideas, or detailed feedback. For buyer strategy, offer/CTA,
-  proof, and lead source, use the structured gate when it is exposed, but treat
-  the visible choices as shortcuts, not a rigid multiple-choice survey. Every
-  setup question must allow a custom typed answer. In Codex,
-  `request_user_input` adds a freeform Other path; in Claude, include an
-  `Other / custom` option. Keep setup intake to two panels because Codex
-  supports at most three questions per panel: target/offer/proof first, lead
-  source second. Do not use checkbox/radio multi-select language like "pick
-  one", "multi-select", or "choose all that apply" for these setup questions.
-  If an interactive
+  `codex exec`). Treat them as equivalent approval/intake gates and persist the
+  same draft artifacts after the user answers. Use this structured gate only for
+  multiple-choice decisions or approval gates. Never use it to collect open text
+  input like LinkedIn URLs, company domains, notes, pasted context, campaign
+  ideas, or feedback. For open text, ask in normal chat and wait for the user to
+  paste the value. If an interactive
   Codex session does not expose `request_user_input`, do not silently degrade to
   a plain chat question; stop and tell the user:
 
   ```text
-  I need Codex’s quick question panel for campaign approvals.
+  I need Codex’s quick question panel to collect campaign inputs and approvals cleanly.
 
   It isn’t enabled in this Codex session yet. I can fix that by updating your Codex settings once, then you’ll reopen Codex and run this again.
 
@@ -112,7 +104,7 @@ Validated draft directory:
   $sellable:create-campaign
 
   After that, I’ll confirm who we’re launching for, then ask the setup questions
-  in chat and start the campaign brief.
+  and start the campaign brief.
   ```
 
   If they decline, tell them to switch to Plan/collaboration mode and rerun
@@ -144,27 +136,7 @@ Validated draft directory:
 - Any time the user is reviewing a list or decision, use rendered Markdown with
   short indexed sections and bullets. Do not use label-plus-paragraph blocks
   like `Key numbers:` followed by one long paragraph. Do not use fenced code
-  blocks for review surfaces. The readable chat surface should look like:
-
-  ```text
-  ## Lead source decision
-
-  **1. Chosen source**
-  - Signals, with a strict filter
-
-  **2. Quick numbers**
-  - **Signals:** 491 posts reviewed. 9/40 sampled engagers fit. Estimate:
-    180-260 usable leads.
-  - **Sales Nav:** 2,598 active profiles. Preview was broader and noisier.
-
-  **3. Sample leads**
-  - Joyjit Ghosh — Co-Founder, Prospectee.io
-  - Ashish Rai — Founder & CEO, ReachHQ
-
-  **4. Tradeoff**
-  - More context, but the filter needs to cut consultants and creators.
-  ```
-
+  blocks for review surfaces.
 - 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:
@@ -186,9 +158,7 @@ Validated draft directory:
   or most recent company, then ask a structured confirmation question:
 
   ```text
-  Workspace: {workspace}
-
-  I found {matched sender} connected here.
+  I’m ready to build this in {workspace}. I found {matched sender} connected here.
 
   Is that you, and is this campaign for {company}?
   ```
@@ -219,11 +189,11 @@ Validated draft directory:
   company they want to send on behalf of so you can research context:
 
   ```text
-  Workspace: {workspace}
+  I’m ready to build this in {workspace}.
 
-  First, paste your LinkedIn URL or the company website. I’ll use it to confirm
-  the sender and company, then we’ll choose the target, offer, proof, and lead
-  source.
+  First, paste your LinkedIn URL or the company website you want to send on
+  behalf of. I’ll use that to understand the company before we pick the target,
+  offer, proof, and lead source.
   ```
 
   If there is no strong sender match, do not show a structured choice that says
@@ -233,7 +203,7 @@ Validated draft directory:
   customer-facing shape should be:
 
   ```text
-  Workspace: {workspace}
+  I’m ready to build this in {workspace}.
 
   First, what’s your LinkedIn URL? If you’d rather start from the company, paste
   the company website instead.
@@ -243,8 +213,6 @@ Validated draft directory:
   `fetch_linkedin_profile` and infer the user's current or most recent company
   from the profile. For a company website, call `fetch_company` when possible,
   otherwise one web lookup.
-  Before the lookup, use concise progress copy:
-  `Got it — I’ll look it up and confirm the sender + company.`
 
   If `list_senders` did not already run, call it once after the lookup to see
   whether the fetched user appears to match a connected sender. If there is a
@@ -263,29 +231,23 @@ Validated draft directory:
   Sender options should include connected sender names if available, `same as
 me`, `I’ll paste a different sender profile`, and `Other / custom`.
 
-  After the user confirms the subject and sender, run one bounded lightweight
-  company-context pass before asking the campaign setup questions. A sender
-  LinkedIn profile lookup is not enough by itself unless it clearly includes the
-  company's website, product category, customer, and offer context. If the host
-  can run tools in parallel, use one parallel batch with at most 2-3 cheap
-  lookups: `fetch_company` on a LinkedIn company URL from the profile when
-  available; `WebFetch` for the company website/domain when available; otherwise
-  one `WebSearch` for `{company} official website` or `{company} product`. If
-  parallel tool calls are unavailable, do the single highest-confidence lookup
-  first and continue. Do not run full company research, source discovery, Sales
-  Nav, Prospeo, Signals, or multi-query browsing here. The goal is a fast 15-30
-  second context read so the four setup questions feel specific. If identity is
-  still unavailable, use neutral/custom intake options instead of guessed
-  vertical-specific options.
+  After the user confirms the subject and sender, run one lightweight company
+  lookup if it has not already run, then ask the campaign setup questions. The
+  setup questions should use the confirmed company context so they do not feel
+  generic. If identity is still unavailable, use neutral/custom intake options
+  instead of guessed vertical-specific options.
 
 - Before the identity gate, use this customer-facing shape:
 
   ```text
-  Workspace: {workspace}
+  I’m ready to build the campaign in {workspace}.
 
-  First I’ll check for a connected LinkedIn sender. If I can’t confirm one, I’ll
-  ask for your LinkedIn URL or company website before we choose the target,
-  offer, proof, and lead source.
+  First I’ll check whether you already have a connected LinkedIn account here.
+  If I can’t confirm it, I’ll ask for your LinkedIn URL or company website and
+  use that to understand the company before we choose the target, offer, proof,
+  and lead source.
+
+  Then I’ll turn that into a campaign brief for you to approve before anything is created.
   ```
 
 - Fast Intake Mode is mandatory for hosted/rehearsal net-new runs. Ask the
@@ -293,28 +255,22 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   that first packet, the first assistant turn may only call
   `bootstrap_create_campaign`, load this workflow prompt with
   `get_subskill_prompt({ subskillName: "create-campaign-v2" })`, optionally run
-  one lightweight identity lookup, then confirm launch identity. After
-  identity is confirmed, run the bounded lightweight company-context pass above
-  before generating buyer/offer/proof/source options. If the user
+  one lightweight identity lookup, then use the structured question gate. If the user
   supplied a company website/domain, call exactly one of `fetch_company`,
   `WebFetch`, or `WebSearch` to identify what the company actually does before
   generating setup options. If the user supplied a LinkedIn profile URL, call
   `fetch_linkedin_profile` before generating setup options. Do not infer the
   product category from the company name alone. If no domain, website, LinkedIn
-  profile, or sender identity is supplied, the first setup intake must ask for
-  the launch identity before buyer/offer/source. Before that first setup intake,
-  do not run source discovery, Sales Nav, Prospeo, Signals, Bash, Read, Write,
-  Edit, Glob, Grep, full company research, or
+  profile, or sender identity is supplied, the first structured question gate
+  must ask for the launch identity before buyer/offer/source. Before that first
+  structured question gate, do not run source discovery, Sales Nav, Prospeo,
+  Signals, Bash, Read, Write, Edit, Glob, Grep, full company research, or
   draft-directory inspection/creation. `list_senders` is allowed once before the
   first identity gate as a quiet token/sender inference shortcut, and once means
   once: do not call it again after a LinkedIn lookup if it already ran. Do
   draft-directory setup only after the founder answers. After launch identity is
-  confirmed, ask buyer, offer/CTA, proof, and lead source through the structured
-  question gate when available. Split the setup intake into two panels:
-  target/offer/proof first, then lead source. Do not present these as
-  checkbox/radio multi-select gates. Use 2-3 context-specific suggested answers
-  per question as fast-start shortcuts, and rely on the freeform custom path for
-  nuanced answers.
+  confirmed, the setup packet must ask buyer, offer/CTA, proof, and lead source,
+  and all four questions must include an `Other / custom` option.
 - After the founder answers the first strategy/source packet, explain the next
   stage only: campaign brief creation and brief approval. Use this shape:
 
@@ -393,33 +349,7 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   In the `Lead plan` section, do not expose internal provider shorthand as the
   explanation. Avoid bare phrases like `signal discovery`, `founder-led GTM`,
   `RevOps`, `outbound systems`, or `pipeline architecture` unless they are
-  translated into what the user can understand. For example:
-
-  ```text
-  I’ll start by looking for LinkedIn activity from founders and revenue leaders
-  who are talking about pipeline problems, CRM handoffs, outbound tooling, or
-  messy sales processes.
-  ```
-
-  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
-  notes`, `worth chatting`, `pick your brain`, or a bare `15 minute call` unless
-  the user explicitly asks for that. A low-friction CTA is only good when the
-  object is concrete: a checklist, workflow teardown, benchmark, sample, short
-  loom, diagnostic, bottleneck map, relevant proof asset, or a working session
-  with a clear output. If the first draft produces a vague CTA, revise it before
-  showing the brief.
+  translated into what the user can understand.
 
   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
@@ -460,13 +390,8 @@ 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 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.
+- `brief-v1.md` is the user-facing brief. `brief.md` is the stable downstream
+  input and remains the thesis source.
 - `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`.
@@ -478,30 +403,29 @@ should test for this campaign. Those can run in parallel and usually take
   sample rows that already look like probable good fits. It can contain rough
   candidate messages and element tests, but it cannot select the final winner
   and cannot override `lead-filter.md`.
-- `message-validation.md` is the normal output of `generate message`.
+- `message-validation.md` is the internal validation artifact produced by the
+  user-facing `message generation` stage.
 - `message-review.md` and `message-review-decision.md` are the mandatory
   message quality gate outputs between `message-validation.md` and
   `approval-packet.md`.
 - Run the dependency chain as a DAG: `create-campaign-brief` -> `find leads`;
   once `lead-review.md` and `lead-sample.json` exist, run `filter leads` and
-  the explicit `generate message` validation as parallel branches from the same
-  basis (`brief.md`, `lead-review.md`, `lead-sample.json`). Approval waits for
-  both `lead-filter.md` and `message-validation.md`, then reconciles that the
+  `message generation` as parallel branches from the same basis (`brief.md`,
+  `lead-review.md`, `lead-sample.json`). Approval waits for both
+  `lead-filter.md` and `message-validation.md`, then reconciles that the
   selected message basis rows still pass the final filter.
-- Parallel means real parallel execution, not just optimistic progress copy.
-  After lead review:
-  - If the host exposes Task/subagent workers and host policy allows them for
-    this user request, launch two disjoint workers: one owns `lead-filter.md`
-    and optional `rubric.json`; the other owns `message-prep.md`,
-    `message-validation.md`, and `message-review.md`.
-  - If only parallel tool batching is available, batch only independent tool
-    reads/lookups. Do not pretend whole artifact-writing stages are running in
-    the background.
-  - If real parallel execution is not available or not allowed, run the same DAG
-    sequentially and use honest copy: `I’ll tighten the filter first, then draft
-the message from the same sample.`
-  - Never say `kicking off two workstreams`, `in parallel`, or `background`
-    unless parallel branches were actually launched.
+- Parallel means real parallel execution, not optimistic progress copy. After
+  lead review, if the host exposes Task/subagent workers and host policy allows
+  them for this user request, launch two disjoint workers: one owns
+  `lead-filter.md` and optional `rubric.json`; the other owns the user-facing
+  message generation branch and may write `message-prep.md`,
+  `message-validation.md`, and `message-review.md`. If only parallel tool
+  batching is available, batch independent tool reads/lookups only. If real
+  parallel execution is not available or not allowed, run the same DAG
+  sequentially and use honest copy: `I’ll tighten the filter first, then draft
+  the message from the same sample.` Never say `kicking off two workstreams`,
+  `in parallel`, or `background` unless parallel branches were actually
+  launched.
 - Never run a downstream stage until the active `flow.v2.json` step's
   `requiredArtifacts` exist.
 - Never call a tool outside the active step's `allowedTools`, and never call a
@@ -575,37 +499,34 @@ Ask the user only when one of these is true:
   packet so the founder can approve or revise the message deliberately.
 
 When asking subjective strategy questions (buyer scope, first ask, proof
-emphasis, tone, lead-source preference), use the structured quick question panel
-when available. Do not make it feel like a rigid multiple-choice survey:
-suggested directions are shortcuts, and the user must be able to type a custom
-answer in their own words. Ask target, offer, and proof in the first panel; ask
-lead source in a second panel. Do not add custom options to the final six-choice
-commit gate.
+emphasis, tone, lead-source preference), always make it clear the user can give
+a custom answer. Add an explicit `Other / custom` option to each subjective
+question. Do not rely on prose like "you can add detail" as the only custom
+path. Do not add custom options to the final six-choice commit gate.
 Use customer-facing question wording:
 
-- target prospects: `Who should this campaign target?`
-- main CTA / offer: `What useful thing should {{sender_or_company}} offer them?`
-- proof emphasis: `What proof should we lean on?`
+- target prospects: `Who should be the target prospects for this campaign? Pick one or combine.`
+- main CTA / offer: `What should the main CTA or offer be? Pick one or combine.`
+- proof emphasis: `Which proof point would most increase this buyer's confidence in {{company}}? Multi-select fine.`
 - lead source: `How should we get the people for this campaign?`
 
-Offer shortcuts must be concrete deliverables or outcomes, not meeting wrappers.
-Good examples: `send a short checklist`, `map 2-3 workflow bottlenecks`, `show a
-relevant customer example`, `teardown their public workflow`, `walk through a
-sample output`, or `diagnose where the current process slows down`. Bad
-examples: `compare notes`, `quick intro call`, `worth chatting`, `pick your
-brain`, `learn more`, or `see if it makes sense`.
-
-Ask the lead-source question as the last question in the first strategy batch,
-after buyer, offer/ask, and proof/safety are understood. Frame supplied lists as
-optional, not required. Suggested lead-source shortcuts should include:
-`I can find people for you, use a CSV of LinkedIn profiles, use a CSV of company
-domains, use an existing Sellable lead list, or follow another source idea.`
-If the user pastes up to 100 LinkedIn profile URLs or company domains, normalize
-the paste into a temporary local CSV and continue through the matching CSV
-preview path. Mixed, ambiguous, malformed, or oversized pastes should ask for a
-real CSV file instead of guessing. Uploaded CSV support is larger than paste
-support: LinkedIn profile CSVs can contain up to 7,500 rows; domain CSVs can
-contain up to 7,500 rows but only 1,000 unique domains.
+Ask the lead-source question as the last question in the first strategy
+batch, after buyer, offer/ask, and proof/safety are understood. Frame supplied
+lists as optional, not required. The three visible options are exactly:
+
+1. `Find people for me (recommended if you don't already have your own list)`
+2. `I have a CSV of LinkedIn profiles`
+3. `I have a CSV of company domains`
+
+Keep `Other / custom` available for freeform answers such as a pasted list,
+an existing Sellable lead list, or another source idea. Do not put existing
+Sellable lead lists in the main three-option first batch; support them through
+custom/freeform input. If the user pastes up to 100 LinkedIn profile URLs or
+company domains, normalize the paste into a temporary local CSV and continue
+through the matching CSV preview path. Mixed, ambiguous, malformed, or oversized
+pastes should ask for a real CSV file instead of guessing. Uploaded CSV support
+is larger than paste support: LinkedIn profile CSVs can contain up to 7,500
+rows; domain CSVs can contain up to 7,500 rows but only 1,000 unique domains.
 
 Avoid internal wording like `Which proof points should the message be allowed
 to lean on?` because it describes the artifact, not the founder decision.
@@ -642,12 +563,25 @@ Required behavior:
 - do not set `selectedLeadListId`
 - do not create lead-list rows
 - do not mutate DB-backed campaign state
-- run a parallel source scout when the source is not supplied, but choose the
-  lanes from the sourcing approach rather than running every provider by
-  default. For Signals-first campaigns, search multiple Signals keyword lanes
-  and fetch top-post engagers in parallel. For Sales Nav-first or
-  Prospeo/account-first campaigns, run multiple preview lanes for that provider
-  in parallel and use Signals only as a warmth/quality check when relevant
+- run a real parallel source-angle scout when the source is not supplied and at
+  least two viable source angles exist. Treat source scouting as independent
+  branches, then compare the outputs in `lead-review.md`.
+  - Branch A: Signals / active LinkedIn posts. Search relevant keyword lanes,
+    review finalist posts, fetch top-post engagers, and estimate warm-fit
+    volume.
+  - Branch B: Sales Nav / title + company filters. Run preview filters, inspect
+    preview rows, and estimate scalable-fit volume.
+  - Branch C: Prospeo / domains only when the campaign has a domain/account
+    path or the user supplied domains. Estimate email/contact scale and call out
+    weaker LinkedIn activity.
+  If the host cannot run these branches in parallel, run them sequentially and
+  do not claim they ran in parallel. If only one source angle is credible, say
+  that and run the best primary source plus one cheap fallback/quality check
+  when available. For Signals-first campaigns, search multiple Signals keyword
+  lanes and fetch top-post engagers in parallel when tool batching allows it.
+  For Sales Nav-first or Prospeo/account-first campaigns, run multiple preview
+  lanes for that provider in parallel and use Signals only as a warmth/quality
+  check when relevant
 - for Signals-first campaigns, raw post search volume is only inventory, not
   lead volume. `492 post results` means matching LinkedIn posts found across
   keyword lanes; it does not mean 492 prospects. The source decision must name
@@ -753,17 +687,12 @@ table with one row per selected or finalist post:
 `## Evidence Snapshot` must include a compact numbers-first table:
 
 - source lane / keyword or filter
-- provider/source angle label, e.g. `Signals / AI outbound posts`,
-  `Sales Nav / active SaaS founders + GTM leaders`, or
-  `Prospeo / domain-filtered agencies`
 - timeframe searched
 - raw results found
 - finalist posts or preview rows reviewed
 - sampled people
 - sampled fits, shown as `n/N (%)`
 - estimated usable people
-- estimated good-fit range after cleanup
-- expected reply-rate range
 - confidence note (`sample-backed`, `directional`, or `needs more sample`)
 
 For Signals-first campaigns, `## Sample Leads` must group representative sample
@@ -777,11 +706,11 @@ directional range and label it `directional`, not definitive.
 
 When showing `lead-review.md` to the user, render a slim decision summary in
 chat, not the full evidence table. Use rendered Markdown directly with short
-bullet lines; do not use fenced code blocks for the user-facing lead review.
-The visible response must include:
+indexed sections and bullet lines; do not use fenced code blocks for the
+user-facing lead review. The visible response must include:
 
 - `Lead source decision`
-- `Chosen source`
+- `Recommendation`
 - `Why it won`
 - `Quick numbers` as bullet points, with one provider/source angle per bullet.
   Each bullet must include raw volume, sampled fit rate as `n/N`, estimated
@@ -794,33 +723,6 @@ 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.
 
-Use this chat shape for the quick-number bullets:
-
-```text
-**1. Quick numbers**
-- **Signals / AI outbound posts:** 249 posts found. Sampled 40 engagers; 18/40
-  looked usable. Estimate: 100-250 good warm fits. Expected reply: 6-12%.
-- **Sales Nav / active SaaS founders + GTM leaders:** 27,454 active profiles before
-  filtering. First 25 had 12 strong/probable fits. Estimate: 300-800 good fits
-  after title/company cleanup. Expected reply: 4-9%.
-- **Prospeo / domain-filtered agencies:** 1,000+ likely contacts if we need scale,
-  but weaker LinkedIn activity. Estimate: 500-1,000 contacts. Expected reply:
-  2-5%.
-```
-
-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
 discovery. For supplied domain/account lists, explain that domains are account
@@ -891,31 +793,6 @@ Required behavior:
 - `Recommendation`
 - `Implementation Details`
 
-When showing the filter result in chat, render a slim summary before moving to
-message review. Use rendered Markdown, indexed sections, and short bullets:
-
-```text
-## Lead filter
-
-**1. Keep**
-- {role/title family}
-- {company/context family}
-
-**2. Exclude**
-- {false-positive family}
-- {false-positive family}
-
-**3. Why**
-- {sample-backed reason}
-
-**4. 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:
 
@@ -956,43 +833,6 @@ 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. Use rendered Markdown, indexed sections, and short
-bullets around the sample. 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. Use rendered Markdown, indexed sections, and short bullets. 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

@@ -57,23 +57,20 @@ 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 slim approval brief, not just a direction summary.
-Any list the user is expected to review should be rendered Markdown with short
-indexed sections and bullets. Avoid label-plus-paragraph blocks like
-`Key numbers:` followed by a dense paragraph, and never use fenced code blocks
-for review surfaces.
+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 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.
+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. 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`.
+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.
 
 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
@@ -95,17 +92,7 @@ Every customer-facing update should answer one of these:
 - What will the user see next?
 - What is protected until approval?
 
-Only promise parallel work when parallel work actually started. If the host
-cannot or should not launch background branches, say the real sequence:
-`I’ll tighten the filter first, then draft the message from the same sample.`
-Do not say `kicking off two workstreams`, `in parallel`, or `background` as
-aspirational copy.
-
-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:
+Before a brief approval, the user should see:
 
 - who we are targeting
 - why they should care
@@ -116,11 +103,6 @@ include:
 - risks / assumptions
 - what happens after approval
 
-The offer / CTA should be useful before it is convenient. Avoid vague
-peer-call asks like "compare notes" unless the user explicitly chose that. The
-buyer should know what they get if they reply: a checklist, teardown, diagnostic,
-sample, benchmark, relevant example, or working session with a concrete output.
-
 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:
@@ -132,37 +114,6 @@ 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. It must use rendered Markdown,
-not a fenced code block, and include bullet-pointed provider/source-angle
-estimates, one bullet per angle, so the sourcing logic is easy to scan:
-
-```text
-**1. Quick numbers**
-- **Signals / AI outbound posts:** 249 posts found. Sampled 40 engagers; 18/40
-  looked usable. Estimate: 100-250 good warm fits.
-- **Sales Nav / active SaaS founders + GTM leaders:** 27,454 active profiles before
-  filtering. First 25 had 12 strong/probable fits. Estimate: 300-800 good fits.
-- **Sales Nav / agencies + GTM consultants:** Smaller but higher intent. Estimate:
-  150-400 good fits.
-```
-
-Then show chosen source, why it won, 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 use indexed rendered Markdown and show what
-changed: keep, exclude, why, expected impact, and
-`Open artifact: lead-filter.md`.
-
-Message review chat should use indexed rendered Markdown, show one fully filled
-sample message without tokens, and keep tokenized templates in the artifact.
-
-Final approval chat should use indexed rendered Markdown for 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
@@ -268,6 +219,27 @@ setting: `~/.codex/config.toml` with
 
 ## Approval Ethic
 
+## Parallelism + Naming
+
+Source-angle comparison should be real, not implied. When the source is not
+supplied and multiple source angles are viable, scout Signals, Sales Nav, and
+relevant domain/contact paths as independent branches when the host can do so.
+If the host runs them sequentially, keep the output numeric but do not claim the
+source scout was parallel.
+
+Only promise parallel post-lead work when parallel work actually started. If the
+host cannot or should not launch background branches, say the real sequence:
+
+```text
+I’ll tighten the filter first, then run message generation from the same sample.
+```
+
+Do not say `kicking off two workstreams`, `in parallel`, or `background` as
+aspirational copy.
+
+Call the post-filter message stage `message generation` in chat.
+`message-validation.md` is an internal proof artifact, not the workstream name.
+
 Be explicit about when nothing has been created yet:
 
 ```text

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

@@ -206,28 +206,27 @@
       "onEnter": [
         {
           "action": "show_brief_summary",
-          "artifact": "brief.md"
+          "artifact": "brief-v1.md"
         },
         {
           "action": "render_brief_approval_checkpoint",
           "requiredVisibleContent": [
             "Campaign brief",
-            "Target",
-            "Core pain",
+            "Who we are targeting",
+            "Why they should care",
             "Offer / CTA",
-            "Proof",
-            "Lead plan",
+            "Proof to use",
+            "Lead source hypothesis",
             "Message angle",
-            "Risks",
-            "After approval",
+            "Risks / assumptions",
+            "What happens after approval",
             "approve this brief",
             "revise the brief",
             "then I will find good-fit leads"
           ],
-          "minimumVisibleBriefDetail": "slim_approval_brief_before_question",
-          "requiredArtifactLinks": ["brief.md"],
+          "minimumVisibleBriefDetail": "full_readable_brief_before_question",
+          "requiredArtifactLinks": ["brief-v1.md", "brief.md"],
           "artifactLinkTiming": "before_approval_question",
-          "chatRenderRule": "Show the brief as rendered Markdown, never as a fenced code block. Use ## Campaign brief, a one-sentence bold Decision, indexed bold section labels, and short bullets. In Lead plan, translate provider shorthand into plain user-facing language about who will be searched for and why; do not rely on bare terms like signal discovery, RevOps, outbound systems, or pipeline architecture.",
           "avoidQuestionWhenOnlyUsefulAnswerIs": "looks good"
         },
         {
@@ -301,7 +300,8 @@
         {
           "action": "run_subskill",
           "target": "find-leads",
-          "mode": "campaignless-preview"
+          "mode": "campaignless-preview",
+          "sourceScoutRule": "When source is not user-supplied and at least two viable source angles exist, scout independent source angles in parallel when host/tooling permits: Signals active-post branch, Sales Nav title/company branch, and Prospeo/domain branch only when relevant. If real parallel execution is unavailable, run the same scouts sequentially and do not claim parallel execution. Compare outputs by raw volume, n/N sampled fit, estimated good-fit range, expected reply range, and tradeoff."
         },
         {
           "action": "write_artifacts",
@@ -366,10 +366,10 @@
           "action": "show_lead_review",
           "artifact": "lead-review.md",
           "renderInlineSections": [
-            "Lead source decision",
-            "Chosen source",
+            "## Lead source decision",
+            "Recommendation",
             "Why it won",
-            "Key numbers",
+            "Quick numbers",
             "Sample leads",
             "Tradeoff"
           ],
@@ -401,19 +401,21 @@
           "forbidPercentOnlyFitRates": true,
           "requiredArtifactLinks": ["lead-review.md"],
           "artifactLinkTiming": "before_next_step_or_revision_question",
-          "chatRenderRule": "Show a slim rendered-Markdown decision summary only, never a fenced code block. Use indexed sections and short bullets: chosen source, why it won, bullet-pointed Quick numbers with one provider/source angle per bullet, raw volume, sampled fit rate as n/N, estimated good-fit range after cleanup, 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."
+          "doNotCompressToSummaryOnly": false,
+          "doNotRenderArtifactLinksOnly": true,
+          "chatRenderRule": "Show a slim rendered-Markdown decision summary only, never a fenced code block. Use indexed sections and short bullets: recommendation, why it won, Quick numbers with one provider/source angle per bullet, raw volume, sampled fit rate as n/N, estimated good-fit range after cleanup, 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",
             "Tighten the fit filter",
-            "Draft the first message",
+            "Message generation",
             "approved brief and real sample leads",
             "parallel only if real parallel branches were launched"
           ],
           "timeEstimate": "~2-3 min",
-          "chatRenderRule": "If real parallel workers/branches were actually launched, say: 'I’m kicking off two workstreams now' and list the two branches. If not, do not mention parallel/background work; say: 'I’ll tighten the filter first, then draft the first message from the same approved brief and sample leads.' Never claim parallelism unless the host actually started parallel execution."
+          "chatRenderRule": "If real parallel workers/branches were actually launched, say: 'I’m kicking off two workstreams now' and list 'Tighten the fit filter' and 'Message generation'. If not, do not mention parallel/background work; say: 'I’ll tighten the filter first, then run message generation from the same approved brief and sample leads.' Never claim parallelism unless the host actually started parallel execution. User-facing stage name is message generation; message-validation.md is only the internal artifact."
         },
         {
           "action": "ask_continue_revise_or_confirm_only_if_needed",
@@ -476,7 +478,7 @@
           "action": "show_lead_filter_summary",
           "artifact": "lead-filter.md",
           "renderInlineSections": [
-            "Lead filter",
+            "## Lead filter",
             "Keep",
             "Exclude",
             "Why",
@@ -623,7 +625,7 @@
             "recommendation"
           ],
           "mustRenderInlineBeforeQuestion": true,
-          "minimumVisibleMessageDetail": "filled_sample_message_no_tokens",
+          "minimumVisibleMessageDetail": "filled_sample_message_only",
           "requiredArtifactLinks": ["message-review.md"],
           "artifactLinkTiming": "before_approval_question",
           "requiredFileLabels": [
@@ -685,9 +687,11 @@
           "questionPrerequisiteVisibleLabels": [
             "Status: message-review",
             "Subject:",
+            "Tokenized template:",
             "Sample prospect fill:",
+            "Token fill basis:",
             "My take:",
-            "Concern:",
+            "Suggested adjustment:",
             "Recommendation:"
           ],
           "forbiddenWhenMissingVisibleMessage": true,

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

@@ -59,8 +59,6 @@ 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,33 +121,29 @@ 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 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:
+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:
 
 - `Verdict:` strong / usable-but-could-improve / needs-revision
 - `What works:` why the message is likely to earn replies
@@ -167,10 +163,6 @@ 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.

package/skills/create-campaign-v2/references/validation-criteria.md

@@ -131,20 +131,6 @@ 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.
 
-`## Evidence Snapshot` and the visible lead-review chat must break estimates out
-by provider/source angle. Do not collapse everything into one raw count. Use
-one row or bullet per angle. The visible chat version should be rendered
-Markdown with indexed sections and short bullets, not a fenced code block. For
-example:
-
-- `Signals / AI outbound posts`
-- `Sales Nav / active SaaS founders + GTM leaders`
-- `Sales Nav / agencies + GTM consultants`
-- `Prospeo / domain-filtered agencies`
-
-Each angle must show raw pool, sampled fits as `n/N`, estimated good-fit range
-after cleanup, expected reply-rate range, and confidence basis.
-
 `lead-sample.json` must include enough structured lead data for downstream
 filtering: