@sellable/mcp 0.1.68 → 0.1.70

package/README.md

@@ -240,10 +240,16 @@ Provider preflight contract:
 
 Parallel execution contract:
 
-- Claude host: use `Task` subagents for parallel research/crafting units.
+- 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.
+- 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
+  message so Claude Code can run them concurrently/background.
 - Codex host: use named custom scouts for source-angle work when subagents are
-  available: `linkedin_engagement_scout`, `sales_nav_scout`, and
-  `prospeo_contact_scout`. Use `multi_tool_use.parallel` for independent
+  available: `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
+  `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.
 - If neither backend is available, run sequentially with the same output schema.

package/agents/registry.json

@@ -0,0 +1,147 @@
+{
+  "version": 1,
+  "agents": [
+    {
+      "id": "linkedin-engagement",
+      "name": "source-scout-linkedin-engagement",
+      "promptFile": "source-scout-linkedin-engagement.md",
+      "displayName": "LinkedIn Engagement Scout",
+      "provider": "signal-discovery",
+      "lane": "linkedin-engagement",
+      "legacy": {
+        "codex": [
+          {
+            "name": "linkedin_engagement_scout",
+            "filename": "linkedin-engagement-scout.toml"
+          }
+        ],
+        "claude": [
+          {
+            "name": "lead-explorer-signals",
+            "filename": "lead-explorer-signals.md"
+          }
+        ]
+      },
+      "codex": {
+        "description": "Sellable lead-source scout for LinkedIn post engagement and active conversation signals.",
+        "modelReasoningEffort": "medium",
+        "sandboxMode": "read-only",
+        "nicknameCandidates": [
+          "LinkedIn Engagement Scout",
+          "Post Scout",
+          "Engager Scout"
+        ]
+      },
+      "claude": {
+        "description": "Use proactively as a background Sellable source scout when find-leads or create-campaign needs LinkedIn post engagement, Signals, or active conversation evidence.",
+        "model": "inherit",
+        "background": true,
+        "maxTurns": 8,
+        "color": "blue",
+        "tools": [
+          "Read",
+          "Grep",
+          "Glob",
+          "mcp__sellable__get_provider_prompt",
+          "mcp__sellable__search_signals",
+          "mcp__sellable__fetch_post_engagers"
+        ]
+      }
+    },
+    {
+      "id": "sales-nav",
+      "name": "source-scout-sales-nav",
+      "promptFile": "source-scout-sales-nav.md",
+      "displayName": "Sales Nav Scout",
+      "provider": "sales-nav",
+      "lane": "sales-nav",
+      "legacy": {
+        "codex": [
+          {
+            "name": "sales_nav_scout",
+            "filename": "sales-nav-scout.toml"
+          }
+        ],
+        "claude": [
+          {
+            "name": "lead-explorer-sales-nav",
+            "filename": "lead-explorer-sales-nav.md"
+          }
+        ]
+      },
+      "codex": {
+        "description": "Sellable lead-source scout for Sales Navigator role, company, and activity filters.",
+        "modelReasoningEffort": "medium",
+        "sandboxMode": "read-only",
+        "nicknameCandidates": [
+          "Sales Nav Scout",
+          "Role Filter Scout",
+          "Activity Scout"
+        ]
+      },
+      "claude": {
+        "description": "Use proactively as a background Sellable source scout when find-leads or create-campaign needs Sales Navigator title, company, geography, or activity-filter evidence.",
+        "model": "inherit",
+        "background": true,
+        "maxTurns": 8,
+        "color": "cyan",
+        "tools": [
+          "Read",
+          "Grep",
+          "Glob",
+          "mcp__sellable__get_provider_prompt",
+          "mcp__sellable__lookup_sales_nav_filter",
+          "mcp__sellable__search_sales_nav"
+        ]
+      }
+    },
+    {
+      "id": "prospeo-contact",
+      "name": "source-scout-prospeo-contact",
+      "promptFile": "source-scout-prospeo-contact.md",
+      "displayName": "Prospeo Contact Scout",
+      "provider": "prospeo",
+      "lane": "prospeo-contact",
+      "legacy": {
+        "codex": [
+          {
+            "name": "prospeo_contact_scout",
+            "filename": "prospeo-contact-scout.toml"
+          }
+        ],
+        "claude": [
+          {
+            "name": "lead-explorer-prospeo",
+            "filename": "lead-explorer-prospeo.md"
+          }
+        ]
+      },
+      "codex": {
+        "description": "Sellable lead-source scout for Prospeo account/domain and broad contact expansion.",
+        "modelReasoningEffort": "medium",
+        "sandboxMode": "read-only",
+        "nicknameCandidates": [
+          "Prospeo Contact Scout",
+          "Domain Scout",
+          "Contact Scout"
+        ]
+      },
+      "claude": {
+        "description": "Use proactively as a background Sellable source scout when find-leads or create-campaign needs Prospeo account, domain-list, CSV-domain, or verified-contact evidence.",
+        "model": "inherit",
+        "background": true,
+        "maxTurns": 8,
+        "color": "green",
+        "tools": [
+          "Read",
+          "Grep",
+          "Glob",
+          "mcp__sellable__get_provider_prompt",
+          "mcp__sellable__load_csv_domains",
+          "mcp__sellable__save_domain_filters",
+          "mcp__sellable__search_prospeo"
+        ]
+      }
+    }
+  ]
+}

package/agents/source-scout-linkedin-engagement.md

@@ -0,0 +1,41 @@
+You are the LinkedIn Engagement Scout for Sellable find-leads.
+
+Your job is to test whether active LinkedIn posts and engagers can produce a warm first-send list for the campaign. Work only on this source lane. Do not import leads, create campaigns, write campaign artifacts, draft messages, ask the user questions, or make the final source decision.
+
+Required first step:
+
+- Load the canonical provider prompt before searching: `get_provider_prompt({ provider: "signal-discovery", confirmed: true })`.
+
+Use the inherited Sellable MCP tools when available:
+
+- `search_signals` to find recent post lanes.
+- `fetch_post_engagers` to sample engagers from selected posts.
+
+Process:
+
+1. Read the campaign brief, kickoff doc, or lane prompt supplied by the parent.
+2. Search 3-5 keyword/topic lanes, favoring fresh posts from the last 7-14 days.
+3. Select 3-5 promising posts when available.
+4. Fetch or sample engagers for selected posts and score rough ICP fit from visible headline/display-name cues only. Do not enrich people during viability estimation.
+5. Estimate usable prospects per selected post from sampled pass rate. If the sample is good but volume is low, say how many more similar posts should be added or scraped.
+6. Return false positives and dead ends explicitly.
+
+Return a concise structured result with:
+
+- `source_lane`
+- `provider_prompt_loaded`
+- `keyword_lanes` with timeframe, raw posts found, finalist posts reviewed
+- `selected_posts` with URL/title, author/topic, age, engager count, sampled engagers, good fits as n/N, estimated usable prospects per post, use/discard
+- `sample_leads`, if any
+- `estimated_good_fit_range`
+- `expected_reply_rate_range`, directional if inferred
+- `false_positive_patterns`
+- `recommendation`
+- `confidence`
+
+Evidence standards:
+
+- Do not trust raw post volume without inspecting finalist post quality.
+- Prefer sample-based pass rates over intuition.
+- If `fetch_post_engagers` is unavailable or fails, report that explicitly and mark the estimate lower-confidence.
+- Keep LinkedIn Engagement viable when selected posts can produce roughly 150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable.

package/agents/source-scout-prospeo-contact.md

