@sellable/mcp 0.1.209 → 0.1.211

package/dist/tools/prompts.js

@@ -157,7 +157,7 @@ export const promptToolDefinitions = [
     },
     {
         name: "get_post_find_leads_scout_registry",
-        description: "Return the canonical Sellable Prospect Filters and Message Drafting worker names after Start Import copies confirmed source rows.",
+        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: {},
@@ -257,9 +257,9 @@ export function getSourceScoutRegistry() {
             legacy: agent.legacy,
         })),
         usage: {
-            codex: "Source finding is parent-thread and sequential by default in create-campaign. Do not launch source scouts in the normal campaign flow. Returned `name` values are for explicit source-comparison/debug runs only.",
-            claude: "Source finding is parent-thread and sequential by default in create-campaign. Do not invoke source-scout Task/Agent workers in the normal campaign flow. Returned `name` values are for explicit source-comparison/debug runs only.",
-            parentThreadRule: "Normal create-campaign source work stays inline in the parent thread with MCP provider tools. Default fallback order: Signal Discovery / LinkedIn engagement, then Sales Nav recent activity, then broader Sales Nav title search, then Prospeo account/contact search. Do not preload every provider prompt; load only the provider prompt for the active sequential source.",
+            codex: "Source finding is parent-thread and sequential in create-campaign. The packaged normal path installs only Message Drafting as a background agent, so this registry intentionally returns no source-scout agents.",
+            claude: "Source finding is parent-thread and sequential in create-campaign. Do not invoke source-scout Task/Agent workers; use MCP provider tools in the parent thread.",
+            parentThreadRule: "Normal create-campaign source work stays inline in the parent thread with MCP provider tools. Do not invoke source-scout Task/Agent workers. Default fallback order: Signal Discovery / LinkedIn engagement, then Sales Nav recent activity, then broader Sales Nav title search, then Prospeo account/contact search. Do not preload every provider prompt; load only the provider prompt for the active sequential source.",
         },
     };
 }
@@ -271,12 +271,11 @@ export function getPostFindLeadsScoutRegistry() {
         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 || ""),
@@ -305,14 +304,10 @@ export function getPostFindLeadsScoutRegistry() {
         })),
         joinGate: {
             afterAllComplete: true,
-            requiredState: ["leadScoringRubrics", "messageDraftRecommendation"],
+            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: [
-                "readable_filters_with_reasons",
-                "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: {
@@ -330,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. If filters are chosen, spawn Prospect Filters and Message Drafting from the same campaign/table basis whenever Codex agent-launch policy is satisfied, then the parent waits for Prospect Filters first, verifies save_rubrics succeeded, asks filter approval, and only then joins Message Drafting for template review. If filters are skipped, spawn only Message Drafting. Treat YOLO/autonomous mode as campaign-scoped permission for these post-import workers. 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 long filter/message prompts 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 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. If filters are chosen, invoke Prospect Filters and Message Drafting from the same campaign/table basis; parent waits for Prospect Filters first, verifies save_rubrics succeeded, asks filter approval, then joins Message Drafting. If filters are skipped, invoke only Message Drafting and move to Messages/message review.",
-            parentThreadRule: 'Post-import background work is limited to Prospect Filters and Message Drafting; source scouts stay out of the normal create-campaign path. If filters are chosen and the workers are available, launch post-find-leads-filter-scout and post-find-leads-message-scout after the filter-choice answer. The parent thread remains the orchestrator: wait for Prospect Filters first, require save_rubrics success or persist the returned production rubrics, keep the browser on Filter Rules, ask filter approval, then move to Filter Leads and join/wait for Message Drafting. Do not move into message review, queue cells, or call update_campaign_brief until saved filters are approved and messageDraftRecommendation is ready. If filters are skipped, launch only Message Drafting. In Codex, YOLO/autonomous mode counts as campaign-scoped permission for these post-import workers; 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 long filter/message prompts 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 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 message spawn prompt; the message branch must load the current campaign brief, campaign/table state, review rows, full generate-messages prompt, and validation/QA assets through scoped tools. 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 background worker is Message Drafting; source work and filter work stay in the parent thread with MCP tools. 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.209",
+  "version": "0.1.211",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign/SKILL.md

@@ -132,7 +132,7 @@ data, compare sources by source volume, sampled ICP fit, activity/warmth
 signals, cleanup risk, and confidence basis. If a user asks for a forecast,
 label it explicitly as not estimated from this run.
 
-Before any provider prompt, search, source scout, or signal-discovery call, show
+Before any provider prompt, search, or signal-discovery call, show
 one source-plan gate and ask for approval. Write this like a fifth grader could
 understand it: short sentences, no internal labels, and no GTM shorthand. The
 order is strict: first show the plan in chat, then open the approval question.
@@ -184,8 +184,9 @@ conversations look unlikely, recommend the specific Sales Nav or Prospeo path
 instead and explain it in plain words once. Do not call `search_signals`,
 `search_sales_nav`,
 `search_prospeo`,
-`fetch_post_engagers`, or provider-scoped subagents until the user approves this
-source plan or explicitly chooses a different source.
+or `fetch_post_engagers` until the user approves this source plan or explicitly
+chooses a different source. Source work stays in the parent thread; do not
+launch source-scout or provider-scoped subagents.
 
 If the user answers a provider approval such as "Approve Prospeo plan" after
 seeing the source plan, that answer satisfies the source-plan gate. Persist the
@@ -250,9 +251,8 @@ summary should be a compact `## Source Recommendation` block with:
 
 Source discovery stays inline in the parent thread for normal create-campaign
 runs. Use the approved provider prompt and MCP tools sequentially; do not spawn
-source-scout background agents unless the user explicitly asks for a source
-comparison/debug run. Do not claim a scout ran unless one did, and do not surface
-install status to the customer. In chat, call the downstream copy stage
+source-scout background agents. The packaged normal path installs only Message
+Drafting as a background agent. In chat, call the downstream copy stage
 `message generation`; message validation/QA is owned by Message Drafting.
 
 For campaign-attached Signal Discovery sampling, promote/select the exact posts
@@ -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,17 +747,21 @@ 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
    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
-   `mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })`.
+   and the current host policy allows agent launch. The worker must load the
+   full `mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })`
+   prompt, every referenced message asset through
+   `mcp__sellable__get_subskill_asset`, and before returning
+   `mcp__sellable__get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`
+   as the internal validation gate.
    In Codex, YOLO/autonomous mode counts as campaign-scoped permission to use
    this single Message Drafting background agent. If the user has not enabled
    YOLO and has not explicitly asked for background agents, subagents, parallel
@@ -768,7 +769,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 +780,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/skills/create-campaign-v2/SKILL.md

@@ -208,8 +208,8 @@ Only then persist `leadSourceType`, `leadSourceProvider`, and provider `currentS
 Source work stays inline in the parent thread in normal create-campaign runs.
 Do not launch source-scout background agents. Run the approved provider probes
 with MCP tools, loading only the provider prompt for the active sequential
-source. Use source scouts only if the user explicitly asks for a source
-comparison/debug run.
+source. The packaged normal path installs only Message Drafting as a background
+agent.
 Use a 10% planning floor after cleanup. If LinkedIn engagement falls below it,
 move to Sales Nav, then Prospeo. If Prospeo also falls below 10%, tighten the
 ICP/source direction instead of inventing another provider.
@@ -270,67 +270,66 @@ customer-facing work before the question should be a short setup summary and the
 add filters, skip filters, or revise source. Do not include another watch link
 in this summary; the existing app view updates through campaign state.
 
-Once filter choice is known, use the post-import workers for the heavy prompt
-work. If the user chooses filters, launch both Prospect Filters
-(`post-find-leads-filter-scout`) and Message Drafting
-(`post-find-leads-message-scout`) from the same campaign/table basis. If filters
-are skipped, launch only Message Drafting and move the watched app to Messages.
-Debug markdown/json artifacts are optional only.
-
-The parent thread is the orchestrator, not the writer of long filter/message
-logic. On the filters path, after spawning both workers, the parent must wait for
-Prospect Filters first. Do not join Message Drafting, render message review, or
-move to Filter Leads until Prospect Filters has either successfully called
-`save_rubrics` or returned production-shaped rubrics that the parent then saves
-with `save_rubrics`. If neither happened, block and report the filter-save
-failure. Only after saved filters are verified should the parent ask for filter
-approval, then wait for Message Drafting if it is still running.
-
-Keep the Message Drafting handoff compact: campaign identity/name,
-`selectedLeadListId`, `workflowTableId`, copied-row count, review-batch
-count/hash, filter choice, source summary, and a concise brief summary. Do not
-paste the full row ID list or row data. The branch loads the current brief,
-table state, and review rows through Sellable tools before drafting.
+Once filter choice is known, the only normal background worker is Message
+Drafting (`post-find-leads-message-scout`). If filters are chosen, launch
+Message Drafting, then keep filter drafting in the parent thread with MCP tools.
+If filters are skipped, launch only Message Drafting and move the watched app to
+Messages when the recommendation is ready. Debug markdown/json artifacts are
+optional only.
+
+The parent thread is the orchestrator and the filter writer. On the filters
+path, immediately start Message Drafting in the background, then load
+`references/filter-leads.md`, draft production rubrics in the parent, call
+`save_rubrics`, and ask for filter approval. Do not render message review, queue
+cells, or move past Filter Rules until saved filters are approved and
+`messageDraftRecommendation` is ready.
+
+Keep the Message Drafting handoff lean: `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. The branch loads the current brief/context and sample
+rows through Sellable tools before drafting.
 
 When the user chooses filters, immediately call
 `update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
-before branch work so the app is on Filter Rules. After `save_rubrics`, keep
-Filter Rules visible so the user can approve saved criteria. Only after approval should
+so the app is on Filter Rules while Message Drafting runs. After
+`save_rubrics`, keep Filter Rules visible so the user can approve saved
+criteria. Only after approval should
 `update_campaign` move to `apply-icp-rubric` / Filter Leads and show
 `Filters saved + waiting for message approval` until the template is approved.
 Do not queue enrichment/filtering/Generate Message cells until message
 approval. Tell the user Message Drafting is preparing the template in the
 background.
 
-Prospect Filters owns filter drafting and may persist production rubrics with
-`save_rubrics`. The parent must verify that durable save before continuing. Run
-compatibility agent `post-find-leads-message-scout` as Message Drafting when
-allowed. Keep the long message prompt and refs there.
-
-Codex: YOLO counts as permission for these post-import workers. If no
+Codex: YOLO counts as permission for this one post-import worker. If no
 permission, ask once after filter choice. Use generic `gpt-5.5` / `xhigh`
 Message Drafting if needed. Never draft in parent silently.
 
 If the user critiques or edits the template before `approve-message`, route the
 feedback back to Message Drafting with current `messageDraftRecommendation`,
 basis token, campaign/table basis, and latest user text. Do not rewrite copy in
-the parent or call `update_campaign_brief`. Message Drafting must load/use
-`generate-messages` and return a revised `messageDraftRecommendation`; parent
-renders it and asks approval. Message QA and validation before approval also
-belong to Message Drafting; the parent renders its QA receipt, not a fresh
-parent-thread critique. The branch must load the normal validation/QA rules and
-run a QA pass before returning its concise review-ready recommendation.
+the parent or call `update_campaign_brief`. Message Drafting must load the full
+`generate-messages` prompt, all referenced assets, and
+`create-campaign-v2-validation`, then return a revised
+`messageDraftRecommendation`; parent renders it and asks approval. Message QA
+and validation before approval also belong to Message Drafting, but validation
+is an internal gate. Do not render `renderedFallbackSample`, `concerns`, or a
+full `qaReceipt` in the normal happy path.
 
 Load:
 
 ```text
 get_subskill_prompt({ subskillName: "generate-messages" })
+get_subskill_asset(...) for every asset in generate-messages Reference Asset Loading
+get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })
 ```
 
 Do not use any alternate or examples-only message prompt. Do not render message
 review until `messageDraftRecommendation` proves current campaign/table basis
-and shows whether it came from a background branch or an explicitly approved
-inline fallback.
+and shows whether it came from Message Drafting or an explicitly approved inline
+fallback.
 
 ## Hard Gates
 

package/skills/create-campaign-v2/SOUL.md

@@ -276,11 +276,11 @@ gate; tell the customer what happens next instead.
 ## Parallelism + Naming
 
 After the Find Buyers Plan is approved, source selection stays in the parent
-thread for normal create-campaign runs. Do not launch source scouts unless the
-user explicitly asks for a source comparison/debug run. Only try a fallback after
-the current place fails, the user asks for comparison, or the first place is
-borderline. Keep fallback copy plain: people talking on LinkedIn, recent
-LinkedIn titles, broader LinkedIn titles, then company/contact search.
+thread for normal create-campaign runs. The packaged normal path installs only
+Message Drafting as a background agent. Only try a fallback after the current
+place fails, the user asks for comparison, or the first place is borderline.
+Keep fallback copy plain: people talking on LinkedIn, recent LinkedIn titles,
+broader LinkedIn titles, then company/contact search.
 Use a 10% planning floor after conservative cleanup. If LinkedIn engagement falls
 below that floor, move to Sales Nav. If Sales Nav falls below that floor after
 reasonable refinement, move to Prospeo. Prospeo is the terminal fallback; if it
@@ -294,46 +294,48 @@ Do not claim a source scout ran and do not surface install status.
 For prospect setup work, call `get_post_find_leads_scout_registry` after
 the user chooses filters, not before the filter-choice question. After
 `confirm_lead_list` copies source rows and records the first review/process
-sample, ask add-filters vs skip-filters immediately. If the user chooses
-filters, launch both Prospect Filters (`post-find-leads-filter-scout`) and
-Message Drafting (`post-find-leads-message-scout`) from the same campaign/table
-basis. If the user skips filters, launch only Message Drafting and move the
-browser to Messages/message review.
-
-The parent thread is the orchestrator. On the filters path it must wait for
-Prospect Filters first, verify `save_rubrics` succeeded or save the returned
-production-shaped rubrics itself, keep the browser on Filter Rules, and ask for
+sample, ask add-filters vs skip-filters immediately. After the answer, launch
+only Message Drafting (`post-find-leads-message-scout`). If the user chooses
+filters, the parent thread keeps the browser on Filter Rules, loads the filter
+reference, drafts/saves rubrics with MCP tools, and asks for filter approval
+while Message Drafting runs.
+
+The parent thread is the orchestrator and the filter writer. On the filters path
+it must verify `save_rubrics`, keep the browser on Filter Rules, and ask for
 filter approval. Only after saved filters are approved should it move the
 browser to Filter Leads and join/wait for Message Drafting. The join gate is
 saved-filter approval or a resolved skip-filter choice, plus a message
 recommendation grounded in the same campaign/table basis. Enrichment, filtering,
 and Generate Message cells wait for template approval on the Use Template path.
 
-Keep the Message Drafting handoff compact: campaign identity, campaign name,
-selected lead list ID, workflow table ID, 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 loads the current campaign brief,
-campaign/table state, review rows, full generate-messages prompt, and
-validation/QA rules inside its own branch before returning review-ready output.
-
-Only promise background work for Prospect Filters or Message Drafting when it
-actually started. If the host cannot or should not launch those branches, do not
-silently move long filter/message prompts into the parent thread. In Codex, ask
-once for permission to use post-import background agents. If the user declines
-or asks to continue without background agents, say the real sequence:
+Keep the Message Drafting handoff lean: `campaignId`, `workflowTableId`, concise
+brief summary, concise source summary/source-use rule, and 3-5 sample
+workflow-table rows with rowId/name/title/company/signal. Optional campaign
+name, selected lead list ID, and filter choice are okay. Do not paste copied row
+counts, brief hashes, review-batch hashes, full row ID lists, broad row data, or
+local debug artifacts. Message Drafting loads the current campaign
+brief/context, full `generate-messages` prompt, all referenced assets, and
+`create-campaign-v2-validation` inside its own branch before returning
+review-ready output.
+
+Only promise Message Drafting background work when it actually started. If the
+host cannot or should not launch that branch, do not silently move the long
+message prompt into the parent thread. In Codex, ask once for permission to use
+the post-import background agent. If the user declines or asks to continue
+without background agents, say the real sequence:
 
 ```text
 I’ll tighten the filter first, then run message generation from the same sample.
 ```
 
 Do not say `kicking off two workstreams`, `in parallel`, or `background` for
-source work. On the filters path, the only normal background workers are
-Prospect Filters and Message Drafting.
+source or filter work. On the filters path, the only normal background worker is
+Message Drafting.
 
 Call the post-filter message stage `message generation` in chat.
-Message validation/QA is owned by Message Drafting; the parent renders its
-approval proof, not a fresh critique from memory.
+Message validation/QA is owned by Message Drafting; validation is an internal
+gate. The parent renders the template, token rules, one good sample, status, and
+approve/revise recommendation, not fallback samples, concerns, or a QA receipt.
 
 Be explicit about what has and has not happened: