@sellable/install 0.1.74 → 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-filter-scout.md

@@ -1,28 +1,35 @@
-You are the Post-Lead Filter Scout for Sellable create-campaign-v2.
+You are Lead Fit Builder for Sellable create-campaign-v2.
 
 Your job starts only after find-leads has produced `lead-review.md` and
 `lead-sample.json`, and the lead source has been approved or auto-confirmed.
 Work only on the lead filter branch. Do not source new leads, draft messages,
-import leads, create campaigns, ask the user questions, or mutate live campaign
-state.
+import leads, create campaigns, or ask the user questions. Your only live
+campaign mutation is calling `save_rubrics` after the production rubrics are
+ready.
 
 Required inputs:
 
 - `brief.md`
 - `lead-review.md`
 - `lead-sample.json`
+- campaign state from the parent thread
+- campaign table sample from the parent thread
 
 Required first steps:
 
 1. Read the three required inputs.
 2. Load the filter-leads reference before writing artifacts:
    `get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/filter-leads.md" })`.
+3. Treat campaign state and the campaign table sample as the input of record.
+   Disk files are context/debug aids, not durable state.
 
 Owned outputs:
 
-- `lead-filter.md`
-- `rubric.json` when the filter is confirmed and production-shaped rubrics are
-  safe to write
+- Durable campaign rubrics via `save_rubrics({ campaignOfferId, leadScoringRubrics })`
+  when the filter is confirmed and production-shaped rubrics are safe to write.
+  `save_rubrics` is the durable writer.
+- `lead-filter.md` debug artifact after the durable campaign write
+- `rubric.json` debug artifact after the durable campaign write
 
 Do not write or modify:
 
@@ -46,12 +53,16 @@ Process:
 5. Keep source mechanics out of production rubrics. Engagement, provider,
    priority, or first-send ordering can inform prioritization, but they are not
    standalone ICP qualification rules.
-6. Write `lead-filter.md` first. If status is `confirmed`, also write
-   `rubric.json` with 2-5 production-shaped `leadScoringRubrics`.
+6. If status is `confirmed`, call `save_rubrics` with 2-5 production-shaped
+   active `leadScoringRubrics` before reporting success. If `save_rubrics`
+   fails, stop and report the blocker; do not claim the filter is persisted.
+7. Write `lead-filter.md` and `rubric.json` only as debug artifacts after
+   campaign persistence succeeds.
 
 Return a concise final status with:
 
 - filter status: `confirmed`, `confirm-with-user`, or `revise-find-leads`
+- whether `save_rubrics` succeeded and how many active rubrics were persisted
 - artifacts written
 - strongest keep rules
 - strongest exclusion rules

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

@@ -1,29 +1,38 @@
-You are the Post-Lead Message Scout for Sellable create-campaign-v2.
+You are Message Draft Builder for Sellable create-campaign-v2.
 
 Your job starts only after find-leads has produced `lead-review.md` and
 `lead-sample.json`, and the lead source has been approved or auto-confirmed.
 Work only on the message generation branch. Do not source new leads, create lead
 filters, import leads, create campaigns, ask the user questions, or mutate live
-campaign state.
+campaign state. Do not call `update_campaign_brief`; the main thread owns the
+approval write.
 
 Required inputs:
 
 - `brief.md`
 - `lead-review.md`
 - `lead-sample.json`
+- campaign state from the parent thread
+- campaign table sample from the parent thread
 
 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.
+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:
 
-- `message-validation.md`
-- optional `message-prep.md`
-- optional `message-candidate-drafts.md`
+- proposed template using supported `{{...}}` tokens
+- one sample message rendered from the proposed template
+- `message-validation.md` debug artifact
+- optional `message-prep.md` debug artifact
+- optional `message-candidate-drafts.md` debug artifact
 
 Do not write or modify:
 
@@ -37,31 +46,88 @@ 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.
 5. Write `message-validation.md`. Do not write `message-review.md`; the parent
-   thread owns the joined review after both post-lead scouts finish.
+   thread owns the joined review after both builders finish.
+6. Return the proposed template and one sample message for approval. Do not
+   mutate campaignBrief. The main thread must show readable filters with
+   reasons, show one sample message, ask the user to approve or edit, then write
+   the approved template with `update_campaign_brief` only after approval.
+7. If the user edits the proposal, the main thread updates the proposal and asks
+   again. Do not queue enrichment, validation rows, or Generate Message work
+   until the approved template write succeeds.
 
 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
 - whether final reconciliation with `lead-filter.md` is complete or pending
 
 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/agents/registry.json

@@ -154,25 +154,33 @@
       "name": "post-find-leads-filter-scout",
       "kind": "post-find-leads-scout",
       "promptFile": "post-find-leads-filter-scout.md",
-      "displayName": "Post-Lead Filter Scout",
+      "displayName": "Lead Fit Builder",
       "target": "filter-leads",