@@ -0,0 +1,43 @@
+You are the Prospeo Contact Scout for Sellable find-leads.
+
+Your job is to test whether Prospeo can produce verified-contact scale for the campaign through account/domain targeting or broad persona expansion. Work only on this source lane. Do not import leads, create campaigns, write campaign artifacts, draft messages, ask the user questions, or make the final source decision.
+
+Required first step:
+
+- Load the canonical provider prompt before searching: `get_provider_prompt({ provider: "prospeo", confirmed: true })`.
+
+Use the inherited Sellable MCP tools when available:
+
+- `load_csv_domains` when the parent supplies a CSV on disk and no `domainFilterId` exists.
+- `save_domain_filters` when the parent supplies pasted/raw include or exclude domains and no `domainFilterId` exists.
+- `search_prospeo` for campaignless people previews.
+
+Process:
+
+1. Read the campaign brief, source intake, kickoff doc, or lane prompt supplied by the parent.
+2. Identify whether this is domain/account targeting or broad persona expansion.
+3. For domain targeting, use or create the standalone `domainFilterId` before searching; never pass raw domains directly into `search_prospeo`.
+4. Run the narrowest useful Prospeo people preview and 1-2 refinements if quality or scale is unclear.
+5. Call out that Prospeo gives contact/account coverage but usually weaker LinkedIn intent than LinkedIn Engagement or Sales Nav activity slices.
+
+Return a concise structured result with:
+
+- `source_lane`
+- `provider_prompt_loaded`
+- `mode`
+- `domain_filter_or_account_inputs`
+- `exact_search_recipe`
+- `raw_result_count`
+- `sampled_people` and good fits as n/N
+- `estimated_good_fit_range_after_cleanup`
+- `expected_reply_rate_range`, directional if inferred
+- `sample_leads`
+- `false_positive_patterns`
+- `recommendation`
+- `confidence`
+
+Evidence standards:
+
+- Never pass raw domains, company website arrays, or company-name arrays into `search_prospeo`.
+- If the user supplied company names rather than domains, report that domain resolution is required before this lane can run safely.
+- Treat Prospeo as an account/contact coverage lane, not as proof of fresh LinkedIn intent.

package/agents/source-scout-sales-nav.md

