@sellable/mcp 0.1.208 → 0.1.210

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,47 +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",
-        "source decision and selectedLeadList/source state",
-        "workflowTableId",
-        "imported review-batch 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__save_rubrics"
-        ]
-      }
-    },
     {
       "id": "message-generation",
       "name": "post-find-leads-message-scout",
@@ -200,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",
@@ -231,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/dist/tools/leads.js

@@ -660,12 +660,10 @@ function analyzeFilterChoiceSample(sampleRows) {
     const fitRatio = fitCount / sampleCount;
     const cleanupRatio = cleanupCount / sampleCount;
     const adjacentRatio = adjacentIndexes.length / sampleCount;
-    const maxCleanRiskCount = Math.max(2, Math.floor(sampleCount * 0.12));
-    const recommendation = fitRatio >= 0.75 &&
-        cleanupCount <= maxCleanRiskCount &&
-        adjacentRatio <= 0.3
+    const allReviewedRowsLookFit = fitCount === sampleCount && cleanupCount === 0;
+    const recommendation = allReviewedRowsLookFit && adjacentRatio <= 0.3
         ? "skip"
-        : fitRatio >= 0.6 && cleanupRatio <= 0.3
+        : fitRatio >= 0.75 && cleanupRatio <= 0.3
             ? "light-filter"
             : "add-filter";
     return {
@@ -697,17 +695,20 @@ function buildFilterChoiceWatchNarration({ sourceLeadCount, reviewRowCount, samp
         : "Sample rows were not available to inspect, so this is a manual filter decision.";
     const fitExamples = formatExamples("Fit examples:", assessment.strongExamples);
     const riskExamples = formatExamples("Cleanup examples:", assessment.riskExamples);
+    const lightFilterReason = cleanupCount > 0
+        ? `${cleanupCount} of ${assessment.sampleCount} need cleanup or manual review`
+        : `${assessment.adjacentCount} of ${assessment.sampleCount} look adjacent instead of clear target-role fits`;
     const headline = assessment.recommendation === "skip"
-        ? "Filtering may not be needed"
+        ? "Filters optional for clean sample"
         : assessment.recommendation === "light-filter"
             ? "I recommend light cleanup filters"
             : assessment.recommendation === "manual-review"
                 ? "Review filters or skip"
                 : "I recommend adding filters";
     const agentIntent = assessment.recommendation === "skip"
-        ? `Codex is not recommending filters because the sample already looks clean. ${fitExamples} Add filters only for a narrow exclusion.`
+        ? `Codex is not recommending filters because every reviewed row already looks like a target-role fit. ${fitExamples} Add filters only if the user wants an extra narrow exclusion.`
         : assessment.recommendation === "light-filter"
-            ? `Codex is recommending light filters because most rows fit, but ${cleanupCount} of ${assessment.sampleCount} look adjacent, unknown, or risky. ${riskExamples}`
+            ? `Codex is recommending light filters because the sample is strong but not perfectly clean: ${lightFilterReason}. ${riskExamples}`
             : assessment.recommendation === "manual-review"
                 ? "Codex could not inspect the review rows, so it is pausing for a manual filter decision instead of assuming filters are required."
                 : `Codex is recommending filters because ${cleanupCount} of ${assessment.sampleCount} sampled rows look adjacent, unknown, or risky before message review. ${riskExamples}`;

package/dist/tools/prompts.d.ts

@@ -86,7 +86,7 @@ export interface SourceScoutRegistryResponse {
 }
 export interface PostFindLeadsScoutRegistryResponse {
     version: number;
-    trigger: "message_drafting_after_confirm_lead_list";
+    trigger: "prospect_setup_after_confirm_lead_list";
     requiredInputs?: string[];
     scouts: Array<{
         id: string;

package/dist/tools/prompts.js

@@ -157,7 +157,7 @@ export const promptToolDefinitions = [
     },
     {
         name: "get_post_find_leads_scout_registry",
-        description: "Return the canonical Sellable Message Drafting worker name after Start Import copies confirmed source rows. Prospect filters stay inline in the parent thread in normal create-campaign runs.",
+        description: "Return the canonical Sellable Message Drafting worker name after Start Import copies confirmed source rows. Normal create-campaign uses only this one post-import background agent.",
         inputSchema: {
             type: "object",
             properties: {},
@@ -265,19 +265,17 @@ export function getSourceScoutRegistry() {
 }
 export function getPostFindLeadsScoutRegistry() {
     const registry = readAgentRegistry();
-    const scouts = registry.agents.filter((agent) => String(agent.kind || "") === "post-find-leads-scout" &&
-        String(agent.target || agent.id || "") === "generate-messages");
+    const scouts = registry.agents.filter((agent) => String(agent.kind || "") === "post-find-leads-scout");
     return {
         version: registry.version,
-        trigger: "message_drafting_after_confirm_lead_list",
+        trigger: "prospect_setup_after_confirm_lead_list",
         requiredInputs: [
             "campaignId",
-            "campaign revision or campaignUpdatedAt",
-            "campaignBrief",
-            "source decision and selectedLeadList/source state",
             "workflowTableId",
-            "compact review-batch row count and basis/hash; branch reads rows through scoped tools",
-            "filter choice and filter/rubric basis when present",
+            "concise brief summary",
+            "concise source summary and source-use rule",
+            "3-5 sample workflow-table rows with rowId/name/title/company/signal",
+            "optional selectedLeadListId, campaignName, and filter choice",
         ],
         scouts: scouts.map((agent) => ({
             id: String(agent.id || ""),
@@ -308,8 +306,8 @@ export function getPostFindLeadsScoutRegistry() {
             afterAllComplete: true,
             requiredState: ["messageDraftRecommendation"],
             noFilterRequiredState: ["messageDraftRecommendation"],
-            skipFilterRule: "leadScoringRubrics may be absent only when the user explicitly skips filters with enableICPFilters=false; messageDraftRecommendation is still required before template review.",
-            show: ["sample_message_for_approval", "message_qa_receipt"],
+            skipFilterRule: "Filters are parent-thread MCP work. The only background worker is Message Drafting; messageDraftRecommendation is required before template review.",
+            show: ["sample_message_for_approval"],
             nextStage: "message-review",
         },
         messageDraftBranchContract: {
@@ -327,41 +325,38 @@ export function getPostFindLeadsScoutRegistry() {
                 "startedAt",
                 "updatedAt",
                 "basisToken",
-                "basis.selectedLeadListId",
                 "basis.workflowTableId",
-                "basis.reviewSampleRowCount",
-                "basis.reviewSampleRowHash",
+                "basis.sampleRowIds",
             ],
-            promptRequired: 'Load current campaign brief/table state through scoped tools, then get_subskill_prompt({ subskillName: "generate-messages" }); the full generate-messages prompt and its Reference Asset Loading pack, including message validation/QA assets requested by that prompt, are required inside the Message Drafting branch for normal drafting, QA, and user-requested rewrites. If required assets cannot be loaded, return blocked/retry-needed instead of drafting from prompt memory.',
+            promptRequired: 'Load current campaign brief/table state through scoped tools, then get_subskill_prompt({ subskillName: "generate-messages" }) for all chunks. Load every asset named in the generate-messages Reference Asset Loading pack through get_subskill_asset. Before returning, load get_subskill_prompt({ subskillName: "create-campaign-v2-validation" }) and use it as the final internal message-validation gate. Do not use shell/local filesystem reads, repo paths, plugin-cache paths, or /Users paths for message references. If required prompts/assets cannot be loaded through MCP tools, return blocked/retry-needed instead of drafting from memory.',
             basisFields: [
-                "campaign revision or updatedAt",
-                "brief hash",
-                "selectedLeadListId",
+                "campaignId",
                 "workflowTableId",
-                "compact initial campaign-table execution slice row count/hash",
-                "filter choice",
-                "filter/rubric basis when present",
+                "concise brief summary",
+                "concise source summary/source-use rule",
+                "3-5 sample workflow-table rows",
+                "optional selectedLeadListId and filter choice",
             ],
             messageDraftOutputFields: [
                 "templateRecommendation",
                 "tokenFillRules",
-                "renderedSample",
-                "concerns",
+                "renderedGoodSample",
                 "revisionNotes when user feedback triggered a revision",
                 "status",
                 "basisStatus",
                 "basisToken",
-                "qaReceipt or validationNotes",
+                "approveOrReviseRecommendation",
+                "validationStatus only; full QA details only when blocked/retry-needed",
                 "outputAt",
                 "outputHash",
                 "error or retry detail",
             ],
-            reusePolicy: "The first completed Message Drafting recommendation remains the default review candidate. Later Prospect Filters, Filter Leads, enrichment, or rubric completion may make an enriched rewrite available, but does not automatically retry or replace the initial draft unless campaign/brief/source/list/table/review-sample identity mismatches or the initial output failed. User copy feedback before approve-message is an explicit Message Drafting revision and must be routed back through the message branch with the current recommendation and basis.",
+            reusePolicy: "The first completed Message Drafting recommendation remains the default review candidate. Later filters, Filter Leads, enrichment, or rubric completion may make an enriched rewrite available, but does not automatically retry or replace the initial draft unless campaign/table/sample identity mismatches or the initial output failed. User copy feedback before approve-message is an explicit Message Drafting revision and must be routed back through the message branch with the current recommendation and basis.",
         },
         usage: {
-            codex: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not spawn anything before that question. Once the user answers, spawn only Message Drafting from the same campaign/table basis whenever Codex agent-launch policy is satisfied. Treat YOLO/autonomous mode as campaign-scoped permission for this single message background agent. If the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once for permission before loading generate-messages in the parent. If permission is granted and the named custom agent is unavailable, spawn a generic gpt-5.5 xhigh Message Drafting background agent with the same campaign/table basis. If filters are chosen, do filter/rubric work inline in the parent thread while Message Drafting runs, then keep the browser on Filter Leads and show `Filters saved + waiting for message approval` while the message recommendation is reviewed. If filters are skipped, move to Messages/message review.",
-            claude: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not invoke any Task/Agent before that question. Once the user answers, invoke only Message Drafting from the same campaign/table basis. If filters are chosen, do filter/rubric work inline in the parent thread while Message Drafting runs, then keep the browser on Filter Leads and show `Filters saved + waiting for message approval` while the message recommendation is reviewed. If filters are skipped, move to Messages/message review.",
-            parentThreadRule: 'Message Drafting is the only normal create-campaign background agent. If post-find-leads-message-scout is available, run that compatibility agent after the filter-choice answer so it works while the parent thread handles filter/rubric setup inline. In Codex, YOLO/autonomous mode counts as campaign-scoped permission for this single message background agent; if the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once for permission before loading generate-messages in the parent. If permission is granted and the named custom agent is unavailable, spawn a generic gpt-5.5 xhigh Message Drafting background agent with the same campaign/table basis. Do not spawn source scouts or Prospect Filters in the normal create-campaign flow. Do not silently fall back to parent-thread message drafting. The Message Drafting handoff must be compact: campaign identity/name, brief summary, source summary, selectedLeadListId, workflowTableId, copied source row count, review-batch row count/hash, and filter choice. Do not paste full reviewBatchRowIds, row data, or local debug artifacts into the spawn prompt; the branch must load the current campaign brief, campaign/table state, review rows, full generate-messages prompt, and validation/QA assets through scoped tools. The parent may run the message branch inline only if the user explicitly says to continue without a background agent; when doing so, state that message generation is running inline. Local markdown/json files are not normal-path inputs. The filter-choice question is the first post-import user gate; do not load this registry or filter references before it. Message drafting starts after the filter-choice answer, must load get_subskill_prompt({ subskillName: "generate-messages" }) and its Reference Asset Loading plus message validation/QA assets inside the branch or explicitly approved inline fallback, must read live campaign table state through scoped MCP/product tools, and must reject mismatched selectedLeadListId/workflowTableId/campaign/workspace input. Do not use any alternate or examples-only message prompt. User copy feedback, message QA, or rewrite requests before approve-message must be routed back to Message Drafting with the current recommendation, basis token, campaign/table basis, and latest user text; the parent must not rewrite or QA the template from memory and must not call update_campaign_brief before approve-message. On the filter path, the parent thread keeps the browser on Filter Rules after save_rubrics so the user can approve the saved criteria; only then move to Filter Leads, show `Filters saved + waiting for message approval`, and wait there for message approval. Enrichment, filtering, Generate Message cells, sender setup, sequence attach, and launch wait for template approval on the Use Template path. On the skip path, move to Messages/message review and wait for message approval before enrichment or Settings. Do not render message review from checklist or shortcut instructions; message review requires a messageDraftRecommendation whose basis proves the generate-messages prompt and QA assets ran for the current campaign/table execution slice. Do not automatically rerun Message Drafting after filters/enrichment finish; show the initial draft by default and offer an enriched rewrite only with explicit user opt-in.',
+            codex: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not spawn anything before that question. After the answer, launch only Message Drafting whenever Codex agent-launch policy is satisfied. If filters are chosen, the parent stays on Filter Rules and drafts/saves rubrics with MCP tools while Message Drafting runs in the background. If filters are skipped, move to Messages/message review after Message Drafting is ready. Treat YOLO/autonomous mode as campaign-scoped permission for this single post-import worker. If the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once before loading the long message prompt in the parent. If permission is granted and the named Message Drafting custom agent is unavailable, spawn a generic gpt-5.5 xhigh Message Drafting background agent with the same lean campaign/table basis.",
+            claude: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not invoke any Task/Agent before that question. After the answer, invoke only Message Drafting. If filters are chosen, parent drafts/saves rubrics with MCP tools while Message Drafting runs, asks filter approval, then joins Message Drafting. If filters are skipped, invoke only Message Drafting and move to Messages/message review.",
+            parentThreadRule: 'The only normal post-import background worker is Message Drafting; source scouts and separate filter workers stay out of the normal create-campaign path. After the filter-choice answer, launch post-find-leads-message-scout only. If filters are chosen, the parent thread remains the filter writer: keep the browser on Filter Rules, load the filter reference, draft/save rubrics through MCP tools, ask filter approval, then move to Filter Leads while waiting for Message Drafting if needed. Do not move into message review, queue cells, or call update_campaign_brief until saved filters are approved when filters are enabled and messageDraftRecommendation is ready. If filters are skipped, launch only Message Drafting. In Codex, YOLO/autonomous mode counts as campaign-scoped permission for this single post-import worker; if the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once for permission before loading the long message prompt in the parent. If Message Drafting is allowed but the named worker is unavailable, use a generic gpt-5.5 xhigh Message Drafting background agent. Do not silently fall back to parent-thread message drafting. The Message Drafting handoff must be lean: campaignId, workflowTableId, brief summary, source summary/source-use rule, and 3-5 sample workflow-table rows with rowId/name/title/company/signal; optional campaignName, selectedLeadListId, and filter choice are allowed. Do not paste copied row counts, brief hashes, review-batch hashes, full reviewBatchRowIds, broad row data, or local debug artifacts into the message spawn prompt. The message branch must load current campaign brief/context, provided sample rows, the full generate-messages prompt, every referenced asset through get_subskill_asset, and before returning get_subskill_prompt({ subskillName: "create-campaign-v2-validation" }) for the internal validation gate. Local markdown/json files are not normal-path inputs. Message reference assets must be loaded with get_subskill_asset from the installed MCP package; do not use shell/local filesystem reads, repo paths, plugin-cache paths, or /Users paths to satisfy message references. The filter-choice question is the first post-import user gate; do not load this registry or filter references before it. Message drafting starts after the filter-choice answer and must reject mismatched workflowTableId/campaign/workspace input. Do not use any alternate or examples-only message prompt. User copy feedback, message QA, or rewrite requests before approve-message must be routed back to Message Drafting with the current recommendation, lean campaign/table basis, and latest user text; the parent must not rewrite or QA the template from memory and must not call update_campaign_brief before approve-message. The worker validates internally and returns only templateRecommendation, tokenFillRules, renderedGoodSample, status, approveOrReviseRecommendation, validationStatus, outputAt, outputHash, and blocked/retry detail. Do not render renderedFallbackSample, concerns, or a qaReceipt on the normal happy path. On the filter path, the parent thread keeps the browser on Filter Rules after save_rubrics so the user can approve the saved criteria; only then move to Filter Leads, show `Filters saved + waiting for message approval`, and wait there for message approval. Enrichment, filtering, Generate Message cells, sender setup, sequence attach, and launch wait for template approval on the Use Template path. On the skip path, move to Messages/message review and wait for message approval before enrichment or Settings. Do not render message review from checklist or shortcut instructions; message review requires a messageDraftRecommendation whose basis proves the generate-messages prompt, assets, and validation prompt ran for the current campaign/table execution slice. Do not automatically rerun Message Drafting after filters/enrichment finish; show the initial draft by default and offer an enriched rewrite only with explicit user opt-in.',
         },
     };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.208",
+  "version": "0.1.210",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign/SKILL.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
@@ -427,9 +428,9 @@ Treat host capabilities as concrete functions, not prose conventions:
   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 and filter work use
-product-native MCP orchestration in the parent; the only normal background
-branch is Message Drafting.
+explain the Sellable install/reload problem. Source work uses product-native MCP
+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
@@ -745,7 +746,14 @@ 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, keep the parent thread as a lean orchestrator and
+4. For filter and message setup, keep the parent thread as a lean orchestrator.
+   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
    use the `post-find-leads-message-scout` compatibility agent for Message
    Drafting whenever the host exposes it
    and the current host policy allows agent launch. The worker must load
@@ -757,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.
@@ -768,20 +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.
-5. Create the campaign shell early with the v1 brief so the user can open the
+   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 only Message Drafting
-   from the same campaign/table basis. If filters are approved, do filter/rubric
-   work inline in the parent thread. 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 rubrics are drafted/saved.
+   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.