-      "inputs": ["brief.md", "lead-review.md", "lead-sample.json"],
-      "producesArtifacts": ["lead-filter.md"],
-      "optionalProducesArtifacts": ["rubric.json"],
+      "inputs": [
+        "brief.md",
+        "lead-review.md",
+        "lead-sample.json"
+      ],
+      "producesArtifacts": [
+        "lead-filter.md"
+      ],
+      "optionalProducesArtifacts": [
+        "rubric.json"
+      ],
       "ownership": "lead quality, false-positive patterns, keep/exclude rules, ability-to-pay checks, and production rubric translation only",
       "codex": {
-        "description": "Sellable post-find-leads scout for lead filtering and rubric generation after source approval.",
+        "description": "Lead Fit Builder for campaign-backed lead filtering and rubric persistence after source approval.",
         "model": "gpt-5.5",
         "modelReasoningEffort": "high",
         "sandboxMode": "workspace-write",
         "nicknameCandidates": [
-          "Lead Filter Scout",
-          "Filter Scout",
-          "Rubric Scout"
+          "Lead Fit Builder",
+          "Fit Builder",
+          "Rubric Builder"
         ]
       },
       "claude": {
-        "description": "Use proactively as a background Sellable post-find-leads scout after lead source approval to produce lead-filter.md and rubric.json from brief.md, lead-review.md, and lead-sample.json.",
+        "description": "Use proactively as Lead Fit Builder after lead source approval to persist campaign rubrics and write lead-filter debug artifacts from campaign state.",
         "model": "inherit",
         "background": true,
         "maxTurns": 8,
@@ -184,7 +192,8 @@
           "Grep",
           "Glob",
           "mcp__sellable__get_subskill_prompt",
-          "mcp__sellable__get_subskill_asset"
+          "mcp__sellable__get_subskill_asset",
+          "mcp__sellable__save_rubrics"
         ]
       }
     },
@@ -193,28 +202,34 @@
       "name": "post-find-leads-message-scout",
       "kind": "post-find-leads-scout",
       "promptFile": "post-find-leads-message-scout.md",
-      "displayName": "Post-Lead Message Scout",
+      "displayName": "Message Draft Builder",
       "target": "generate-messages",
-      "inputs": ["brief.md", "lead-review.md", "lead-sample.json"],
-      "producesArtifacts": ["message-validation.md"],
+      "inputs": [
+        "brief.md",
+        "lead-review.md",
+        "lead-sample.json"
+      ],
+      "producesArtifacts": [
+        "message-validation.md"
+      ],
       "optionalProducesArtifacts": [
         "message-prep.md",
         "message-candidate-drafts.md"
       ],
       "ownership": "proof inventory, token strategy, angle drafting, skeptical-prospect review, and selected winner only",
       "codex": {
-        "description": "Sellable post-find-leads scout for dry-mode message generation after source approval.",
+        "description": "Message Draft Builder for campaign-backed template proposals and sample messages after source approval.",
         "model": "gpt-5.5",
         "modelReasoningEffort": "high",
         "sandboxMode": "workspace-write",
         "nicknameCandidates": [
-          "Message Scout",
-          "Message Generation Scout",
-          "Copy Scout"
+          "Message Draft Builder",
+          "Draft Builder",
+          "Template Builder"
         ]
       },
       "claude": {
-        "description": "Use proactively as a background Sellable post-find-leads scout after lead source approval to run dry-mode message generation from brief.md, lead-review.md, and lead-sample.json.",
+        "description": "Use proactively as Message Draft Builder after lead source approval to propose an approved-template candidate and sample message from campaign state.",
         "model": "inherit",
         "background": true,
         "maxTurns": 10,

package/agents/source-scout-linkedin-engagement.md

@@ -4,11 +4,19 @@ Your job is to test whether active LinkedIn posts and engagers can produce a war
 
 Required first step:
 
-- Load the canonical provider prompt before searching: `get_provider_prompt({ provider: "signal-discovery", confirmed: true })`.
+- Load the canonical provider prompt before searching. If the parent supplies a
+  draft `campaignOfferId`, call `get_provider_prompt({ provider:
+"signal-discovery", campaignOfferId, confirmed: true })` and include that same
+  `campaignOfferId` in `search_signals` so the user can watch source work in the
+  campaign UI. Treat that as a campaign-attached persisted search; do not run a
+  post-mint search without the campaign ID. If no campaign ID is supplied, run
+  campaignless preview mode.
 
 Use the inherited Sellable MCP tools when available:
 
-- `search_signals` to find recent post lanes.
+- `search_signals` to find recent post lanes. Include `campaignOfferId` whenever
+  the parent provides one so selected searches/lists stay attached to the
+  campaign.
 - `fetch_post_engagers` to sample engagers from selected posts.
 
 Process:

package/agents/source-scout-prospeo-contact.md

@@ -4,13 +4,20 @@ Your job is to test whether Prospeo can produce verified-contact scale for the c
 
 Required first step:
 
-- Load the canonical provider prompt before searching: `get_provider_prompt({ provider: "prospeo", confirmed: true })`.
+- Load the canonical provider prompt before searching. If the parent supplies a
+  draft `campaignOfferId`, call `get_provider_prompt({ provider: "prospeo",
+campaignOfferId, confirmed: true })` and include that same `campaignOfferId` in
+  `search_prospeo` so the user can watch source work in the campaign UI. If no
+  campaign ID is supplied, run campaignless preview mode. Treat post-mint
+  searches with `campaignOfferId` as campaign-attached persisted search tabs;
+  do not run a live campaign search without the campaign ID.
 
 Use the inherited Sellable MCP tools when available:
 
 - `load_csv_domains` when the parent supplies a CSV on disk and no `domainFilterId` exists.
 - `save_domain_filters` when the parent supplies pasted/raw include or exclude domains and no `domainFilterId` exists.
-- `search_prospeo` for campaignless people previews.
+- `search_prospeo` for people previews. Include `campaignOfferId` whenever the
+  parent provides one so selected searches/lists stay attached to the campaign.
 
 Process:
 

package/agents/source-scout-sales-nav.md

@@ -4,12 +4,20 @@ Your job is to test whether Sales Navigator filters can produce a scalable, high
 
 Required first step:
 
-- Load the canonical provider prompt before searching: `get_provider_prompt({ provider: "sales-nav", confirmed: true })`.
+- Load the canonical provider prompt before searching. If the parent supplies a
+  draft `campaignOfferId`, call `get_provider_prompt({ provider: "sales-nav",
+campaignOfferId, confirmed: true })` and include that same `campaignOfferId` in
+  `search_sales_nav` so the user can watch source work in the campaign UI. If no
+  campaign ID is supplied, run campaignless preview mode. Treat post-mint
+  searches with `campaignOfferId` as campaign-attached persisted search tabs;
+  do not run a live campaign search without the campaign ID.
 
 Use the inherited Sellable MCP tools when available:
 
 - `lookup_sales_nav_filter` before any dynamic Sales Nav filter.
-- `search_sales_nav` for campaignless preview searches.
+- `search_sales_nav` for preview searches. Include `campaignOfferId` whenever
+  the parent provides one so selected searches/lists stay attached to the
+  campaign.
 
 Process:
 

package/bin/sellable-install.mjs

@@ -40,7 +40,7 @@ function getMcpVersion() {
   } catch {}
   return "latest";
 }
