@sellable/mcp 0.1.69 → 0.1.70

package/README.md

@@ -240,13 +240,16 @@ Provider preflight contract:
 
 Parallel execution contract:
 
-- Claude host: use the installed `lead-explorer-signals`,
-  `lead-explorer-sales-nav`, and `lead-explorer-prospeo` Task/Agent subagents
+- 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

@@ -2,12 +2,27 @@
   "version": 1,
   "agents": [
     {
-      "id": "linkedin-engagement-scout",
-      "promptFile": "linkedin-engagement-scout.md",
+      "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": {
-        "name": "linkedin_engagement_scout",
-        "filename": "linkedin-engagement-scout.toml",
         "description": "Sellable lead-source scout for LinkedIn post engagement and active conversation signals.",
         "modelReasoningEffort": "medium",
         "sandboxMode": "read-only",
@@ -18,8 +33,6 @@
         ]
       },
       "claude": {
-        "name": "lead-explorer-signals",
-        "filename": "lead-explorer-signals.md",
         "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,
@@ -36,12 +49,27 @@
       }
     },
     {
-      "id": "sales-nav-scout",
-      "promptFile": "sales-nav-scout.md",
+      "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": {
-        "name": "sales_nav_scout",
-        "filename": "sales-nav-scout.toml",
         "description": "Sellable lead-source scout for Sales Navigator role, company, and activity filters.",
         "modelReasoningEffort": "medium",
         "sandboxMode": "read-only",
@@ -52,8 +80,6 @@
         ]
       },
       "claude": {
-        "name": "lead-explorer-sales-nav",
-        "filename": "lead-explorer-sales-nav.md",
         "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,
@@ -70,12 +96,27 @@
       }
     },
     {
-      "id": "prospeo-contact-scout",
-      "promptFile": "prospeo-contact-scout.md",
+      "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": {
-        "name": "prospeo_contact_scout",
-        "filename": "prospeo-contact-scout.toml",
         "description": "Sellable lead-source scout for Prospeo account/domain and broad contact expansion.",
         "modelReasoningEffort": "medium",
         "sandboxMode": "read-only",
@@ -86,8 +127,6 @@
         ]
       },
       "claude": {
-        "name": "lead-explorer-prospeo",
-        "filename": "lead-explorer-prospeo.md",
         "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,

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.69",
+  "version": "0.1.70",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

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,12 +103,14 @@ 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, invoke the generated `lead-explorer-*`
+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. If the host runs them sequentially, do not
+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.
 

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,15 +438,18 @@ 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, explicitly
-  invoke the generated `.claude/agents/lead-explorer-*.md` Task/Agent subagents
+  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. If host subagents are unavailable, use independent MCP/tool calls
+  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,
@@ -603,15 +611,17 @@ 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 `lead-explorer-signals`,
-  `lead-explorer-sales-nav`, and/or `lead-explorer-prospeo` Task/Agent subagents
+  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

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

@@ -224,17 +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, invoke the generated `lead-explorer-signals`, `lead-explorer-sales-nav`,
-and/or `lead-explorer-prospeo` Task/Agent subagents in one assistant message so
+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. If the host runs them sequentially, keep the output
-numeric but do not claim the source scout was parallel.
+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, explicitly invoke the generated lead-explorer-signals, lead-explorer-sales-nav, and/or lead-explorer-prospeo 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."
+          "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,16 +65,19 @@ 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.
 - Common parallel comparisons are LinkedIn Engagement + Sales Nav, LinkedIn
   Engagement + Prospeo Contact, or all three when each lane is credible.
@@ -82,11 +85,14 @@ The kickoff doc is the resume surface. Re-open it before repeating discovery wor
   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/lead-explorer-signals.md`
-  - `./.claude/agents/lead-explorer-sales-nav.md`
-  - `./.claude/agents/lead-explorer-prospeo.md`
+  - `./.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.
@@ -257,7 +263,7 @@ 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. For Claude Code, explicitly invoke the
-matching `lead-explorer-*` Task/Agent subagents in one message instead of
+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
@@ -424,12 +430,12 @@ 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. In Claude Code, invoke all selected
-`lead-explorer-*` agents in one turn so source scouting is concurrent when the
+`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: