@sellable/install 0.1.103 → 0.1.105

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

@@ -61,9 +61,9 @@ Return the following to the parent thread:
   choice, and rubric/filter basis when present
 - output timestamp/hash and any retry/error detail
 
-Write `message-validation.md`, `message-prep.md`, or
-`message-candidate-drafts.md` only when the parent explicitly asks for debug
-artifacts. Normal live campaign runs can return the same content directly.
+Do not write local markdown/json artifacts in normal live campaign runs. Return
+the recommendation directly to the parent thread. Emit debug artifacts only when
+the parent explicitly asks for debug/UAT output.
 
 When reporting branch runtime proof, use this shape under
 `watchNarration.workerDetails.messageDraftBuilder`:
@@ -136,3 +136,47 @@ Return a concise status with:
 - one rendered omit/fallback sample
 - quality-gate pass/fail summary
 - whether final template review is ready or needs revision
+
+When the parent will show the recommendation in chat, format the customer-facing
+message review as Markdown with distinct copy blocks:
+
+````markdown
+## Message Template
+
+**Subject**
+
+```text
+{{tokenized_subject}}
+```
+
+**Body**
+
+```text
+{{tokenized_message_body}}
+```
+
+## Rendered Examples
+
+### Good token fill
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+
+### Good omit / fallback
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+````
+
+Use a table for token rules. Keep explanations outside the fenced `text` blocks
+so the user can quickly see exactly what copy is being approved.

package/agents/registry.json

@@ -168,7 +168,7 @@
       "optionalProducesArtifacts": [],
       "ownership": "lead quality, false-positive patterns, keep/exclude rules, ability-to-pay checks, and production rubric translation only",
       "codex": {
-        "description": "Lead Fit Builder for campaign-backed lead filtering and rubric persistence after source approval.",
+        "description": "Lead Fit Builder for campaign-backed lead filtering and rubric persistence after review-batch import and filter approval.",
         "model": "gpt-5.5",
         "modelReasoningEffort": "high",
         "sandboxMode": "read-only",
@@ -179,7 +179,7 @@
         ]
       },
       "claude": {
-        "description": "Use proactively as Lead Fit Builder after lead source approval to persist campaign rubrics from campaign state.",
+        "description": "Use proactively as Lead Fit Builder after review-batch import and filter approval to persist campaign rubrics from campaign state.",
         "model": "inherit",
         "background": true,
         "maxTurns": 8,
@@ -211,11 +211,7 @@
         "token fill rules",
         "rendered sample"
       ],
-      "optionalProducesArtifacts": [
-        "message-validation.md",
-        "message-prep.md",
-        "message-candidate-drafts.md"
-      ],
+      "optionalProducesArtifacts": [],
       "ownership": "proof inventory, token strategy, angle drafting, skeptical-prospect review, and selected winner only",
       "codex": {
         "description": "Message Draft Builder for campaign-backed template proposals after confirm_lead_list imports a non-empty bounded review batch.",

package/bin/sellable-install.mjs

@@ -40,7 +40,7 @@ function getMcpVersion() {
   } catch {}
   return "latest";
 }
-const CODEX_PLUGIN_VERSION = "0.1.31";
+const CODEX_PLUGIN_VERSION = "0.1.32";
 const CODEX_PLUGIN_COMPAT_VERSIONS = [
   "0.1.8",
   "0.1.9",
@@ -630,8 +630,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
-- "I can create a draft shell for you to watch, but no leads import and nothing
-  sends until you approve", not mutation jargon
+- "I can create a draft shell for you to watch with approval gates before
+  sourcing", 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
@@ -960,7 +960,7 @@ updates.
    supplemental approval checklist, not a replacement for the long prompt. Use
    campaign state, campaign brief content, selected source state, and imported
    review-batch rows as the source of truth; do not read stale local markdown,
-   inspect the database directly, or synthesize \`message-validation.md\` from
+   inspect the database directly, or synthesize local validation artifacts from
    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

package/package.json

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

package/skill-templates/create-campaign.md

@@ -86,7 +86,7 @@ or tool discovery. Start in product language:
 ```text
 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.
+before we move into lead sourcing.
 ```
 
 If a linked/local skill file is stale or missing, silently use the installed
@@ -102,8 +102,14 @@ 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
-- "I can create a draft shell for you to watch, but no leads import and nothing
-  sends until you approve", not mutation jargon
+- "I can create a draft shell for you to watch with approval gates before
+  sourcing", not mutation jargon
+
+Approval and safety copy should be tasteful. State what the current approval
+covers once, in one short sentence, then move on. Do not append repeated
+"nothing starts / no leads import / no sending" disclaimers to routine progress
+updates. Use positive gate language like "Next gate: selected-post scrape" or
+"Approval covers scouting/search only" instead of long negative lists.
 
 When explaining lead-source decisions, show the concrete counts behind the
 logic: lanes searched, timeframe, raw result counts, finalist posts or preview
@@ -127,7 +133,7 @@ authorizes scouting/search only. The gate should say:
 - why that lane fits the buyer, offer, and likely public activity
 - what will be tested next
 - the fallback lane if relevant posts or ICP engagement look thin
-- that approval authorizes scouting/search only, not lead import or sending
+- what approval covers in one concise line
 
 Do not surface blanket source heuristics as product copy. Make the
 recommendation specific to the campaign. If Signal Discovery is recommended,
@@ -142,6 +148,20 @@ Signal Discovery, name how many selected posts will be scraped, the target
 engager/source-candidate volume, and the bounded review-batch size. For Sales
 Nav or Prospeo, name the specific approved import lane. Do not call
 `import_leads` or `confirm_lead_list` until this second approval is granted.
+For Signal Discovery, the customer-facing approval card must use the exact
+action shape "Approve scraping N Signal Discovery posts?" and the chat summary
+should be a compact `## Source Recommendation` block with:
+
+- goal: about 300 good-fit prospects after cleanup, enrichment, and filters
+- working assumption: about 15% of raw post engagers become good-fit prospects
+- engagers needed: about 2,000 raw engagers
+- a selected-post table with post author/topic, why it fits, and visible
+  engagement
+- total visible pool and estimated good-fit pool
+- first pass: build the source list, then import only 15 leads into the review
+  batch
+- fallback: switch to Sales Nav recent activity if the review batch is
+  vendor-heavy, agency-heavy, or off-ICP
 
 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:
@@ -159,8 +179,8 @@ 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.
+chat, call the downstream copy stage `message generation`; message validation is
+only an internal approval proof.
 
 For campaign-attached Signal Discovery sampling, promote/select the exact posts
 with `select_promising_posts` before `fetch_post_engagers` so the user can see
@@ -168,19 +188,17 @@ which posts are being sampled in the watched app. The watch guide should say
 that we are pulling sample engagers from these posts to confirm the ICP is
 actually engaging and the source is viable.
 
-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 and the current session exposes the returned names. Message
-generation is the provisional Message Draft Builder: it may start after the
-review batch exists, including while the user is on filter choice, but workflow
-cell execution must wait. After rubrics are saved, do not queue enrichment,
-filtering, or Generate Message cells until the user approves the message
-template. AI Generated is an explicit opt-out that cancels or ignores the
-background template draft. If the post-lead agents are absent, the main thread
-still orchestrates the same branches from the compact context with MCP
-tools/assets.
+After the bounded review batch exists, use the same registry pattern for
+post-lead work. The create-campaign-v2 subskill calls
+`get_post_find_leads_scout_registry`, then launches the returned
+message-generation scout immediately when real subagents are available and the
+current session exposes the returned name. If the user chooses filters, launch
+the filter-leads scout then and join it with the already-running or completed
+message draft before message review. Workflow cell execution still waits for
+filter and template approval. AI Generated is an explicit opt-out that cancels
+or ignores the background template draft. 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
@@ -412,7 +430,7 @@ 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.
+are sourced.
 ```
 
 Do not silently ask Codex intake or approval questions as plain chat when
@@ -597,7 +615,7 @@ updates.
    supplemental approval checklist, not a replacement for the long prompt. Use
    campaign state, campaign brief content, selected source state, and imported
    review-batch rows as the source of truth; do not read stale local markdown,
-   inspect the database directly, or synthesize `message-validation.md` from
+   inspect the database directly, or synthesize local validation artifacts from
    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
@@ -609,9 +627,11 @@ updates.
    call `mcp__sellable__update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
    so the watched app moves to Filter Rules while rubrics are drafted/saved.
    After rubrics save, move the watched app to `apply-icp-rubric` / Filter
-   Leads and say the fit rules are saved; approve the message template next;
-   after approval, queue the bounded review-batch
-   `enrichCellId` cells to kick off enrichment/filtering.
+   Leads and say the fit rules are saved; approve the message template next
+   while the browser stays on Filter Leads. After approval, save the template
+   to the campaign brief, then queue the bounded review-batch `enrichCellId`
+   cells to kick off enrichment/filtering. Move to Messages only after at
+   least one review row passes and Generate Message cells are running or ready.
    Product Generate Message cells must not run from the background template
    path before that template/token approval.
    Do not ask the user to approve the brief before shell creation unless they
@@ -621,14 +641,14 @@ updates.
    visible work so the user can watch progress in the app: `create-offer` for
    the brief, `pick-provider` or the selected provider step while sourcing,
    `filter-choice` after the 15-row review batch, `create-icp-rubric` as soon
-   as filters are approved, `apply-icp-rubric` after rubrics save, `messages`
-   for the Use Template / AI Generated mode
-   choice, `auto-execute-messaging` for approved
-   message work or the product's AI-generated path, `awaiting-user-greenlight`
-   for the final handoff, `settings` for sender selection, `sequence` after
-   sender attach, and `send` once the recommended sequence is attached.
-   `validate-sample` is recovery/legacy only if reached. Do not advance the
-   step backward.
+   as filters are approved, `apply-icp-rubric` after rubrics save and while
+   waiting for message-template approval, `validate-sample` while the approved
+   template unlocks bounded enrichment/filter scoring on Filter Leads,
+   `auto-execute-messaging` after at least one row passes and review-batch
+   messages are being generated or reviewed, `awaiting-user-greenlight` only
+   after generated review-batch messages are approved, `settings` for sender
+   selection, `sequence` after sender attach, and `send` once the recommended
+   sequence is attached. Do not advance the step backward.
 7. Keep `selectedLeadListId` as the source list and `workflowTableId` as the
    campaign table. Do not use disk files as the post-mint source of truth.
 8. Do not ask the user to run another command.