@@ -0,0 +1,44 @@
+You are the Sales Nav Scout for Sellable find-leads.
+
+Your job is to test whether Sales Navigator filters can produce a scalable, high-fit lead pool for the campaign. Work only on this source lane. Do not import leads, create campaigns, write campaign artifacts, draft messages, ask the user questions, or make the final source decision.
+
+Required first step:
+
+- Load the canonical provider prompt before searching: `get_provider_prompt({ provider: "sales-nav", confirmed: true })`.
+
+Use the inherited Sellable MCP tools when available:
+
+- `lookup_sales_nav_filter` before any dynamic Sales Nav filter.
+- `search_sales_nav` for campaignless preview searches.
+
+Process:
+
+1. Read the campaign brief, kickoff doc, or lane prompt supplied by the parent.
+2. Preserve target role names with `CURRENT_TITLE` lookups; do not rely on seniority alone when the brief names concrete roles.
+3. When `lookup_sales_nav_filter` returns multiple title options, choose the closest semantic title match instead of the first result.
+4. Build a broad-but-reasonable baseline from role/title, geography, company size, industry/account context, and recent LinkedIn activity when relevant.
+5. Run the baseline plus 1-2 refinements if the first pass is noisy or under-scaled.
+6. Verify filters actually applied: returned search URL contains filters, first-page rows match the intended lane, and result count does not look like an unfiltered pool.
+
+Return a concise structured result with:
+
+- `source_lane`
+- `provider_prompt_loaded`
+- `exact_filter_recipe`
+- `lookup_ids_used`
+- `raw_result_count`
+- `sampled_people` and good fits as n/N
+- `estimated_good_fit_range_after_cleanup`
+- `expected_acceptance_rate_range`, directional if inferred
+- `expected_reply_rate_range`, directional if inferred
+- `sample_leads`
+- `false_positive_patterns`
+- `recommendation`
+- `confidence`
+
+Evidence standards:
+
+- Optimize for a useful prospect pool, not max volume at any cost.
+- Bias toward `POSTED_ON_LINKEDIN` for reply-likelihood when the pool still has enough scale.
+- Do not hand-wave missing filter IDs.
+- If Sales Nav returns a giant unfiltered pool, discard that result and retry with valid filters before recommending it.

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, getSubskillAsset, getSubskillPrompt, listSubskillPrompts, promptToolDefinitions, searchSubskillPrompts, } from "./tools/prompts.js";
+import { completeSenderResearch, getMessagePrompt, 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";
@@ -408,6 +408,9 @@ server.setRequestHandler(CallToolRequestSchema, async (request) => {
             case "search_subskill_prompts":
                 result = searchSubskillPrompts(args?.query, args?.limit, args?.includePublic, args?.includeInternal);
                 break;
+            case "get_source_scout_registry":
+                result = getSourceScoutRegistry();
+                break;
             case "complete_sender_research":
                 result = completeSenderResearch(args);
                 break;

package/dist/tools/prompts.d.ts

@@ -60,6 +60,40 @@ export interface CompleteSenderResearchInput {
     credibilitySignalsFound?: number;
     notes?: string;
 }
+export interface SourceScoutRegistryResponse {
+    version: number;
+    agents: Array<{
+        id: string;
+        name: string;
+        displayName: string;
+        provider: string;
+        lane: string;
+        codex: {
+            filename: string;
+            description: string;
+        };
+        claude: {
+            filename: string;
+            description: string;
+            tools: string[];
+        };
+        legacy?: {
+            codex?: Array<{
+                name: string;
+                filename: string;
+            }>;
+            claude?: Array<{
+                name: string;
+                filename: 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: ({
@@ -223,6 +257,29 @@ export declare const promptToolDefinitions: ({
         additionalProperties: boolean;
     };
     _meta?: undefined;
+} | {
+    name: string;
+    description: string;
+    inputSchema: {
+        type: string;
+        properties: {
+            limit?: undefined;
+            includePublic?: undefined;
+            includeInternal?: undefined;
+            subskillName?: undefined;
+            offset?: undefined;
+            assetPath?: undefined;
+            query?: undefined;
+            depth?: undefined;
+            proofItemsFound?: undefined;
+            caseStudyItemsFound?: undefined;
+            credibilitySignalsFound?: undefined;
+            notes?: undefined;
+        };
+        required: never[];
+        additionalProperties: boolean;
+    };
+    _meta?: undefined;
 } | {
     name: string;
     description: string;
@@ -263,6 +320,7 @@ export declare const promptToolDefinitions: ({
     };
     _meta?: undefined;
 })[];
+export declare function getSourceScoutRegistry(): SourceScoutRegistryResponse;
 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

@@ -130,6 +130,16 @@ export const promptToolDefinitions = [
             additionalProperties: false,
         },
     },
+    {
+        name: "get_source_scout_registry",
+        description: "Return the canonical Sellable source-scout agent names and host filenames. Use this before lead-source scouting so Codex and Claude launch the same named scouts from one registry.",
+        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.",
@@ -162,6 +172,60 @@ export const promptToolDefinitions = [
         },
     },
 ];
+function resolveAgentsDir() {
+    const candidates = [];
+    if (process.env.SELLABLE_AGENTS_DIR) {
+        candidates.push(path.resolve(process.env.SELLABLE_AGENTS_DIR));
+    }
+    if (process.argv[1]) {
+        candidates.push(path.resolve(path.dirname(process.argv[1]), "../agents"));
+        try {
+            const realEntryPath = fs.realpathSync(process.argv[1]);
+            candidates.push(path.resolve(path.dirname(realEntryPath), "../agents"));
+        }
+        catch {
+            // Module-relative and cwd fallbacks remain.
+        }
+    }
+    candidates.push(path.resolve(process.cwd(), "mcp/sellable/agents"));
+    candidates.push(path.resolve(process.cwd(), "agents"));
+    for (const candidate of candidates) {
+        if (fs.existsSync(path.join(candidate, "registry.json"))) {
+            return candidate;
+        }
+    }
+    return candidates[0] ?? path.resolve(process.cwd(), "mcp/sellable/agents");
+}
+export function getSourceScoutRegistry() {
+    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: agents.map((agent) => ({
+            id: String(agent.id || ""),
+            name: String(agent.name || ""),
+            displayName: String(agent.displayName || agent.name || ""),
+            provider: String(agent.provider || ""),
+            lane: String(agent.lane || agent.id || ""),
+            codex: {
+                filename: String(agent.codex?.filename || `${agent.name}.toml`),
+                description: String(agent.codex?.description || ""),
+            },
+            claude: {
+                filename: String(agent.claude?.filename || `${agent.name}.md`),
+                description: String(agent.claude?.description || ""),
+                tools: Array.isArray(agent.claude?.tools) ? agent.claude.tools : [],
+            },
+            legacy: agent.legacy,
+        })),
+        usage: {
+            codex: "Spawn credible scouts by the returned `name` values in one assistant turn when the user approved background source scouts.",
+            claude: "Invoke Claude Code Task/Agent subagents with subagent_type equal to the returned `name` values.",
+            parentThreadRule: "Do not preload every provider prompt in the parent; each scout loads only the provider prompt for its lane.",
+        },
+    };
+}
 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.68",
+  "version": "0.1.70",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",
@@ -36,6 +36,7 @@
   },
   "files": [
     "dist",
+    "agents",
     "skills",
     ".claude-plugin",
     ".mcp.json",

package/skills/create-campaign/SKILL.md

@@ -11,6 +11,7 @@ allowed-tools:
   - mcp__sellable__get_subskill_asset
   - mcp__sellable__search_subskill_prompts
   - mcp__sellable__get_provider_prompt
+  - mcp__sellable__get_source_scout_registry
   - mcp__sellable__get_message_prompt
   - mcp__sellable__get_active_workspace
   - mcp__sellable__list_senders
@@ -102,11 +103,15 @@ scout those angles as independent branches when the host can actually do it:
 LinkedIn Engagement / active post engagers (internal `signal-discovery`
 provider prompt), Sales Nav / title + company filters, and Prospeo Contact /
 domains only when relevant. In Codex, explicitly spawn the named custom scouts
-`linkedin_engagement_scout`, `sales_nav_scout`, and `prospeo_contact_scout` for
+`source-scout-linkedin-engagement`, `source-scout-sales-nav`, and `source-scout-prospeo-contact` for
 the credible lanes; Codex does not infer subagent fan-out from generic source
-comparison wording. In Claude Code, keep using the existing Task agents under
-`.claude/agents/`. If the host runs them sequentially, do not claim they ran in
-parallel. In chat, call the downstream copy stage `message generation`;
+comparison wording. In Claude Code, invoke the generated `source-scout-*`
+Task/Agent subagents for all credible lanes in one assistant message; the
+installer writes them from the same canonical Sellable agent registry with
+explicit Sellable MCP tool allowlists. The create-campaign-v2 subskill calls
+`get_source_scout_registry` before dispatch so the current registry, not this
+copy, is the runtime source of truth. If the host runs them sequentially, 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.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep

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

@@ -360,6 +360,11 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   user-facing choice should be approve/revise language, not "looks good".
   Approval options should refer to what the user just read, e.g. `Approve this
 brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
+  When the user chose `Find people for me` and the host supports subagents,
+  make the recommended approval label explicit: `Approve brief + use background
+  source scouts`. That gives Codex/Claude a user-visible request to launch
+  source-scout subagents after approval instead of silently falling back to
+  parent-thread provider probes.
   Include an `Open artifact:` link to `brief.md` before the approval question.
   The visible brief must come before local persistence chrome. After the brief
   is synthesized, render the approval-ready brief in chat before running visible
@@ -433,18 +438,23 @@ should test for this campaign. Those can run in parallel and usually take
   `message-validation.md`, then reconciles that the selected message basis rows
   still pass the final filter.
 - Parallel means real parallel execution, not optimistic progress copy. For the
-  lead-source scout in Codex, explicitly spawn one named custom scout per
-  credible source lane when subagents are available: `linkedin_engagement_scout`
+  lead-source scout, first call `get_source_scout_registry` and use the
+  returned canonical `name` values. In Codex, explicitly spawn one named custom scout per
+  credible source lane when subagents are available: `source-scout-linkedin-engagement`
   (display: LinkedIn Engagement Scout, powered by the `signal-discovery`
-  provider prompt), `sales_nav_scout` (Sales Nav Scout), and
-  `prospeo_contact_scout` (Prospeo Contact Scout). For Claude Code, keep using
-  the existing `.claude/agents/lead-explorer-*.md` Task agents. If host
-  subagents are unavailable, use independent MCP/tool calls in the same model
-  turn or dedicated Sellable MCP tools that perform server-side `Promise.all`
-  fan-out. If real parallel execution is not available or not allowed, run the
-  same DAG sequentially and use honest copy: `I’ll tighten the filter first,
-  then draft the message from the same sample.` Never say `kicking off two
-  workstreams`, `in parallel`, or `background` unless parallel branches were
+  provider prompt), `source-scout-sales-nav` (Sales Nav Scout), and
+  `source-scout-prospeo-contact` (Prospeo Contact Scout). For Claude Code, explicitly
+  invoke the generated `.claude/agents/source-scout-*.md` Task/Agent subagents
+  for all credible lanes in one assistant message; they are installed from the
+  same canonical Sellable agent registry and carry explicit Sellable MCP tool
+  allowlists. The parent thread should not preload every provider prompt before
+  spawning scouts; each scout loads only its own provider prompt. If host
+  subagents are unavailable, use independent MCP/tool calls
+  in the same model turn or dedicated Sellable MCP tools that perform
+  server-side `Promise.all` fan-out. If real parallel execution is not available
+  or not allowed, run the same DAG sequentially and use honest copy: `I’ll tighten the filter first,
+then draft the message from the same sample.` Never say `kicking off two
+workstreams`, `in parallel`, or `background` unless parallel branches were
   actually launched.
 - Never run a downstream stage until the active `flow.v2.json` step's
   `requiredArtifacts` exist.
@@ -601,13 +611,18 @@ Required behavior:
 - do not mutate DB-backed campaign state
 - run a real parallel source-angle scout when the source is not supplied and at
   least two viable source angles exist. Treat source scouting as independent
-  branches, then compare the outputs in `lead-review.md`. In Codex, explicitly
-  spawn named custom subagents in the same turn: `linkedin_engagement_scout`,
-  `sales_nav_scout`, and `prospeo_contact_scout` for the credible lanes. Codex
+  branches, then compare the outputs in `lead-review.md`. Call
+  `get_source_scout_registry` first so new scouts can be added without prompt
+  rewrites. In Codex, explicitly
+  spawn named custom subagents in the same turn: `source-scout-linkedin-engagement`,
+  `source-scout-sales-nav`, and `source-scout-prospeo-contact` for the credible lanes. Codex
   does not infer this from generic "compare paths" wording. If the realistic
   source set is LinkedIn Engagement + Sales Nav (Signals + Sales Nav), run both.
   If it is LinkedIn Engagement + Prospeo Contact (Signals + Prospeo), run both.
   If all three are credible, run all three when the host/runtime supports it.
+  In Claude Code, launch the matching `source-scout-linkedin-engagement`,
+  `source-scout-sales-nav`, and/or `source-scout-prospeo-contact` Task/Agent subagents
+  in the same assistant message, not as sequential scout turns.
   - Branch A: LinkedIn Engagement / active LinkedIn posts (internal provider:
     Signals / `signal-discovery`). Search relevant keyword lanes, review
     finalist posts, fetch top-post engagers, and estimate warm-fit volume.

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

@@ -224,14 +224,24 @@ setting: `~/.codex/config.toml` with
 Source-angle comparison should be real, not implied. When the source is not
 supplied and multiple source angles are viable, scout Signals, Sales Nav, and
 relevant domain/contact paths as independent branches when the host can do so.
-In Codex, explicitly spawn named custom scouts in the same turn:
-`linkedin_engagement_scout` (LinkedIn Engagement Scout, backed by the
-`signal-discovery` provider prompt), `sales_nav_scout` (Sales Nav Scout), and
-`prospeo_contact_scout` (Prospeo Contact Scout) for the credible lanes. Codex
+Call `get_source_scout_registry` first and use the returned canonical `name`
+values; the names below are the current registry entries. In Codex, explicitly
+spawn named custom scouts in the same turn:
+`source-scout-linkedin-engagement` (LinkedIn Engagement Scout, backed by the
+`signal-discovery` provider prompt), `source-scout-sales-nav` (Sales Nav Scout), and
+`source-scout-prospeo-contact` (Prospeo Contact Scout) for the credible lanes. Codex
 does not infer subagent fan-out from generic "compare paths" wording. In Claude
-Code, keep using the existing Task agents under `.claude/agents/`. If the host
-runs them sequentially, keep the output numeric but do not claim the source
-scout was parallel.
+Code, invoke the generated `source-scout-linkedin-engagement`, `source-scout-sales-nav`,
+and/or `source-scout-prospeo-contact` Task/Agent subagents in one assistant message so
+Claude can run the source lanes concurrently/background. These agents come from
+the same canonical Sellable registry and must load their matching provider
+prompt before searching. The parent thread should not fetch every provider
+prompt first; that burns time and often degenerates into parallel tool calls
+instead of true subagents. When asking the user to approve a brief with
+Sellable finding leads, use an explicit label like `Approve brief + use
+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.
 
 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

@@ -341,7 +341,7 @@
           "action": "run_subskill",
           "target": "find-leads",
           "mode": "campaignless-preview",
-          "sourceScoutRule": "When source is not user-supplied and at least two viable source angles exist, scout independent source angles with real parallelism when host/tooling permits. In Codex, explicitly spawn one named custom scout per credible lane in the same turn: linkedin_engagement_scout for LinkedIn Engagement / active post engagers (internal signal-discovery provider prompt), sales_nav_scout for Sales Nav title/company/activity filters, and prospeo_contact_scout for Prospeo account/domain/contact expansion. In Claude Code, use the existing .claude/agents/lead-explorer-*.md Task agents. Fallback to independent MCP/tool calls in the same model turn or dedicated Sellable MCP tools that perform server-side fan-out. Run LinkedIn Engagement + Sales Nav, LinkedIn Engagement + Prospeo Contact, or all three when credible. If real parallel execution is unavailable, run the same scouts sequentially and do not claim parallel execution. Compare outputs by raw volume, n/N sampled fit, estimated good-fit range, expected reply range, and tradeoff. Keep Signals/LinkedIn Engagement as viable when selected posts can produce ~150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable; when both are viable, present the choice and recommend the stronger default."
+          "sourceScoutRule": "When source is not user-supplied and at least two viable source angles exist, call get_source_scout_registry and use the returned canonical agent names, then scout independent source angles with real parallelism when host/tooling permits. In Codex, explicitly spawn one named custom scout per credible lane in the same turn: source-scout-linkedin-engagement for LinkedIn Engagement / active post engagers (internal signal-discovery provider prompt), source-scout-sales-nav for Sales Nav title/company/activity filters, and source-scout-prospeo-contact for Prospeo account/domain/contact expansion. In Claude Code, explicitly invoke the generated source-scout-linkedin-engagement, source-scout-sales-nav, and/or source-scout-prospeo-contact Task agents / Agent subagents in one assistant message so the lanes can run concurrently/background; those agents are installed from the canonical Sellable agent registry and carry explicit Sellable MCP tool allowlists. Fallback to independent MCP/tool calls in the same model turn or dedicated Sellable MCP tools that perform server-side fan-out. Run LinkedIn Engagement + Sales Nav, LinkedIn Engagement + Prospeo Contact, or all three when credible. If real parallel execution is unavailable, run the same scouts sequentially and do not claim parallel execution. Compare outputs by raw volume, n/N sampled fit, estimated good-fit range, expected reply range, and tradeoff. Keep Signals/LinkedIn Engagement as viable when selected posts can produce ~150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable; when both are viable, present the choice and recommend the stronger default."
         },
         {
           "action": "write_artifacts",

package/skills/find-leads/SKILL.md

@@ -65,22 +65,34 @@ The kickoff doc is the resume surface. Re-open it before repeating discovery wor
 
 ## Execution Backend Routing
 
+- Before source-scout dispatch, call `get_source_scout_registry` and use the
+  returned `name` values. The current canonical names are listed below for
+  readability, but the registry is the source of truth for install/runtime.
 - If Codex subagents are available, run the scout lanes with named custom
   agents. Spawn one agent per credible lane in the same turn, then wait for all
   lane results before synthesizing `lead-review.md`:
-  - `linkedin_engagement_scout` (display: LinkedIn Engagement Scout) for
+  - `source-scout-linkedin-engagement` (display: LinkedIn Engagement Scout) for
     active LinkedIn posts and engagers; internally this uses the
     `signal-discovery` provider prompt plus `search_signals` /
     `fetch_post_engagers`.
-  - `sales_nav_scout` (display: Sales Nav Scout) for Sales Navigator title,
+  - `source-scout-sales-nav` (display: Sales Nav Scout) for Sales Navigator title,
     company, geography, and activity filters.
-  - `prospeo_contact_scout` (display: Prospeo Contact Scout) for Prospeo
+  - `source-scout-prospeo-contact` (display: Prospeo Contact Scout) for Prospeo
     account/domain and verified-contact expansion.
-- If Claude `Task` is available, deep exploration uses the existing file-backed
-  Claude explorer agents:
-  - `./.claude/agents/lead-explorer-signals.md`
-  - `./.claude/agents/lead-explorer-sales-nav.md`
-  - `./.claude/agents/lead-explorer-prospeo.md`
+- Common parallel comparisons are LinkedIn Engagement + Sales Nav, LinkedIn
+  Engagement + Prospeo Contact, or all three when each lane is credible.
+- If Claude `Task`/`Agent` is available, deep exploration uses the file-backed
+  Claude explorer agents installed from the same canonical Sellable agent
+  registry. Launch every credible lane in the same assistant message so Claude
+  Code can run them concurrently/background:
+  - `./.claude/agents/source-scout-linkedin-engagement.md`
+  - `./.claude/agents/source-scout-sales-nav.md`
+  - `./.claude/agents/source-scout-prospeo-contact.md`
+- These Claude agents must have explicit Sellable MCP tool allowlists and must
+  load the matching provider prompt before searching.
+- The parent thread should not preload every provider prompt before launching
+  scouts. Spawn the credible scouts first; each scout loads only the provider
+  prompt for its lane and returns structured evidence.
 - Else if `multi_tool_use.parallel` is available, run independent discovery calls in parallel and synthesize locally.
 - Else run sequentially.
 - Never claim agents were used when they were not.
@@ -250,10 +262,13 @@ If the first probe has good quality but insufficient scale, iterate 1-2 times to
 When two or more source angles are viable, run the provider probes in real
 parallel when the host/runtime allows it. For Codex, explicitly spawn the
 named source scout agents above; Codex will not infer subagent fan-out from
-general "compare sources" wording. Examples: LinkedIn Engagement + Sales Nav,
-LinkedIn Engagement + Prospeo Contact, or Sales Nav + Prospeo Contact. If the
-host cannot run them in parallel, run the same probes sequentially and do not
-claim they ran in parallel.
+general "compare sources" wording. For Claude Code, explicitly invoke the
+matching `source-scout-*` Task/Agent subagents in one message instead of
+probing one lane, waiting, then probing the next. Examples: LinkedIn Engagement
+
+- Sales Nav, LinkedIn Engagement + Prospeo Contact, or Sales Nav + Prospeo
+  Contact. If the host cannot run them in parallel, run the same probes
+  sequentially and do not claim they ran in parallel.
 
 Treat refinement as a measured loop:
 
@@ -414,11 +429,13 @@ Show the light-touch results and ask whether to deep-dispatch or iterate.
 
 ## Layer 3: Selective deep exploration
 
-Spawn only the validated paths from Gate 1.
+Spawn only the validated paths from Gate 1. In Claude Code, invoke all selected
+`source-scout-*` agents in one turn so source scouting is concurrent when the
+runtime supports it.
 
-- `lead-explorer-signals`
-- `lead-explorer-sales-nav`
-- `lead-explorer-prospeo`
+- `source-scout-linkedin-engagement`
+- `source-scout-sales-nav`
+- `source-scout-prospeo-contact`
 
 Each explorer must return: