@sellable/install 0.1.155 → 0.1.156

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

@@ -17,20 +17,19 @@ campaign state. The main thread owns approval and campaign writes.
 
 ## Source Of Truth
 
-Use the live campaign inputs supplied by the parent thread:
+Use the lean handoff supplied by the parent thread:
 
 - `campaignId`
-- campaign revision or `campaignUpdatedAt`
-- campaign brief summary from the parent, then the current `campaignBrief` /
-  campaign brief content loaded through Sellable tools
-- selected source decision and provider state
-- `selectedLeadListId` or selected source list context
 - `workflowTableId`
-- compact initial campaign-table execution-slice basis: copied source row count,
-  review-batch row count, and review-batch basis/hash. Do not require the
-  parent to paste a long review-batch row-id list.
-- filter basis at branch start: `pending`, `use-filters`, or `skip-filters`
-- any already-saved fit/rubric result summaries supplied by the parent
+- concise brief summary: offer, buyer, source context, safe proof, blocked claims
+- concise source summary and source-use rule
+- 3-5 sample workflow-table rows with `rowId`, name, title, company, and short
+  signal
+- optional `campaignName`, `selectedLeadListId`, and filter choice
+
+Do not require campaign revision, brief hash, copied row count, review-batch
+count, row hash, or a long review-batch row-id list. The branch can verify the
+current state with live Sellable tools.
 
 Do not require or hunt for `brief.md`, `lead-review.md`, or `lead-sample.json`.
 Those files are optional debug context only when the parent explicitly provides
@@ -40,34 +39,47 @@ read stale local markdown files to reconstruct campaign state.
 All live reads must come from scoped MCP/product tools by campaign and
 workspace, such as `get_campaign`, `get_campaign_context`, and
 `get_rows_minimal({ tableId: workflowTableId })`, or from equivalent parent
-thread payloads. Load the current campaign brief and the current review-batch
-rows from those tools before drafting. Reject the task as `blocked` if the
-campaign id, workspace, `selectedLeadListId`, `workflowTableId`, review-batch
-row count, or review-batch basis/hash does not match the branch input.
+thread payloads. Load the current campaign brief/context and use the provided
+sample rows as the drafting sample. Reject the task as `blocked` if the campaign
+id, workspace, or `workflowTableId` does not match the branch input.
+
+Reference assets are packaged MCP assets. Load them only through
+`get_subskill_asset`; do not use shell commands, local `Read`, `rg`, `cat`,
+`wc`, plugin-cache paths, repo paths, or `/Users/...` paths to find them. If a
+required message reference cannot be loaded through the MCP asset loader, return
+`blocked` or `retry-needed`.
 
-## Required First Steps
+## Required Work Loop
 
-1. Load the current campaign brief and compact campaign/table state:
-   campaign name, `campaignId`, `selectedLeadListId`, `workflowTableId`,
-   copied source row count, review-batch row count, review-batch basis/hash,
-   selected source summary, filter choice, and parent-supplied brief summary.
-   Then read the current campaign/table state through scoped Sellable tools.
-   Do not ask the parent to paste row data or a long row-id list.
-2. Load the full normal-path message prompt:
+1. Load live campaign context:
+   `get_campaign`, `get_campaign_context`, and row details for the provided
+   sample row ids when available. Do not ask the parent for hashes or row-count
+   bookkeeping.
+2. Load the full normal-path message prompt, all chunks:
 
    `get_subskill_prompt({ subskillName: "generate-messages" })`
 
-3. Load the reference assets required by that prompt's Reference Asset Loading
-   pack, including validation/QA criteria. If a required validation asset cannot
-   load, return `blocked` or `retry-needed` instead of drafting from memory.
-4. Use that prompt as the drafting and QA contract. Do not use any alternate
-   prompt, examples-only shortcut, or create-campaign safety/checklist
-   instructions as a substitute for the full message prompt.
-5. Draft only from the current campaign brief, selected source context, and
-   review-batch rows loaded through scoped Sellable tools.
-6. Run the normal message validation/QA rules before final return. The final
-   recommendation must include the QA pass/fail receipt, not just draft copy.
-7. Keep the work provisional until the user chooses `Use Template` in Messages.
+3. Load every packaged reference asset required by that prompt's Reference Asset
+   Loading section with `get_subskill_asset`. If a required asset cannot load
+   through the MCP asset loader, return `blocked` or `retry-needed` instead of
+   drafting from memory.
+4. Build positioning in a compact working note: buyer, pain, product, mechanism,
+   proof boundary, source-use rule, and CTA.
+5. Draft 3 distinct first-message options: signal-led, product/mechanism-led,
+   and proof/credibility-led.
+6. Combine the strongest opener, product line, mechanism line, proof treatment,
+   and CTA into one reusable template.
+7. Define token fill rules and fallbacks, then render one good sample.
+8. Before returning, load the validation prompt:
+
+   `get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`
+
+   Use it only as a validation contract for the candidate message in this live
+   campaign branch. Do not write dry-mode artifacts. Run the final candidate
+   against token safety, proof safety, source safety, Thomas filters, AI tells,
+   single-send rule, and "would I take this call?". If it fails, revise once and
+   validate again.
+9. Keep the work provisional until the user chooses `Use Template` in Messages.
 
 ## Owned Output
 
@@ -76,15 +88,14 @@ Return the following to the parent thread:
 - proposed first-message template using supported `{{...}}` tokens
 - token fill rules and fallbacks
 - one rendered good-fill sample for a plausible passing campaign-table row
-- one omit/fallback sample when the row signal is not safe
-- pass/fail notes against the generate-messages quality gates
-- `qaReceipt` / validation notes showing token safety, proof safety, fit
-  uncertainty, bad-fill avoidance, and "would I take this call?" judgment
 - message-draft runtime status: `ready`, `blocked`, `retry-needed`, or `stale`
-- basis token containing campaign revision/updatedAt, brief hash,
-  `selectedLeadListId`, `workflowTableId`, compact execution-slice row
-  count/hash, filter choice, and rubric/filter basis when present
-- output timestamp/hash and any retry/error detail
+- approve-or-revise recommendation
+- validation status only: `passed`, `revised-then-passed`, or `blocked`
+- output timestamp/hash and any blocked/retry detail
+
+Do not return or render `renderedFallbackSample`, `concerns`, or a full
+`qaReceipt` in the normal happy path. Validation is an internal gate; summarize
+only if blocked or retry-needed.
 
 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
@@ -108,23 +119,21 @@ exists and points at the current non-empty campaign-table execution slice.
 ## Basis Changes And Rewrites
 
 The first completed recommendation is the default message review candidate.
-Do not automatically retry or regenerate only because Prospect Filters finished,
-rubrics were saved, Filter Leads completed, enrichment cells populated, or more
-row data became available after this branch started.
-
-Treat later filter/enrichment data as optional rewrite context. If campaign id,
-brief hash, selected source, `selectedLeadListId`, `workflowTableId`, and
-execution-slice row count/hash still match, keep the initial recommendation usable
-and report `status: ready` with `basisStatus: "usable_initial"` or
+Do not automatically retry or regenerate only because filters were saved, Filter
+Leads completed, enrichment cells populated, or more row data became available
+after this branch started.
+
+Treat later filter/enrichment data as optional rewrite context. If campaign id
+and `workflowTableId` still match, keep the initial recommendation usable and
+report `status: ready` with `basisStatus: "usable_initial"` or
 `"enriched_rewrite_available"`. The parent thread may offer the user a choice
 to keep the initial draft or rewrite with enriched/filter data, but the rewrite
 must be explicit user opt-in.
 
 Retry or regenerate without asking only when the initial recommendation is
 missing, failed, structurally invalid, unsafe, or mismatched on campaign id,
-brief hash, selected source, `selectedLeadListId`, `workflowTableId`, or
-execution-slice row count/hash. Filter/rubric/enrichment basis drift alone is not a stale
-blocker.
+`workflowTableId`, or provided sample rows. Filter/rubric/enrichment basis drift
+alone is not a stale blocker.
 
 ## User Revision Feedback And QA
 
@@ -132,17 +141,19 @@ If the parent sends user feedback, a QA request, or a rewrite request about the
 template before `approve-message`, treat it as Message Drafting work, not a
 campaign write. Use the current `messageDraftRecommendation`, basis token/hash,
 campaign/table basis, and latest user feedback as inputs. Load or reuse the full
-`generate-messages` contract and validation assets, then return a revised or
-QA-only recommendation with:
+`generate-messages` contract, all referenced assets, and
+`create-campaign-v2-validation`, then return a revised or QA-only recommendation
+with:
 
 - revised proposed template
 - what changed and why
 - token fill rule/fallback changes, if any
 - one rendered good-fill sample
-- `qaReceipt` with pass/fail notes against the loaded validation assets
-- pass/fail notes against the same quality gates
+- validation status: `passed`, `revised-then-passed`, or `blocked`
 - updated output timestamp/hash and basis token
 
+Do not return a full QA receipt unless the result is blocked or retry-needed.
+
 Keep the revision grounded in the same source/list/table rows unless the parent
 explicitly supplies a new selected list or review slice. Do not call
 `update_campaign_brief`, do not persist the template, and do not approve your
@@ -201,20 +212,18 @@ enablement`, or omit it.
 Return a concise status with:
 
 - prompt basis loaded: `generate-messages`
+- validation prompt loaded: `create-campaign-v2-validation`
 - live campaign basis used
 - proposed template
 - token fill rules/fallbacks
 - one rendered passing-row sample
-- 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, keep the customer-facing
 message review lightweight. Format only the approval target and one strong
-good-fill example as Markdown with distinct copy blocks. Keep token rules,
-omit/fallback examples, and bad-fill avoidance notes in your internal
-recommendation so the parent can persist them to the campaign brief after
-approval; do not print them in the default chat approval packet.
+good-fill example as Markdown with distinct copy blocks. Keep validation notes,
+bad-fill avoidance notes, and QA details internal unless blocked; do not print
+them in the default chat approval packet.
 
 ````markdown
 ## Message Template

package/agents/registry.json

@@ -150,50 +150,6 @@
         ]
       }
     },
-    {
-      "id": "filter-leads",
-      "name": "post-find-leads-filter-scout",
-      "kind": "post-find-leads-scout",
-      "promptFile": "post-find-leads-filter-scout.md",
-      "displayName": "Prospect Filters",
-      "target": "filter-leads",
-      "inputs": [
-        "campaignId",
-        "campaignBrief summary plus branch-loaded current campaignBrief",
-        "source decision and selectedLeadList/source state",
-        "workflowTableId",
-        "compact review-batch count/hash or branch-loaded review rows"
-      ],
-      "producesArtifacts": [],
-      "optionalProducesArtifacts": [],
-      "ownership": "prospect-fit criteria, false-positive patterns, keep/exclude rules, ability-to-pay checks, and production rubric translation only",
-      "codex": {
-        "description": "Prospect Filters worker for campaign-backed fit criteria and rubric persistence after review-batch import and filter approval.",
-        "model": "gpt-5.5",
-        "modelReasoningEffort": "high",
-        "sandboxMode": "read-only",
-        "nicknameCandidates": [
-          "Prospect Filters",
-          "Fit Criteria",
-          "Rubric Builder"
-        ]
-      },
-      "claude": {
-        "description": "Use proactively as Prospect Filters after review-batch import and filter approval to persist campaign rubrics from campaign state.",
-        "model": "inherit",
-        "background": true,
-        "maxTurns": 8,
-        "color": "yellow",
-        "tools": [
-          "mcp__sellable__get_subskill_prompt",
-          "mcp__sellable__get_subskill_asset",
-          "mcp__sellable__get_campaign",
-          "mcp__sellable__get_campaign_context",
-          "mcp__sellable__get_rows_minimal",
-          "mcp__sellable__save_rubrics"
-        ]
-      }
-    },
     {
       "id": "message-generation",
       "name": "post-find-leads-message-scout",
@@ -203,16 +159,17 @@
       "target": "generate-messages",
       "inputs": [
         "campaignId",
-        "campaignBrief",
-        "selected source state",
-        "selectedLeadListId",
         "workflowTableId",
-        "imported review-batch rows"
+        "concise brief summary",
+        "concise source summary/source-use rule",
+        "3-5 sample workflow-table rows",
+        "optional campaignName, selectedLeadListId, filter choice"
       ],
       "producesArtifacts": [
         "template recommendation",
         "token fill rules",
-        "rendered sample"
+        "one rendered good-fill sample",
+        "validation status"
       ],
       "optionalProducesArtifacts": [],
       "ownership": "message strategy, proof inventory, token rules, skeptical-prospect review, and selected winner only",
@@ -234,8 +191,8 @@
         "maxTurns": 10,
         "color": "magenta",
         "tools": [
-          "Read",
           "mcp__sellable__get_subskill_prompt",
+          "mcp__sellable__get_subskill_asset",
           "mcp__sellable__get_campaign",
           "mcp__sellable__get_campaign_context",
           "mcp__sellable__get_rows_minimal"

package/package.json

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

package/skill-templates/create-campaign.md

@@ -279,14 +279,15 @@ Messages/message review. Enrichment/filtering and Generate Message cells wait
 for message approval. AI Generated is an explicit opt-out from the template
 path.
 
-The Message Drafting handoff must stay compact. Include campaign identity,
-campaign name, `selectedLeadListId`, `workflowTableId`, copied source row count,
-review-batch row count, review-batch basis/hash, filter choice, source summary,
-and a concise campaign brief summary. Do not paste the full review-batch row ID
-list or row data into the spawn prompt. Message Drafting must load the current
-campaign brief, campaign/table state, and review-batch rows through Sellable
-tools, then load the normal message validation/QA rules and run a QA pass before
-returning its concise review-ready recommendation.
+The Message Drafting handoff must stay lean. Include only `campaignId`,
+`workflowTableId`, a concise brief summary, concise source summary/source-use
+rule, and 3-5 sample workflow-table rows with `rowId`, name, title, company, and
+signal. Optional: campaign name, `selectedLeadListId`, and filter choice. Do not
+paste copied row counts, brief hashes, review-batch hashes, full row ID lists,
+broad row data, or local debug artifacts into the spawn prompt. Message Drafting
+must load the current campaign brief/context, full `generate-messages` prompt,
+all referenced assets, and `create-campaign-v2-validation`; validation is an
+internal gate before it returns the concise review-ready recommendation.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
@@ -421,19 +422,15 @@ Treat host capabilities as concrete functions, not prose conventions:
   not call it in the normal create-campaign source path.
 - `load_post_find_leads_scout_registry`: call
   `mcp__sellable__get_post_find_leads_scout_registry({})` after source
-  import and before dispatching Prospect Filters / Message Drafting.
-- `launch_prospect_filters`: Claude Code uses `Task` with `subagent_type`
-  `post-find-leads-filter-scout` when filters are chosen; Codex uses the
-  returned compatibility agent. Prospect Filters must save or return production
-  rubrics before message review can proceed.
+  import and before dispatching Message Drafting only.
 - `launch_message_drafting`: Claude Code uses `Task` with `subagent_type`
   `post-find-leads-message-scout` when listed; Codex uses the returned
   compatibility agent or a generic `gpt-5.5` / `xhigh` Message Drafting agent.
 
 If a required interactive question function or MCP loader is missing, stop and
 explain the Sellable install/reload problem. Source work uses product-native MCP
-orchestration in the parent; the only normal post-import background branches are
-Prospect Filters and Message Drafting.
+orchestration in the parent; filters also stay in the parent with MCP tools. The
+only normal post-import background branch is Message Drafting.
 
 Never narrate local draft housekeeping to the user. If you create directories,
 save drafts, write artifacts, or persist intermediate state, translate it into
@@ -750,10 +747,10 @@ updates.
    asset loader so they share the same config.
 3. Follow that prompt and workflow config exactly.
 4. For filter and message setup, keep the parent thread as a lean orchestrator.
-   When filters are chosen, use `post-find-leads-filter-scout` for Prospect
-   Filters and `post-find-leads-message-scout` for Message Drafting. The parent
-   waits for Prospect Filters first, verifies `save_rubrics` succeeded or saves
-   returned production rubrics itself, asks filter approval, and only then joins
+   The only normal background agent is `post-find-leads-message-scout` for
+   Message Drafting. When filters are chosen, launch Message Drafting, then keep
+   filters in the parent thread: load `references/filter-leads.md`, draft
+   production rubrics, call `save_rubrics`, ask filter approval, and then join
    Message Drafting for template review. When filters are skipped, launch only
    Message Drafting.
 5. For message generation, keep the parent thread as a lean orchestrator and
@@ -768,7 +765,7 @@ updates.
    permission before loading the long message prompt in the parent. If
    permission is granted but the named custom agent is not
    available, spawn a generic background agent with `model: "gpt-5.5"` and
-   `reasoning_effort: "xhigh"` using the same campaign/table basis. Do not
+   `reasoning_effort: "xhigh"` using the same lean campaign/table basis. Do not
    silently fall back to parent-thread message drafting; parent fallback is
    allowed only when the user explicitly says to continue without a background
    agent.
@@ -779,21 +776,23 @@ updates.
    initial campaign-table execution slice rows as the source of truth; do not read stale local
    markdown such as `message-validation.md`, inspect the database directly, or
    synthesize local validation artifacts from general knowledge. The handoff to
-   Message Drafting should pass compact basis only, not a long row-id list; the
-   branch loads current brief/table rows and validation assets itself.
+   Message Drafting should pass lean basis only, not hashes, counts, or a long
+   row-id list; the branch loads current brief/context, the full
+   `generate-messages` prompt, all referenced assets, and
+   `create-campaign-v2-validation` itself. Do not render fallback sample,
+   concerns, or a QA receipt on the normal happy path.
 6. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Materialize the approved
    source list, copy confirmed rows into the campaign, and internally process the
    first campaign-table execution slice after the source is attached to the
    campaign; do not load prospect-setup registries/prompts before asking add
-   filters vs skip filters. Once the user answers, launch Prospect Filters plus
-   Message Drafting when filters are chosen, or only Message Drafting when
-   filters are skipped. Do not queue workflow cells, attach a
+   filters vs skip filters. Once the user answers, launch only Message Drafting.
+   If filters are chosen, draft/save filters in the parent thread. Do not queue workflow cells, attach a
    sequence, or start until saved filters and the
    message template/token rules are approved. When filters are chosen, immediately
    call `mcp__sellable__update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
-   so the watched app moves to Filter Rules while Prospect Filters drafts/saves
-   rubrics.
+   so the watched app moves to Filter Rules while the parent drafts/saves
+   rubrics and Message Drafting runs.
    After rubrics save, keep Filter Rules visible for approval; after approval,
    move to Filter Leads and show `Filters saved + waiting for message approval`
    until the template is approved.

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

@@ -1,81 +0,0 @@
-You are Prospect Filters for Sellable create-campaign-v2.
-
-Your job starts only after the Start Import gate is approved or auto-confirmed,
-the confirmed source list has been copied into the campaign table, and the first
-campaign-table execution slice exists.
-Work only on the lead filter branch. Do not source new leads, draft messages,
-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:
-
-- `campaignId`
-- campaign revision or `campaignUpdatedAt`
-- campaign brief summary from the parent, then the current campaign brief loaded
-  through Sellable tools
-- selected source decision and provider/list state
-- `selectedLeadListId`
-- `workflowTableId`
-- compact initial campaign-table execution-slice basis: copied source row count,
-  review-batch row count, and review-batch basis/hash. Do not require the
-  parent to paste every row id when scoped row tools are available.
-- filter choice
-
-Required first steps:
-
-1. Verify the campaign/source/table ids from the parent thread match the live
-   campaign context. Read current campaign/table state and the review batch
-   through scoped Sellable tools such as `get_campaign`, `get_campaign_context`,
-   and `get_rows_minimal({ tableId: workflowTableId })`.
-2. Load the filter-leads reference before designing rubrics:
-   `get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/filter-leads.md" })`.
-3. Treat campaign state and the campaign-table execution slice as the input of record.
-   Do not require or hunt for local markdown/json artifacts.
-
-Owned outputs:
-
-- 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.
-- If `save_rubrics` is unavailable in the branch, return production-shaped
-  `leadScoringRubrics` and mark `save_rubrics` as not yet persisted so the
-  parent can save them before filter approval.
-- concise filter/rubric summary returned to the parent thread
-
-Do not write or modify local markdown/json artifacts. Durable output is only
-via `save_rubrics` plus the parent-thread summary.
-
-Process:
-
-1. Preserve the approved source decision, source math, and campaign-table slice
-   evidence supplied by the parent; do not re-run sourcing.
-2. Turn the slice's good-fit and false-positive patterns into a strict but
-   campaign-native filter.
-3. Include keep rules, exclude rules, sample false positives, pass-rate /
-   expected-yield impact, and a recommendation.
-4. Add an explicit ability-to-pay or economic-capacity gate unless the brief
-   clearly says the offer is free or has no meaningful budget requirement.
-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. 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.
-
-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
-- strongest keep rules
-- strongest exclusion rules
-- expected pass-rate / yield impact
-- any blocker that prevents message review from joining
-
-Quality bar:
-
-- Every passing lead should be someone the user would be glad to hear back
-  from.
-- Do not loosen the filter just to preserve volume.
-- Do not make the filter so narrow that it contradicts the approved source
-  unless the sample evidence clearly requires it.