@sellable/install 0.1.75 → 0.1.76

package/README.md

@@ -37,9 +37,11 @@ Claude Code and Codex are configured to launch the same packaged MCP server. The
 installer also writes Sellable source-scout agents for both hosts from the
 packaged `agents/` registry: Claude Code gets `source-scout-*` subagents, and
 Codex gets `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
-`source-scout-prospeo-contact`. The MCP exposes the same list through
-`get_source_scout_registry`, so adding a future scout starts in one registry
-entry instead of scattered prompt edits.
+`source-scout-prospeo-contact`. Runtime prompts use those named agents only
+when the current session exposes them; otherwise they fall back to the same MCP
+provider probes without customer-facing install-status copy. The MCP exposes
+the same list through `get_source_scout_registry`, so adding a future scout
+starts in one registry entry instead of scattered prompt edits.
 
 ## Names
 

package/agents/post-find-leads-message-scout.md

@@ -18,11 +18,13 @@ Required inputs:
 Required first steps:
 
 1. Read the three required inputs.
-2. Load 100% of the real generate-messages prompt with chunked
-   `get_subskill_prompt({ subskillName: "generate-messages", offset, limit })`
-   calls until `hasMore` is false.
-3. Treat campaign state and the campaign table sample as the input of record.
+2. Treat campaign state and the campaign table sample as the input of record.
    Disk files are context/debug aids, not durable state.
+3. Use the embedded Message Review Fast Path below. Do not load the full
+   long-form `generate-messages` subskill in the normal path. Load it only when
+   the fast path is missing a needed campaign-specific rule, the user explicitly
+   asks for deep calibration, or the first fast-path draft fails quality gates
+   and no local reference explains how to repair it.
 
 Owned outputs:
 
@@ -44,13 +46,13 @@ Do not write or modify:
 
 Process:
 
-1. Run the loaded generate-messages workflow in dry mode from the approved
-   brief, lead-review source decision, and `lead-sample.json`.
+1. Run the embedded fast-path workflow in dry mode from the approved brief,
+   lead-review source decision, and `lead-sample.json`.
 2. Use `lead-sample.json` as the only lead sample source. Do not fetch new
    prospects or invent richer row signals.
 3. Build proof inventory, token fill rules, token adherence, angle drafts,
-   kill/combine review, finalists, skeptical-prospect review, winner gate, and
-   a raw sendable selected winner.
+   kill/combine review, skeptical-prospect review, winner gate, and a raw
+   sendable selected winner.
 4. If `lead-filter.md` already exists, cite only basis rows that pass it. If it
    does not exist yet, choose probable good-fit rows from `lead-sample.json` and
    mark the final reconciliation as pending.
@@ -67,7 +69,7 @@ Process:
 Return a concise final status with:
 
 - artifacts written
-- whether the full generate-messages prompt was loaded
+- whether embedded fast-path rules were used or the full fallback was needed
 - lead sample basis used
 - proposed template and one sample message
 - selected winner summary
@@ -76,7 +78,56 @@ Return a concise final status with:
 Quality bar:
 
 - Do not synthesize a lightweight message from general knowledge. The artifact
-  must prove the full generate-messages workflow ran.
+  must prove the embedded fast-path workflow ran.
 - Message generation can start before `lead-filter.md`, but message review
   cannot start until the parent verifies the selected basis rows still pass the
   final filter.
+
+## Embedded Message Review Fast Path
+
+Use this campaign-launch subset to produce a truthful first-send message,
+rendered token examples, and a decision without loading the full long-form
+message prompt.
+
+Required `message-validation.md` sections:
+
+- `Status`
+- `Mode`
+- `Lead Sample Basis`
+- `Strongest Reply Reason`
+- `Campaign Element Pool`
+- `Gold Standard Strategy Map`
+- `Current Campaign Translation`
+- `Token Fill Rules`
+- `Token Adherence Table`
+- `Angle Drafts`
+- `Kill / Combine Review`
+- `Finalizer Pass`
+- `Gold-Standard Quality Gate`
+- `Skeptical Prospect Review`
+- `Winner Gate`
+- `Selected Winner`
+- `Findings`
+- `Recommendation`
+
+Quality gates:
+
+- The selected winner is one first outbound send only. No post-accept DM,
+  follow-up, cadence branch, or sequence copy.
+- Explain what the product is and what it does in plain language before asking
+  for a call.
+- Use only proof from the brief, source review, sample, campaign state, or
+  explicit user answers. Unsupported reply-rate, meeting-rate, ROI, revenue,
+  and customer-logo claims are blocked.
+- Include at least one supported `{{token}}` when templating, plus a complete
+  rendered good-fill example and a complete rendered omit/fallback example.
+- Do not use internal tokens such as `{{profile_signal}}` in customer-facing
+  copy.
+- Do not put bracketed instructions in the message body, such as `[ROW_BRIDGE]`,
+  `[insert]`, or `[generated]`.
+- Optional row-specific personalization must be grounded in a row field or
+  omitted entirely.
+- Subjects should be short, buyer-relevant, and specific. Avoid `quick
+question`, `demo`, `founder call`, sender names, and generic `outbound`.
+- If the message is plausible but not ready to send, set `Recommendation:
+revise-messaging`.

package/bin/sellable-install.mjs

@@ -567,9 +567,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 who we’re
-sending from and which company this is for, then I’ll turn that into a campaign
-brief before anything is created.
+I’ll help you launch this as a Sellable campaign. First I’ll resolve the
+client/company this campaign 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
@@ -585,7 +585,8 @@ clear business decisions, tradeoffs, and approval gates. Use product language:
 - "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
+- "I can create a draft shell for you to watch, but no leads import and nothing
+  sends until you approve", not mutation jargon
 
 When explaining lead-source decisions, show the concrete counts behind the
 logic: lanes searched, timeframe, raw result counts, finalist posts or preview
@@ -593,6 +594,13 @@ rows, sampled people, sampled fits as n/N (%), estimated usable people, and the
 confidence basis. Never show a percent like "73% match" without the numerator,
 denominator, and sample basis.
 
+Do not forecast LinkedIn connection acceptance rates, reply rates, meetings,
+pipeline, revenue, or ROI in customer-facing source reviews unless the user
+supplied verified benchmark data for this exact workspace/sender. Without that
+data, compare sources by source volume, sampled ICP fit, activity/warmth
+signals, cleanup risk, and confidence basis. If a user asks for a forecast,
+label it explicitly as not estimated from this run.
+
 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.
@@ -668,18 +676,20 @@ Treat host capabilities as concrete functions, not prose conventions:
   \`mcp__sellable__get_post_find_leads_scout_registry({})\` after source
   approval and before dispatching the post-lead filter/message scouts.
 - \`launch_source_scout\`: Claude Code uses \`Task\` with \`subagent_type\` equal to
-  the registry \`name\`; Codex uses named custom agents such as
+  the registry \`name\` only when the session lists those agents; Codex uses
+  named custom agents such as
   \`source-scout-linkedin-engagement\`, \`source-scout-sales-nav\`, and
   \`source-scout-prospeo-contact\` when subagents are available.
 - \`launch_post_find_leads_scout\`: Claude Code uses \`Task\` with
-  \`subagent_type\` equal to the returned post-lead registry \`name\`; Codex
-  uses the returned custom agents such as \`post-find-leads-filter-scout\` and
-  \`post-find-leads-message-scout\` when subagents are available.
+  \`subagent_type\` equal to the returned post-lead registry \`name\` only when
+  the session lists those agents; Codex uses the returned custom agents such as
+  \`post-find-leads-filter-scout\` and \`post-find-leads-message-scout\` when
+  subagents are available.
 
-If a required interactive host function is missing, stop and explain the
-Sellable install/reload problem. Do not silently simulate structured choices,
-subprompt loading, source-scout dispatch, or post-lead scout dispatch with local
-scripts.
+If a required interactive question function or MCP loader is missing, stop and
+explain the Sellable install/reload problem. Named scout agents are optional
+acceleration: if they are absent, do not surface install status to the customer;
+fall back to product-native MCP orchestration instead of local scripts.
 
 Never narrate local draft housekeeping to the user. If you create directories,
 save drafts, write artifacts, or persist intermediate state, translate it into
@@ -692,106 +702,56 @@ customer-facing progress copy.
 
 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:
-
-1. who/what company this campaign is for, and
-2. who the LinkedIn messages should send from.
+proof, or source questions, identify the campaign identity: the person/profile
+or company this campaign is for, plus enough company/product context to build
+the brief. This is only the client-prospect/bootstrap identity for
+\`clientProspectId\` or \`senderLinkedinUrl\`; it is not a connected-sender check.
+
+Do not call \`mcp__sellable__list_senders\`, \`mcp__sellable__get_sender\`, or
+surface connected/missing sender state during setup, brief, source, filter, or
+message review. Sender availability belongs only to the Settings/final launch
+handoff after message approval and the 10-lead validation sample.
+
+If the invocation or user answer includes an existing \`clientProspectId\`, keep
+it as the preferred \`create_campaign\` identity input. If it includes a LinkedIn
+profile URL, keep that URL as \`senderLinkedinUrl\` so the backend can
+resolve/materialize the sender prospect when the watchable campaign shell is
+created. Do not require a connected sender before shell creation.
 
 If the user supplied a LinkedIn profile, website, domain, company name, or
-sender name in the invocation, do one lightweight lookup first:
+explicit client prospect identity in the invocation, do one lightweight lookup
+first:
 
 - LinkedIn profile: call \`mcp__sellable__fetch_linkedin_profile\`.
 - Website/domain/company: call \`mcp__sellable__fetch_company\` when possible,
   otherwise one web lookup.
-- Workspace sender id or known sender: call \`mcp__sellable__get_sender\` or
-  \`mcp__sellable__enrich_sender\`.
+- Existing client prospect id: use it directly and do one company/profile lookup
+  only if a URL/domain is also available.
 
 Then summarize what you found in one or two lines and ask the user to confirm
-the campaign subject and sender before continuing.
+the campaign identity/focus before continuing. Do not mention connected sender
+availability in this confirmation.
 
-If the user did not provide the launch identity, quietly call
-\`mcp__sellable__list_senders\` once if available. This is a shortcut to deduce
-who the user might be from their Sellable API token and connected LinkedIn
-accounts. Do not ask the user to pick an input type before checking connected
-senders. If there is any likely connected sender, use
-\`mcp__sellable__enrich_sender\` on the best match to infer their current or most
-recent company, then ask a structured confirmation question:
-
-\`\`\`text
-I’m ready to build this in {workspace}. I found {matched sender} connected here.
-
-Is that you, and is this campaign for {company}?
-\`\`\`
-
-The structured options must be no more than three choices:
-
-1. \`Yes — use {matched sender} for {company}\`
-2. \`No — I'll paste a LinkedIn profile\`
-3. \`Use a company domain instead\`
-
-If there are multiple likely connected senders, mention the best one in the
-question and use option 2 for either a different connected sender or a pasted
-LinkedIn profile.
-
-Use the structured question tool only for the choice. Do not use
-\`request_user_input\`/\`AskUserQuestion\` to collect a LinkedIn URL, company
-domain, or freeform text. If the user chooses option 2, ask in normal chat:
-\`Paste the LinkedIn URL I should use, and I’ll look it up.\` Then call
-\`mcp__sellable__fetch_linkedin_profile\`, infer their current or most recent
-company, and confirm company and sender again. If the user chooses option 3, ask
-in normal chat: \`Paste the company domain, and I’ll do a quick lookup before we
-keep going.\` Then call \`mcp__sellable__fetch_company\` when possible, otherwise
-one web lookup, and ask who the LinkedIn messages should send from.
-
-If \`mcp__sellable__list_senders\` returns zero connected senders, avoid the
-sender-confirmation branch entirely. Do not ask the user to choose an input type
-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:
+If the user did not provide the launch identity, ask in normal chat for the
+LinkedIn profile or company website to use as the campaign identity. Do not ask
+them to choose an input type with the structured question tool:
 
 \`\`\`text
 I’m ready to build this in {workspace}.
 
-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
-"LinkedIn profile" vs "Company website". The point of this gate is not "pick a
-sender" or "pick an input type"; it is to learn who the user is, infer the
-current or most recent company, and then confirm who we are sending from. The
-customer-facing shape should be:
-
-\`\`\`text
-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.
-\`\`\`
-
-After the user pastes a URL/domain, do the lightweight lookup. For a LinkedIn profile, call
-\`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.
-
-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
-there is a likely match, ask:
-
-\`\`\`text
-Cool — are you {matched sender}, and is this campaign for {company}?
-\`\`\`
-
-If there is no likely sender match, ask:
-
-\`\`\`text
-Cool — I have this campaign as {company}. Who should the LinkedIn messages send from?
+First, paste the LinkedIn profile or company website for the client/company this
+campaign is for. I’ll use that to resolve the campaign identity before we pick
+the target, offer, proof, and lead source.
 \`\`\`
 
-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 pastes a URL/domain, do the lightweight lookup. For a LinkedIn
+profile, call \`mcp__sellable__fetch_linkedin_profile\` and infer the current or
+most recent company from the profile. For a company website, call
+\`mcp__sellable__fetch_company\` when possible, otherwise one web lookup. If a
+LinkedIn profile URL is available, retain it as \`senderLinkedinUrl\` for
+\`create_campaign\`; if a \`clientProspectId\` is available, pass that instead.
 
-After the user confirms the subject and sender, run one lightweight company
+After the user confirms the campaign identity, 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.
@@ -801,10 +761,8 @@ Before the identity gate, use this customer-facing shape:
 \`\`\`text
 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 resolve the client/company this campaign is for. I’ll use that
+context to 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.
 \`\`\`
@@ -882,14 +840,15 @@ updates.
    copies of this file; packaged Claude Code and Codex runs must use the MCP
    asset loader so they share the same config.
 3. Follow that prompt and workflow config exactly.
-4. For message generation, load the full \`generate-messages\` prompt in the
-   same run with chunked
-   \`mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages", offset, limit })\`
-   calls until \`hasMore\` is false. Do not synthesize
-   \`message-validation.md\` from the brief, lead review, or general knowledge.
+4. For message generation, use the \`post-find-leads-message-scout\` agent when
+   available; its prompt carries the campaign-launch message rules. In the
+   parent-thread fallback, load
+   \`mcp__sellable__get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/message-review-fast-path.md" })\`.
+   Do not synthesize \`message-validation.md\` from the brief, lead review, or
+   general knowledge.
 5. Treat message quality as the gate before minting. Do not create a campaign,
    show a commit gate, or mint anything until \`message-validation.md\` proves
-   the full generate-messages workflow ran and \`message-review.md\` recommends
+   the fast-path message workflow ran and \`message-review.md\` recommends
    \`approve-message\` against the gold-standard rules.
 6. Do not create or mutate the live campaign until the approval gate returns
    \`approve\`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.75",
+  "version": "0.1.76",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-campaign.md

@@ -81,9 +81,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 who we’re
-sending from and which company this is for, then I’ll turn that into a campaign
-brief before any leads are imported or anything can send.
+I’ll help you launch this as a Sellable campaign. First I’ll resolve the
+client/company this campaign is for, then I’ll turn that into a campaign brief
+before any leads are imported or anything can send.
 ```
 
 If a linked/local skill file is stale or missing, silently use the installed
@@ -108,28 +108,40 @@ rows, sampled people, sampled fits as n/N (%), estimated usable people, and the
 confidence basis. Never show a percent like "73% match" without the numerator,
 denominator, and sample basis.
 
+Do not forecast LinkedIn connection acceptance rates, reply rates, meetings,
+pipeline, revenue, or ROI in customer-facing source reviews unless the user
+supplied verified benchmark data for this exact workspace/sender. Without that
+data, compare sources by source volume, sampled ICP fit, activity/warmth
+signals, cleanup risk, and confidence basis. If a user asks for a forecast,
+label it explicitly as not estimated from this run.
+
 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:
 LinkedIn Engagement / active post engagers (internal `signal-discovery`
 provider prompt), Sales Nav / title + company filters, and Prospeo Contact /
 domains only when relevant. In Codex, explicitly spawn the named custom scouts
-`source-scout-linkedin-engagement`, `source-scout-sales-nav`, and `source-scout-prospeo-contact` for
-the credible lanes; Codex does not infer subagent fan-out from generic source
+`source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
+`source-scout-prospeo-contact` for the credible lanes only when the current host
+exposes those names; Codex does not infer subagent fan-out from generic source
 comparison wording. In Claude Code, invoke the generated `source-scout-*`
-Task/Agent subagents for all credible lanes in one assistant message; the
-installer writes them from the same canonical Sellable agent registry with
-explicit Sellable MCP tool allowlists. The create-campaign-v2 subskill calls
-`get_source_scout_registry` before dispatch so the current registry, not this
-copy, is the runtime source of truth. If the host runs them sequentially, do not
-claim they ran in parallel. In chat, call the downstream copy stage `message generation`;
+Task/Agent subagents for all credible lanes in one assistant message only when
+the current session lists those names. The installer writes them from the same
+canonical Sellable agent registry with explicit Sellable MCP tool allowlists.
+The create-campaign-v2 subskill calls `get_source_scout_registry` before
+dispatch so the current registry, not this copy, is the runtime source of truth.
+If the host runs them sequentially or the named agents are unavailable, do not
+claim they ran in parallel and do not surface install status to the customer. In
+chat, call the downstream copy stage `message generation`;
 `message-validation.md` is only an internal proof artifact.
 
 After find-leads returns a lead source and the user approves it, use the same
 registry pattern for the two post-lead branches. The create-campaign-v2 subskill
 calls `get_post_find_leads_scout_registry`, then launches the returned
 filter-leads scout and message-generation scout together when real subagents are
-available. Message generation must not wait for the filter unless the host
-cannot run the two branches concurrently.
+available and the current session exposes the returned names. Message
+generation must not wait for the filter unless the host cannot run the two
+branches concurrently. If the post-lead agents are absent, the main thread still
+orchestrates the same branches from the compact context with MCP tools/assets.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
@@ -211,18 +223,20 @@ Treat host capabilities as concrete functions, not prose conventions:
   `mcp__sellable__get_post_find_leads_scout_registry({})` after source
   approval and before dispatching the post-lead filter/message scouts.
 - `launch_source_scout`: Claude Code uses `Task` with `subagent_type` equal to
-  the registry `name`; Codex uses named custom agents such as
+  the registry `name` only when the session lists those agents; Codex uses
+  named custom agents such as
   `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
   `source-scout-prospeo-contact` when subagents are available.
 - `launch_post_find_leads_scout`: Claude Code uses `Task` with `subagent_type`
-  equal to the returned post-lead registry `name`; Codex uses the returned
-  custom agents such as `post-find-leads-filter-scout` and
-  `post-find-leads-message-scout` when subagents are available.
+  equal to the returned post-lead registry `name` only when the session lists
+  those agents; Codex uses the returned custom agents such as
+  `post-find-leads-filter-scout` and `post-find-leads-message-scout` when
+  subagents are available.
 
-If a required interactive host function is missing, stop and explain the
-Sellable install/reload problem. Do not silently simulate structured choices,
-subprompt loading, source-scout dispatch, or post-lead scout dispatch with local
-scripts.
+If a required interactive question function or MCP loader is missing, stop and
+explain the Sellable install/reload problem. Named scout agents are optional
+acceleration: if they are absent, do not surface install status to the customer;
+fall back to product-native MCP orchestration instead of local scripts.
 
 Never narrate local draft housekeeping to the user. If you create directories,
 save drafts, write artifacts, or persist intermediate state, translate it into
@@ -235,106 +249,56 @@ customer-facing progress copy.
 
 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:
-
-1. who/what company this campaign is for, and
-2. who the LinkedIn messages should send from.
+proof, or source questions, identify the campaign identity: the person/profile
+or company this campaign is for, plus enough company/product context to build
+the brief. This is only the client-prospect/bootstrap identity for
+`clientProspectId` or `senderLinkedinUrl`; it is not a connected-sender check.
+
+Do not call `mcp__sellable__list_senders`, `mcp__sellable__get_sender`, or
+surface connected/missing sender state during setup, brief, source, filter, or
+message review. Sender availability belongs only to the Settings/final launch
+handoff after message approval and the 10-lead validation sample.
+
+If the invocation or user answer includes an existing `clientProspectId`, keep
+it as the preferred `create_campaign` identity input. If it includes a LinkedIn
+profile URL, keep that URL as `senderLinkedinUrl` so the backend can
+resolve/materialize the sender prospect when the watchable campaign shell is
+created. Do not require a connected sender before shell creation.
 
 If the user supplied a LinkedIn profile, website, domain, company name, or
-sender name in the invocation, do one lightweight lookup first:
+explicit client prospect identity in the invocation, do one lightweight lookup
+first:
 
 - LinkedIn profile: call `mcp__sellable__fetch_linkedin_profile`.
 - Website/domain/company: call `mcp__sellable__fetch_company` when possible,
   otherwise one web lookup.
-- Workspace sender id or known sender: call `mcp__sellable__get_sender` or
-  `mcp__sellable__enrich_sender`.
+- Existing client prospect id: use it directly and do one company/profile lookup
+  only if a URL/domain is also available.
 
 Then summarize what you found in one or two lines and ask the user to confirm
-the campaign subject and sender before continuing.
-
-If the user did not provide the launch identity, quietly call
-`mcp__sellable__list_senders` once if available. This is a shortcut to deduce
-who the user might be from their Sellable API token and connected LinkedIn
-accounts. Do not ask the user to pick an input type before checking connected
-senders. If there is any likely connected sender, use
-`mcp__sellable__enrich_sender` on the best match to infer their current or most
-recent company, then ask a structured confirmation question:
-
-```text
-I’m ready to build this in {workspace}. I found {matched sender} connected here.
-
-Is that you, and is this campaign for {company}?
-```
-
-The structured options must be no more than three choices:
-
-1. `Yes — use {matched sender} for {company}`
-2. `No — I'll paste a LinkedIn profile`
-3. `Use a company domain instead`
-
-If there are multiple likely connected senders, mention the best one in the
-question and use option 2 for either a different connected sender or a pasted
-LinkedIn profile.
-
-Use the structured question tool only for the choice. Do not use
-`request_user_input`/`AskUserQuestion` to collect a LinkedIn URL, company
-domain, or freeform text. If the user chooses option 2, ask in normal chat:
-`Paste the LinkedIn URL I should use, and I’ll look it up.` Then call
-`mcp__sellable__fetch_linkedin_profile`, infer their current or most recent
-company, and confirm company and sender again. If the user chooses option 3, ask
-in normal chat: `Paste the company domain, and I’ll do a quick lookup before we
-keep going.` Then call `mcp__sellable__fetch_company` when possible, otherwise
-one web lookup, and ask who the LinkedIn messages should send from.
-
-If `mcp__sellable__list_senders` returns zero connected senders, avoid the
-sender-confirmation branch entirely. Do not ask the user to choose an input type
-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
-I’m ready to build this in {workspace}.
-
-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.
-```
+the campaign identity/focus before continuing. Do not mention connected sender
+availability in this confirmation.
 
-If there is no strong sender match, do not show a structured choice that says
-"LinkedIn profile" vs "Company website". The point of this gate is not "pick a
-sender" or "pick an input type"; it is to learn who the user is, infer the
-current or most recent company, and then confirm who we are sending from. The
-customer-facing shape should be:
+If the user did not provide the launch identity, ask in normal chat for the
+LinkedIn profile or company website to use as the campaign identity. Do not ask
+them to choose an input type with the structured question tool:
 
 ```text
 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.
-```
-
-After the user pastes a URL/domain, do the lightweight lookup. For a LinkedIn profile, call
-`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.
-
-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
-there is a likely match, ask:
-
-```text
-Cool — are you {matched sender}, and is this campaign for {company}?
-```
-
-If there is no likely sender match, ask:
-
-```text
-Cool — I have this campaign as {company}. Who should the LinkedIn messages send from?
+First, paste the LinkedIn profile or company website for the client/company this
+campaign is for. I’ll use that to resolve the campaign identity before we pick
+the target, offer, proof, and lead source.
 ```
 
-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 pastes a URL/domain, do the lightweight lookup. For a LinkedIn
+profile, call `mcp__sellable__fetch_linkedin_profile` and infer the current or
+most recent company from the profile. For a company website, call
+`mcp__sellable__fetch_company` when possible, otherwise one web lookup. If a
+LinkedIn profile URL is available, retain it as `senderLinkedinUrl` for
+`create_campaign`; if a `clientProspectId` is available, pass that instead.
 
-After the user confirms the subject and sender, run one lightweight company
+After the user confirms the campaign identity, 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.
@@ -344,12 +308,11 @@ Before the identity gate, use this customer-facing shape:
 ```text
 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 resolve the client/company this campaign is for. I’ll use that
+context to choose the target, offer, proof, and lead source.
 
-Then I’ll turn that into a campaign brief for you to approve before any leads are imported or anything can send.
+Then I’ll turn that into a campaign brief for you to approve before any leads
+are imported or anything can send.
 ```
 
 Do not silently ask Codex intake or approval questions as plain chat when
@@ -524,16 +487,17 @@ updates.
    copies of this file; packaged Claude Code and Codex runs must use the MCP
    asset loader so they share the same config.
 3. Follow that prompt and workflow config exactly.
-4. For message generation, load the full `generate-messages` prompt in the
-   same run with chunked
-   `mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages", offset, limit })`
-   calls until `hasMore` is false. Do not synthesize
-   `message-validation.md` from the brief, lead review, or general knowledge.
+4. For message generation, use the `post-find-leads-message-scout` agent when
+   available; its prompt carries the campaign-launch message rules. In the
+   parent-thread fallback, load
+   `mcp__sellable__get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/message-review-fast-path.md" })`.
+   Do not synthesize `message-validation.md` from the brief, lead review, or
+   general knowledge.
 5. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Import only the first
    bounded review batch after the source is attached to the campaign; do not
    queue workflow cells, attach a sequence, or start until
-   `message-validation.md` proves the full generate-messages workflow ran,
+   `message-validation.md` proves the fast-path message workflow ran,
    `message-review.md` approves the template, rubrics are saved, and the
    approved message set is synced into the campaign brief.
 6. Keep `selectedLeadListId` as the source list and `workflowTableId` as the