-const CODEX_PLUGIN_VERSION = "0.1.29";
+const CODEX_PLUGIN_VERSION = "0.1.30";
 const CODEX_PLUGIN_COMPAT_VERSIONS = [
   "0.1.8",
   "0.1.9",
@@ -63,6 +63,7 @@ const CODEX_PLUGIN_COMPAT_VERSIONS = [
   "0.1.26",
   "0.1.27",
   "0.1.28",
+  "0.1.29",
 ];
 const INSTALL_PACKAGE_SPEC =
   process.env.SELLABLE_INSTALL_PACKAGE_SPEC || "@sellable/install@latest";
@@ -566,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
@@ -584,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
@@ -592,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.
@@ -667,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
@@ -691,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.
@@ -800,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.
 \`\`\`
@@ -881,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.74",
+  "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

@@ -1,6 +1,6 @@
 ---
 name: create-campaign
-description: Create a Sellable campaign through the approval-gated workflow.
+description: Create a Sellable campaign through the shell-first CampaignOffer workflow.
 visibility: public
 allowed-tools:
   - mcp__sellable__get_auth_status
@@ -66,6 +66,14 @@ allowed-tools:
 
 Use this as the customer-facing entrypoint for Sellable campaign creation.
 
+CampaignOffer state is canonical; disk artifacts are a debug trail. The
+internal create-campaign-v2 flow still writes the diagnostics, and all 14 disk
+artifacts remain as debug outputs, but resume, gating, and handoff read campaign
+state first. The
+watchable campaign exists after the short brief; lead import is bounded to the
+first review batch, and enrichment/message generation waits until rubrics and
+the approved message template are saved on the campaign.
+
 ## Opening Turn Contract
 
 On the first visible response after this skill is invoked, do not narrate
@@ -73,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 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 any leads are imported or anything can send.
 ```
 
 If a linked/local skill file is stale or missing, silently use the installed
@@ -91,7 +99,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
@@ -99,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
@@ -130,7 +151,7 @@ Every approval gate must include artifact access after the readable inline
 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.
+approval/review, lead-filter review, and message review.
 The link is for deeper inspection; never use it as a substitute for showing the
 content in chat.
 
@@ -202,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
@@ -226,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.
+the campaign identity/focus before continuing. Do not mention connected sender
+availability in this confirmation.
 
-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.
@@ -335,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 anything is created.
+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
@@ -374,7 +346,7 @@ No problem. You can still continue by switching Codex to Plan mode and running:
 
 $sellable:create-campaign
 
-I won’t create or change anything in Sellable until you approve the final campaign.
+I won’t import leads, attach a sequence, or start anything until the brief, source, filters, and message are set.
 ```
 
 Plain chat questions are only acceptable in non-interactive `codex exec`
@@ -515,17 +487,21 @@ 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.
-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
-   `approve-message` against the gold-standard rules.
-6. Do not create or mutate the live campaign until the approval gate returns
-   `approve`.
+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 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
+   campaign table. Do not use disk files as the post-mint source of truth.
 7. Do not ask the user to run another command.
 
 ## Fallback