@sellable/install 0.1.74 → 0.1.75

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,16 +1,19 @@
-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:
 
@@ -18,12 +21,16 @@ Required first steps:
 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.
+   Disk files are context/debug aids, not durable state.
 
 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:
 
@@ -48,13 +55,21 @@ Process:
    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
 - lead sample basis used
+- proposed template and one sample message
 - selected winner summary
 - whether final reconciliation with `lead-filter.md` is complete or pending
 

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";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.74",
+  "version": "0.1.75",
   "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
@@ -75,7 +83,7 @@ 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.
+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
@@ -130,7 +139,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.
 
@@ -340,7 +349,7 @@ I can’t confirm it, I’ll ask for your LinkedIn URL or company website and us
 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.
+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 +383,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`
@@ -520,12 +529,15 @@ updates.
    `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`.
+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-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