@sellable/mcp 0.1.77 → 0.1.79

package/README.md

@@ -243,6 +243,10 @@ Parallel execution contract:
 - Source scout names come from `agents/registry.json` and are exposed at runtime
   through `get_source_scout_registry`. Add new scouts there first; installer,
   Codex config, Claude agent files, and prompts should consume the registry.
+- Post-find-leads scout names also come from `agents/registry.json` and are
+  exposed through `get_post_find_leads_scout_registry`. After source approval,
+  use that registry to launch the filter-leads scout and message-generation
+  scout together when the host supports real subagents.
 - Claude host: use the installed `source-scout-linkedin-engagement`,
   `source-scout-sales-nav`, and `source-scout-prospeo-contact` Task/Agent subagents
   for parallel lead-source scouting. Launch all credible lanes in one assistant
@@ -252,6 +256,10 @@ Parallel execution contract:
   `source-scout-prospeo-contact`. Use `multi_tool_use.parallel` for independent
   tool-call batches when subagents are unavailable or the work is only simple
   batched lookups.
+- For the post-lead stage, Codex/Claude should launch
+  `post-find-leads-filter-scout` and `post-find-leads-message-scout` in the
+  same turn/message when subagents are available. If not, run them sequentially
+  and do not claim parallel work.
 - If neither backend is available, run sequentially with the same output schema.
 
 Config path resolution (in order):

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

@@ -0,0 +1,67 @@
+You are the Post-Lead Filter Scout for Sellable create-campaign-v2.
+
+Your job starts only after find-leads has produced `lead-review.md` and
+`lead-sample.json`, and the lead source has been approved or auto-confirmed.
+Work only on the lead filter branch. Do not source new leads, draft messages,
+import leads, create campaigns, ask the user questions, or mutate live campaign
+state.
+
+Required inputs:
+
+- `brief.md`
+- `lead-review.md`
+- `lead-sample.json`
+
+Required first steps:
+
+1. Read the three required inputs.
+2. Load the filter-leads reference before writing artifacts:
+   `get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/filter-leads.md" })`.
+
+Owned outputs:
+
+- `lead-filter.md`
+- `rubric.json` when the filter is confirmed and production-shaped rubrics are
+  safe to write
+
+Do not write or modify:
+
+- `message-validation.md`
+- `message-review.md`
+- `approval-packet.md`
+- `brief.md`
+- `lead-review.md`
+- `lead-sample.json`
+
+Process:
+
+1. Preserve the approved source decision and the sample math from
+   `lead-review.md`; do not re-run sourcing.
+2. Turn the sample'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. Write `lead-filter.md` first. If status is `confirmed`, also write
+   `rubric.json` with 2-5 production-shaped `leadScoringRubrics`.
+
+Return a concise final status with:
+
+- filter status: `confirmed`, `confirm-with-user`, or `revise-find-leads`
+- artifacts written
+- 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.

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

@@ -0,0 +1,67 @@
+You are the Post-Lead Message Scout for Sellable create-campaign-v2.
+
+Your job starts only after find-leads has produced `lead-review.md` and
+`lead-sample.json`, and the lead source has been approved or auto-confirmed.
+Work only on the message generation branch. Do not source new leads, create lead
+filters, import leads, create campaigns, ask the user questions, or mutate live
+campaign state.
+
+Required inputs:
+
+- `brief.md`
+- `lead-review.md`
+- `lead-sample.json`
+
+Required first steps:
+
+1. Read the three required inputs.
+2. Load 100% of the real generate-messages prompt with chunked
+   `get_subskill_prompt({ subskillName: "generate-messages", offset, limit })`
+   calls until `hasMore` is false.
+
+Owned outputs:
+
+- `message-validation.md`
+- optional `message-prep.md`
+- optional `message-candidate-drafts.md`
+
+Do not write or modify:
+
+- `lead-filter.md`
+- `rubric.json`
+- `message-review.md`
+- `approval-packet.md`
+- `brief.md`
+- `lead-review.md`
+- `lead-sample.json`
+
+Process:
+
+1. Run the loaded generate-messages workflow in dry mode from the approved
+   brief, lead-review source decision, and `lead-sample.json`.
+2. Use `lead-sample.json` as the only lead sample source. Do not fetch new
+   prospects or invent richer row signals.
+3. Build proof inventory, token fill rules, token adherence, angle drafts,
+   kill/combine review, finalists, skeptical-prospect review, winner gate, and
+   a raw sendable selected winner.
+4. If `lead-filter.md` already exists, cite only basis rows that pass it. If it
+   does not exist yet, choose probable good-fit rows from `lead-sample.json` and
+   mark the final reconciliation as pending.
+5. Write `message-validation.md`. Do not write `message-review.md`; the parent
+   thread owns the joined review after both post-lead scouts finish.
+
+Return a concise final status with:
+
+- artifacts written
+- whether the full generate-messages prompt was loaded
+- lead sample basis used
+- selected winner summary
+- whether final reconciliation with `lead-filter.md` is complete or pending
+
+Quality bar:
+
+- Do not synthesize a lightweight message from general knowledge. The artifact
+  must prove the full generate-messages workflow ran.
+- Message generation can start before `lead-filter.md`, but message review
+  cannot start until the parent verifies the selected basis rows still pass the
+  final filter.

package/agents/registry.json

@@ -4,6 +4,7 @@
     {
       "id": "linkedin-engagement",
       "name": "source-scout-linkedin-engagement",
+      "kind": "source-scout",
       "promptFile": "source-scout-linkedin-engagement.md",
       "displayName": "LinkedIn Engagement Scout",
       "provider": "signal-discovery",
@@ -52,6 +53,7 @@
     {
       "id": "sales-nav",
       "name": "source-scout-sales-nav",
+      "kind": "source-scout",
       "promptFile": "source-scout-sales-nav.md",
       "displayName": "Sales Nav Scout",
       "provider": "sales-nav",
@@ -100,6 +102,7 @@
     {
       "id": "prospeo-contact",
       "name": "source-scout-prospeo-contact",
+      "kind": "source-scout",
       "promptFile": "source-scout-prospeo-contact.md",
       "displayName": "Prospeo Contact Scout",
       "provider": "prospeo",
@@ -145,6 +148,87 @@
           "mcp__sellable__search_prospeo"
         ]
       }
+    },
+    {
+      "id": "filter-leads",
+      "name": "post-find-leads-filter-scout",
+      "kind": "post-find-leads-scout",
+      "promptFile": "post-find-leads-filter-scout.md",
+      "displayName": "Post-Lead Filter Scout",
+      "target": "filter-leads",
+      "inputs": ["brief.md", "lead-review.md", "lead-sample.json"],
+      "producesArtifacts": ["lead-filter.md"],
+      "optionalProducesArtifacts": ["rubric.json"],
+      "ownership": "lead quality, false-positive patterns, keep/exclude rules, ability-to-pay checks, and production rubric translation only",
+      "codex": {
+        "description": "Sellable post-find-leads scout for lead filtering and rubric generation after source approval.",
+        "model": "gpt-5.5",
+        "modelReasoningEffort": "high",
+        "sandboxMode": "workspace-write",
+        "nicknameCandidates": [
+          "Lead Filter Scout",
+          "Filter Scout",
+          "Rubric Scout"
+        ]
+      },
+      "claude": {
+        "description": "Use proactively as a background Sellable post-find-leads scout after lead source approval to produce lead-filter.md and rubric.json from brief.md, lead-review.md, and lead-sample.json.",
+        "model": "inherit",
+        "background": true,
+        "maxTurns": 8,
+        "color": "yellow",
+        "tools": [
+          "Read",
+          "Write",
+          "Edit",
+          "Grep",
+          "Glob",
+          "mcp__sellable__get_subskill_prompt",
+          "mcp__sellable__get_subskill_asset"
+        ]
+      }
+    },
+    {
+      "id": "message-generation",
+      "name": "post-find-leads-message-scout",
+      "kind": "post-find-leads-scout",
+      "promptFile": "post-find-leads-message-scout.md",
+      "displayName": "Post-Lead Message Scout",
+      "target": "generate-messages",
+      "inputs": ["brief.md", "lead-review.md", "lead-sample.json"],
+      "producesArtifacts": ["message-validation.md"],
+      "optionalProducesArtifacts": [
+        "message-prep.md",
+        "message-candidate-drafts.md"
+      ],
+      "ownership": "proof inventory, token strategy, angle drafting, skeptical-prospect review, and selected winner only",
+      "codex": {
+        "description": "Sellable post-find-leads scout for dry-mode message generation after source approval.",
+        "model": "gpt-5.5",
+        "modelReasoningEffort": "high",
+        "sandboxMode": "workspace-write",
+        "nicknameCandidates": [
+          "Message Scout",
+          "Message Generation Scout",
+          "Copy Scout"
+        ]
+      },
+      "claude": {
+        "description": "Use proactively as a background Sellable post-find-leads scout after lead source approval to run dry-mode message generation from brief.md, lead-review.md, and lead-sample.json.",
+        "model": "inherit",
+        "background": true,
+        "maxTurns": 10,
+        "color": "magenta",
+        "tools": [
+          "Read",
+          "Write",
+          "Edit",
+          "Grep",
+          "Glob",
+          "mcp__sellable__get_subskill_prompt",
+          "mcp__sellable__get_subskill_asset"
+        ]
+      }
     }
   ]
 }

package/dist/server.js

@@ -21,7 +21,7 @@ import { fetchCompany, fetchCompanyPosts, fetchLinkedInPosts, fetchLinkedInProfi
 import { getCampaignNavigationState, navigationToolDefinitions, } from "./tools/navigation.js";
 import { addOnDemandLeads, createOnDemandCampaign, createOnDemandTable, initOnDemandSequence, onDemandToolDefinitions, pauseOnDemandCampaign, startOnDemandCampaign, } from "./tools/one-off.js";
 import { processingToolDefinitions, upsertRubric } from "./tools/processing.js";
-import { completeSenderResearch, getMessagePrompt, getSourceScoutRegistry, getSubskillAsset, getSubskillPrompt, listSubskillPrompts, promptToolDefinitions, searchSubskillPrompts, } from "./tools/prompts.js";
+import { completeSenderResearch, getMessagePrompt, getPostFindLeadsScoutRegistry, getSourceScoutRegistry, getSubskillAsset, getSubskillPrompt, listSubskillPrompts, promptToolDefinitions, searchSubskillPrompts, } from "./tools/prompts.js";
 import { readinessToolDefinitions, waitForCampaignTableReady, waitForLeadListReady, } from "./tools/readiness.js";
 import { getRows, getTableRows, getTableRowsMinimal, rowToolDefinitions, } from "./tools/rows.js";
 import { addRubricItem, checkRubric, deleteRubricItem, draftRubrics, rubricToolDefinitions, saveRubrics, selectNecessaryRubrics, updateRubricItem, waitForRubricResults, } from "./tools/rubrics.js";
@@ -411,6 +411,9 @@ server.setRequestHandler(CallToolRequestSchema, async (request) => {
             case "get_source_scout_registry":
                 result = getSourceScoutRegistry();
                 break;
+            case "get_post_find_leads_scout_registry":
+                result = getPostFindLeadsScoutRegistry();
+                break;
             case "complete_sender_research":
                 result = completeSenderResearch(args);
                 break;

package/dist/tools/campaigns.js

@@ -1,6 +1,6 @@
 import { getApi } from "../api.js";
 import { getConfig } from "../auth.js";
-import { assertCreateCampaignPromptLoaded } from "./flow-preflight.js";
+import { assertCreateCampaignPromptLoaded, assertNetNewCreateCampaignResearchReady, } from "./flow-preflight.js";
 import { setCampaignInteractionMode, } from "./interaction-mode.js";
 import { fetchCampaignRubrics } from "./processing.js";
 const LEAD_SOURCE_PROVIDERS = {
@@ -618,9 +618,10 @@ export async function createCampaign(input) {
             `or all create fields. Missing: ${missing.join(", ")}.\n\n` +
             "Remediation:\n" +
             '- For full workflow, call get_subskill_prompt({ subskillName: "create-campaign" }) and follow it.\n' +
-            "- For net-new campaign creation: pass either `clientProspectId` (preferred) or `senderLinkedinUrl` and let the backend resolve sender context at mint time.\n" +
+            "- For net-new campaign creation: run the `research-sender` flow first, call `complete_sender_research`, then pass either `clientProspectId` (preferred) or `senderLinkedinUrl` and let the backend resolve sender context at mint time.\n" +
             "- For resume, call create_campaign with campaignId only.");
     }
+    assertNetNewCreateCampaignResearchReady();
     const name = input.name;
     const clientProspectId = hasClientProspectId
         ? input.clientProspectId?.trim()

package/dist/tools/prompts.d.ts

@@ -96,6 +96,43 @@ export interface SourceScoutRegistryResponse {
         parentThreadRule: string;
     };
 }
+export interface PostFindLeadsScoutRegistryResponse {
+    version: number;
+    trigger: "find_leads_source_approved";
+    requiredArtifacts: string[];
+    scouts: Array<{
+        id: string;
+        name: string;
+        displayName: string;
+        target: string;
+        inputs: string[];
+        producesArtifacts: string[];
+        optionalProducesArtifacts: string[];
+        ownership: string;
+        codex: {
+            filename: string;
+            description: string;
+            model: string;
+            modelReasoningEffort: string;
+        };
+        claude: {
+            filename: string;
+            description: string;
+            tools: string[];
+        };
+    }>;
+    joinGate: {
+        afterAllComplete: boolean;
+        requiredArtifacts: string[];
+        show: string[];
+        nextStage: string;
+    };
+    usage: {
+        codex: string;
+        claude: string;
+        parentThreadRule: string;
+    };
+}
 export declare const DEFAULT_SUBSKILL_PROMPT_CHUNK_CHARS = 48000;
 export declare const MAX_SUBSKILL_PROMPT_CHUNK_CHARS = 48000;
 export declare const promptToolDefinitions: ({
@@ -323,6 +360,7 @@ export declare const promptToolDefinitions: ({
     _meta?: undefined;
 })[];
 export declare function getSourceScoutRegistry(): SourceScoutRegistryResponse;
+export declare function getPostFindLeadsScoutRegistry(): PostFindLeadsScoutRegistryResponse;
 export declare function getMessagePrompt(): Promise<PromptResponse>;
 export declare function listSubskillPrompts(limit?: number, includePublic?: boolean, includeInternal?: boolean): ListSubskillPromptsResponse;
 export declare function getSubskillPrompt(subskillName: string, offset?: number, limit?: number): SubskillPromptResponse;

package/dist/tools/prompts.js

@@ -140,6 +140,16 @@ export const promptToolDefinitions = [
             additionalProperties: false,
         },
     },
+    {
+        name: "get_post_find_leads_scout_registry",
+        description: "Return the canonical Sellable post-find-leads scout names for the two parallel workstreams unlocked after lead source approval: filter-leads and message generation.",
+        inputSchema: {
+            type: "object",
+            properties: {},
+            required: [],
+            additionalProperties: false,
+        },
+    },
     {
         name: "complete_sender_research",
         description: "Mark sender research as completed for create-campaign preflight. Call this after research-sender synthesis and before create_campaign.",
@@ -196,12 +206,22 @@ function resolveAgentsDir() {
     }
     return candidates[0] ?? path.resolve(process.cwd(), "mcp/sellable/agents");
 }
-export function getSourceScoutRegistry() {
+function readAgentRegistry() {
     const registryPath = path.join(resolveAgentsDir(), "registry.json");
     const registry = JSON.parse(fs.readFileSync(registryPath, "utf8"));
-    const agents = Array.isArray(registry.agents) ? registry.agents : [];
     return {
         version: Number(registry.version || 1),
+        agents: Array.isArray(registry.agents) ? registry.agents : [],
+    };
+}
+export function getSourceScoutRegistry() {
+    const registry = readAgentRegistry();
+    const agents = registry.agents.filter((agent) => {
+        const kind = String(agent.kind || "source-scout");
+        return kind === "source-scout";
+    });
+    return {
+        version: registry.version,
         agents: agents.map((agent) => ({
             id: String(agent.id || ""),
             name: String(agent.name || ""),
@@ -228,6 +248,51 @@ export function getSourceScoutRegistry() {
         },
     };
 }
+export function getPostFindLeadsScoutRegistry() {
+    const registry = readAgentRegistry();
+    const scouts = registry.agents.filter((agent) => String(agent.kind || "") === "post-find-leads-scout");
+    return {
+        version: registry.version,
+        trigger: "find_leads_source_approved",
+        requiredArtifacts: ["brief.md", "lead-review.md", "lead-sample.json"],
+        scouts: scouts.map((agent) => ({
+            id: String(agent.id || ""),
+            name: String(agent.name || ""),
+            displayName: String(agent.displayName || agent.name || ""),
+            target: String(agent.target || agent.id || ""),
+            inputs: Array.isArray(agent.inputs) ? agent.inputs.map(String) : [],
+            producesArtifacts: Array.isArray(agent.producesArtifacts)
+                ? agent.producesArtifacts.map(String)
+                : [],
+            optionalProducesArtifacts: Array.isArray(agent.optionalProducesArtifacts)
+                ? agent.optionalProducesArtifacts.map(String)
+                : [],
+            ownership: String(agent.ownership || ""),
+            codex: {
+                filename: String(agent.codex?.filename || `${agent.name}.toml`),
+                description: String(agent.codex?.description || ""),
+                model: String(agent.codex?.model || "gpt-5.5"),
+                modelReasoningEffort: String(agent.codex?.modelReasoningEffort || "high"),
+            },
+            claude: {
+                filename: String(agent.claude?.filename || `${agent.name}.md`),
+                description: String(agent.claude?.description || ""),
+                tools: Array.isArray(agent.claude?.tools) ? agent.claude.tools : [],
+            },
+        })),
+        joinGate: {
+            afterAllComplete: true,
+            requiredArtifacts: ["lead-filter.md", "message-validation.md"],
+            show: ["lead_filter_summary", "sample_message"],
+            nextStage: "message-review",
+        },
+        usage: {
+            codex: "After the user approves or auto-confirms the lead source, spawn both returned scout `name` values in one assistant turn when subagents are available.",
+            claude: "After lead source approval, invoke both returned Task/Agent subagents in one assistant message so filter-leads and message generation run concurrently.",
+            parentThreadRule: "Do not run filter-leads to completion before starting message generation. Both scouts consume brief.md, lead-review.md, and lead-sample.json; join before message review.",
+        },
+    };
+}
 export async function getMessagePrompt() {
     const api = getApi();
     return api.get("/api/v3/prompts/edit-message");

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -12,6 +12,7 @@ allowed-tools:
   - mcp__sellable__search_subskill_prompts
   - mcp__sellable__get_provider_prompt
   - mcp__sellable__get_source_scout_registry
+  - mcp__sellable__get_post_find_leads_scout_registry
   - mcp__sellable__get_message_prompt
   - mcp__sellable__get_active_workspace
   - mcp__sellable__list_senders
@@ -114,6 +115,13 @@ copy, is the runtime source of truth. If the host runs them sequentially, do not
 claim they ran in parallel. In chat, call the downstream copy stage `message generation`;
 `message-validation.md` is only an internal proof artifact.
 
+After find-leads returns a lead source and the user approves it, use the same
+registry pattern for the two post-lead branches. The create-campaign-v2 subskill
+calls `get_post_find_leads_scout_registry`, then launches the returned
+filter-leads scout and message-generation scout together when real subagents are
+available. Message generation must not wait for the filter unless the host
+cannot run the two branches concurrently.
+
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
 sourcing terms into plain language.
@@ -190,14 +198,22 @@ Treat host capabilities as concrete functions, not prose conventions:
   and continue chunks until `hasMore` is false.
 - `load_source_scout_registry`: call
   `mcp__sellable__get_source_scout_registry({})` before any scout dispatch.
+- `load_post_find_leads_scout_registry`: call
+  `mcp__sellable__get_post_find_leads_scout_registry({})` after source
+  approval and before dispatching the post-lead filter/message scouts.
 - `launch_source_scout`: Claude Code uses `Task` with `subagent_type` equal to
   the registry `name`; Codex uses named custom agents such as
   `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
   `source-scout-prospeo-contact` when subagents are available.
+- `launch_post_find_leads_scout`: Claude Code uses `Task` with `subagent_type`
+  equal to the returned post-lead registry `name`; Codex uses the returned
+  custom agents such as `post-find-leads-filter-scout` and
+  `post-find-leads-message-scout` when subagents are available.
 
 If a required interactive host function is missing, stop and explain the
 Sellable install/reload problem. Do not silently simulate structured choices,
-subprompt loading, or source-scout dispatch with local scripts.
+subprompt loading, source-scout dispatch, or post-lead scout dispatch with local
+scripts.
 
 Never narrate local draft housekeeping to the user. If you create directories,
 save drafts, write artifacts, or persist intermediate state, translate it into

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

@@ -460,10 +460,12 @@ should test for this campaign. Those can run in parallel and usually take
   `post-lead-workstreams` step. Launch `filter leads` and `message generation`
   from the same basis (`brief.md`, `lead-review.md`, `lead-sample.json`) as
   separate workstreams when the host supports real subagents/background work.
-  In Claude Code, use two Task/Agent subagents in the same assistant message;
-  in Codex, use disjoint worker subagents when the host exposes them. The
-  existing `filter-rubric` and `message-generation` steps remain focused retry
-  and resume targets.
+  First call `get_post_find_leads_scout_registry` and use the returned
+  canonical `name` values. In Claude Code, use both returned Task/Agent
+  subagents in the same assistant message; in Codex, use both returned custom
+  scouts as disjoint subagents in the same assistant turn when the host exposes
+  them. The existing `filter-rubric` and `message-generation` steps remain
+  focused retry and resume targets.
 - Message generation does not need `lead-filter.md` to start. The moment
   `lead-sample.json` exists with at least 5 probable good-fit rows and the lead
   source is confirmed or auto-confirmed, start the message-generation
@@ -499,6 +501,13 @@ should test for this campaign. Those can run in parallel and usually take
 then draft the message from the same sample.` Never say `kicking off two
 workstreams`, `in parallel`, or `background` unless parallel branches were
   actually launched.
+- For post-lead workstreams, first call
+  `get_post_find_leads_scout_registry` and launch exactly the returned
+  `filter-leads` and `message-generation` scouts when real subagents are
+  available. This is the same registry pattern as source scouting, but the
+  trigger is source approval and the join gate is both `lead-filter.md` and
+  `message-validation.md` existing from the same `brief.md`, `lead-review.md`,
+  and `lead-sample.json`.
 - Never run a downstream stage until the active `flow.v2.json` step's
   `requiredArtifacts` exist.
 - Never call a tool outside the active step's `allowedTools`, and never call a
@@ -926,6 +935,9 @@ Required behavior:
   economic capacity, competitor/vendor exclusion, and active current-role status
   as table-stakes buyer-quality gates; include geography/market whenever budget,
   channel adoption, language, compliance, or delivery assumptions depend on it
+- customize the concrete thresholds for those gates to the client's offer,
+  market, price point, delivery model, and competitor landscape; the invariant
+  is that every passing lead should be worth the user's time if they reply
 - do not turn "shown interest", post engagement, Signals source, recent posting,
   provider source, or first-send priority into a production filter; those are
   discovery or messaging context, not proof the lead is qualified

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

@@ -243,6 +243,14 @@ background source scouts` so the next turn has a user-visible request to spawn
 scouts. If the host runs them sequentially, keep the output numeric but do not
 claim the source scout was parallel.
 
+For post-lead work, call `get_post_find_leads_scout_registry` after source
+approval and use the returned canonical `name` values. Launch both returned
+scouts in the same assistant turn/message when real subagents are available:
+`post-find-leads-filter-scout` and `post-find-leads-message-scout`. This is the
+same registry pattern as source scouting, but the trigger is approved
+find-leads output and the join gate is both `lead-filter.md` and
+`message-validation.md`.
+
 Only promise parallel post-lead work when parallel work actually started. If the
 host cannot or should not launch background branches, say the real sequence:
 

package/skills/create-campaign-v2/core/flow.v2.json

@@ -560,9 +560,15 @@
       "label": "Post-lead filter and message workstreams",
       "normalFlow": true,
       "onEnter": [
+        {
+          "tool": "get_post_find_leads_scout_registry",
+          "requiredValues": {},
+          "purpose": "Load the canonical two-scout registry before dispatch so Codex and Claude use the same post-find-leads agent names."
+        },
         {
           "action": "launch_post_lead_workstreams",
           "mode": "parallel_when_host_supports_subagents",
+          "registryRequired": "get_post_find_leads_scout_registry",
           "branches": [
             {
               "name": "filter-leads",
@@ -587,8 +593,8 @@
           ],
           "earlyMessageStartRule": "As soon as lead-sample.json exists with at least 5 probable good-fit rows and the lead source is confirmed or auto-confirmed, launch message-generation from brief.md, lead-review.md, and lead-sample.json. Do not wait for lead-filter.md to begin proof inventory, token planning, or candidate angles.",
           "finalMessageReconcileRule": "message-validation.md may start before lead-filter.md exists, but before message-review it must cite only lead-sample.json rows that still pass lead-filter.md. If the selected winner depends on a row later excluded by lead-filter.md, revise message-generation before message review.",
-          "claudeRule": "In Claude Code, launch both workstreams with Task/Agent subagents in the same assistant message when Task is available. Do not run filter first and then message generation unless subagents/background work are unavailable.",
-          "codexRule": "In Codex, launch disjoint worker subagents for filter-leads and message-generation when the host exposes subagents for this run. If the host cannot spawn them, run the same branches sequentially and say so.",
+          "claudeRule": "In Claude Code, launch both returned post-find-leads scouts with Task/Agent subagents in the same assistant message when Task is available. Do not run filter first and then message generation unless subagents/background work are unavailable.",
+          "codexRule": "In Codex, launch both returned post-find-leads scout names as disjoint subagents in the same assistant turn when the host exposes subagents for this run. If the host cannot spawn them, run the same branches sequentially and say so.",
           "fallback": "If real parallel branches are unavailable, run filter-leads and then message-generation in the parent thread. Do not claim background or parallel work in that fallback."
         },
         {
@@ -612,6 +618,7 @@
       "allowedTools": [
         "get_subskill_prompt",
         "get_subskill_asset",
+        "get_post_find_leads_scout_registry",
         "Task",
         "spawn_agent",
         "AskUserQuestion",

package/skills/create-campaign-v2/references/filter-leads.md

@@ -5,10 +5,16 @@ fidelity to the find-leads estimate, not re-run sourcing or produce a large
 scoring framework.
 
 The business goal is not "find people who might reply." It is "every reply the
-user gets should come from someone who is in the ICP and has a realistic path
-to buying." A lead who may reply but cannot buy, lacks budget, sits at the wrong
-account type, is a vendor/competitor, or is on the wrong side of a marketplace
-is not a good lead.
+user gets should come from someone they would be excited to hear back from:
+inside the ICP, able to act, and with a realistic path to buying." A lead who may
+reply but cannot buy, lacks budget, sits at the wrong account type, is a
+vendor/competitor, or is on the wrong side of a marketplace is not a good lead.
+
+The exact qualification gates are client- and offer-specific, but the standard
+does not change: anyone we reach out to, and anyone who replies, should be worth
+the user's time to talk to. Use the client's price point, buyer, channel,
+delivery constraints, market, and competitor landscape to define the concrete
+gates for that campaign.
 
 Source interest is not qualification. A lead who engaged with a post, appeared
 in a Signals search, recently posted on LinkedIn, or "showed interest" in the
@@ -18,6 +24,34 @@ become a production filter or `leadScoringRubric` item. If the source lane was
 built from topical engagement, the filter should still ask: is this the right
 role, seniority, account type, budget band, market, and non-competitor?
 
+Ability to pay must be considered for every campaign, but it is only a required
+filter/rubric when the client, offer, or price point makes affordability a real
+qualification risk. Do not force an enterprise-budget screen onto a low-cost B2C,
+creator, prosumer, or small-team offer. Do not use a loose consumer-style screen
+for an enterprise, services-heavy, implementation-heavy, or paid-pilot offer.
+When affordability is material, `lead-filter.md` must name the campaign-native
+proxy that proves the prospect can afford this specific offer at this specific
+price point. Do not dodge this gate because the exact budget is unknown; use a
+reasonable public proxy such as funding, headcount, revenue band, team maturity,
+current tool spend, practice size, location count, consumer purchasing power,
+job-to-be-done intensity, or buyer budget ownership. If affordability is material
+and no reliable proxy exists in the sample or through normal enrichment, set
+`Status: confirm-with-user` and ask for the budget proxy before moving to message
+generation.
+
+Use price-point proportionality:
+
+- inexpensive B2C / prosumer / creator offers: do not require an explicit
+  ability-to-pay rule unless affordability is central to the ICP; fit is usually
+  based on use case, audience, life context, or intent, not company budget
+- a few-hundred-dollar SMB or self-serve B2B offer: require evidence of an
+  active business, relevant workflow, and enough commercial seriousness to pay
+  hundreds, but do not require enterprise scale
+- mid-market / paid pilot / agency or implementation-supported offer: require a
+  team, operational pain, and a likely owner for the budget
+- enterprise / high-ACV offer: require enterprise or upper-mid-market account
+  fit, budget-owning seniority, department maturity, and buying-process plausibility
+
 Inputs:
 
 - `brief.md`
@@ -66,8 +100,8 @@ Use the actual sample to answer:
 - which repeated false positives must become explicit exclusions
 - whether filters are enough, or whether the source lane would make the
   campaign miss if launched as-is
-- whether the filtered leads are economically worth sending to, using the best
-  campaign-native proxy available from row data, enrichment, or Googleable facts
+- whether the filtered leads are worth sending to for this client's offer and
+  price point, using an economic-fit proxy only when affordability is material
 
 ## Table-Stakes Qualification Gates
 
@@ -75,6 +109,14 @@ Confirmed production filters should fail closed on buyer quality. The default
 confirmed filter set must explicitly include each table-stakes gate below, or
 `lead-filter.md` must state why a gate is irrelevant for this campaign:
 
+Customize the concrete threshold for each gate to the client and offer. For
+example, "can afford this" might mean nothing explicit for a low-cost B2C tool,
+an active business for a few-hundred-dollar SMB offer, enterprise headcount for
+one client, a funded seed-stage team for another, multi-location practice size
+for another, or existing tool spend for another. Do not hard-code Sellable's
+exact budget, geography, or title rules into unrelated campaigns; hard-code the
+principle that passing leads must be worth the customer's time.
+
 - right role / function: the person owns or directly influences the buyer
   problem; wrong-function leads fail even when they match the source topic
 - right seniority / authority: the person can approve, pilot, champion, or
@@ -83,9 +125,10 @@ confirmed filter set must explicitly include each table-stakes gate below, or
 - account and channel fit: the company is the right account type and its buyers
   are reachable through the chosen channel, such as LinkedIn for LinkedIn
   outbound campaigns
-- economic capacity / ability to buy: the company has an appropriate budget
-  proxy for the offer, such as headcount, revenue, funding, team size, practice
-  size, location count, department maturity, or existing tooling
+- economic capacity / ability to buy, when material: the prospect has an
+  appropriate price-point proxy for the offer, such as active business status,
+  headcount, revenue, funding, team size, practice size, location count,
+  department maturity, existing tooling, or budget ownership
 - competitor / vendor / wrong-side exclusion: competitors, adjacent vendors,
   agencies/service providers, resellers, and marketplace-side conflicts fail
   unless the brief explicitly targets that group
@@ -140,11 +183,15 @@ Status: confirmed | confirm-with-user | revise-find-leads
 
 ## Who We'll Keep
 
-- ...
+- buyers we would be excited to get a reply from, including the role, authority,
+  account type, and price-point-appropriate commercial-fit signal that make the
+  reply worth taking
 
 ## Who We'll Exclude
 
-- ...
+- people who may reply but are not worth sending to because they lack authority,
+  lack a plausible budget path when budget is material, sit at the wrong account
+  type, or are competitors/vendors/wrong-side marketplace participants
 
 ## Sample False Positives
 
@@ -165,7 +212,9 @@ Status: confirmed | confirm-with-user | revise-find-leads
 
 ## Implementation Details
 
-If `Status: confirmed`, include production rubrics:
+If `Status: confirmed`, include production rubrics. The `economic_capacity`
+example below applies when affordability is material; omit it for inexpensive
+B2C/prosumer/community offers where ability to pay is not a meaningful fit gate:
 
 ```json
 {
@@ -187,6 +236,15 @@ If `Status: confirmed`, include production rubrics:
       "isRequiredCheck": true,
       "allowPartialCredit": false,
       "strictMatching": false
+    },
+    {
+      "checkName": "economic_capacity",
+      "description": "Prospect has a price-point-appropriate ability-to-pay proxy.",
+      "criterion": "Yes if public or enriched data shows the prospect is likely able to afford this specific offer using the campaign's chosen proxy, scaled to the price point. For low-cost B2C/prosumer offers, this may be personal fit and purchasing power. For a few-hundred-dollar SMB/self-serve offer, this may be an active business and relevant workflow. For paid-pilot, implementation-heavy, mid-market, or enterprise offers, this may require funding, revenue, headcount, department maturity, existing tool spend, location count, or budget-owner title. No if the prospect is structurally unable to buy at the offer's price point or missing the required proxy after enrichment.",
+      "reason": "Replies from accounts without a realistic budget path waste the user's time even when the person is warm or interested.",
+      "isRequiredCheck": true,
+      "allowPartialCredit": false,
+      "strictMatching": false
     }
   ]
 }
@@ -230,6 +288,15 @@ Rules:
   inputs
 - `leadScoringRubrics` must contain 2-5 production-shaped rubric items, not one
   item per bullet
+- confirmed `leadScoringRubrics` must include an explicit ability-to-pay /
+  economic-capacity check when affordability is material to fit: a few-hundred-
+  dollar B2B offer, paid pilot, implementation-heavy sale, mid-market sale, or
+  enterprise/high-ACV motion. Do not require this check for inexpensive B2C,
+  prosumer, creator, community, or otherwise low-friction offers unless
+  affordability is central to the ICP. When present, the check must be
+  price-point-appropriate for the client and offer: commercial-seriousness based
+  for a few hundred dollars, budget-owner based for mid-market/enterprise. Do not
+  rely on role fit, company fit, or source engagement to imply this.
 - do not put source-path mechanics or send-priority hints into
   `leadScoringRubrics`. Examples: recently posted on LinkedIn, came from a
   Signals search, appeared in Sales Nav, was found by Prospeo, first-send wave,
@@ -249,9 +316,10 @@ Rules:
   - right role / function fit
   - buyer seniority / authority
   - account or company-type fit
-  - economic capacity / ability to buy, using a campaign-native proxy such as
-    headcount, revenue, funding, practice size, location count, patient volume,
-    department maturity, existing tooling, or budget-owner title
+  - economic capacity / ability to buy, when material, using a campaign-native
+    proxy such as active business status, headcount, revenue, funding, practice
+    size, location count, patient volume, department maturity, existing tooling,
+    or budget-owner title
   - geography / market, when relevant
   - active-current-role safety
   - hard exclusions for competitors, vendors, agencies, job seekers,
@@ -275,6 +343,7 @@ When relevant to the brief and sample, preserve these recurring families:
 - buyer role / seniority
 - wrong-function exclusions
 - company-type exclusions
+- economic capacity / ability-to-pay proxy
 - competitor / vendor / intermediary exclusions
 - geography
 - company size
@@ -327,6 +396,9 @@ Rules:
   `reason`, `isRequiredCheck`, `allowPartialCredit`, and `strictMatching`
 - prefer 2-5 rubric criteria total; do not map every keep/exclude bullet into
   its own scoring row
+- include an explicit ability-to-pay criterion when affordability is material to
+  fit. It may be bundled with company size/stage only when the `checkName`,
+  `description`, and `criterion` still name the budget proxy directly.
 - production rubric criteria should be buyer-quality gates, not execution
   metadata. Do not create rubric rows for provider source, recently-posted
   priority, first-send ordering, or other search mechanics unless the user
@@ -350,7 +422,7 @@ Recommended rubric grouping:
 
 - buyer authority / role fit
 - company / industry / provider-lane fit
-- economic capacity / ability to buy
+- economic capacity / ability to buy, when material
 - geography / size / stage fit, when relevant
 - competitor / vendor / wrong-side / repeated false-positive exclusion
 - one optional buyer-quality qualifier, at most, only when it changes fit scoring

package/skills/research/config.json

@@ -0,0 +1,9 @@
+{
+  "parallelMode": "wide",
+  "agentCount": 6,
+  "maxToolCallsPerAgent": 2,
+  "senderMaxAgents": 2,
+  "senderMaxToolCallsPerAgent": 3,
+  "progressMode": true,
+  "debugMode": true
+}