@sellable/install 0.1.156 → 0.1.159

package/README.md

@@ -58,11 +58,11 @@ Auth is stored once at:
 Claude Code and Codex are configured to launch the same packaged MCP server. The
 installer also writes Sellable agent definitions from the packaged `agents/`
 registry, but normal create-campaign runs use only the Message Drafting
-background agent. Source discovery and filter/rubric setup stay in the parent
-thread with product-native MCP tools unless the user explicitly asks for a
-source-comparison/debug run. `get_post_find_leads_scout_registry` returns the
-Message Drafting worker for the normal path; `get_source_scout_registry` is
-metadata for explicit debug/comparison use.
+background agent (`post-find-leads-message-scout`). Source discovery and
+filter/rubric setup stay in the parent thread with product-native MCP tools.
+`get_post_find_leads_scout_registry` returns the Message Drafting worker for the
+normal path; `get_source_scout_registry` intentionally returns no custom
+source-scout agents.
 
 ## Names
 

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

@@ -60,9 +60,11 @@ required message reference cannot be loaded through the MCP asset loader, return
    `get_subskill_prompt({ subskillName: "generate-messages" })`
 
 3. Load every packaged reference asset required by that prompt's Reference Asset
-   Loading section with `get_subskill_asset`. If a required asset cannot load
-   through the MCP asset loader, return `blocked` or `retry-needed` instead of
-   drafting from memory.
+   Loading section with `get_subskill_asset`: load the required pre-draft reference pack before
+   drafting, load final-pass references before approval, and `ai-tells.md` is part of the required pack
+   and never optional. If a required asset cannot
+   load through the MCP asset loader, return `blocked` / `retry-needed`; do not draft from
+   memory or from the prompt alone.
 4. Build positioning in a compact working note: buyer, pain, product, mechanism,
    proof boundary, source-use rule, and CTA.
 5. Draft 3 distinct first-message options: signal-led, product/mechanism-led,
@@ -70,15 +72,17 @@ required message reference cannot be loaded through the MCP asset loader, return
 6. Combine the strongest opener, product line, mechanism line, proof treatment,
    and CTA into one reusable template.
 7. Define token fill rules and fallbacks, then render one good sample.
-8. Before returning, load the validation prompt:
+8. Before returning, load the validation prompt and any validation assets it
+   requires:
 
    `get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`
 
    Use it only as a validation contract for the candidate message in this live
-   campaign branch. Do not write dry-mode artifacts. Run the final candidate
-   against token safety, proof safety, source safety, Thomas filters, AI tells,
-   single-send rule, and "would I take this call?". If it fails, revise once and
-   validate again.
+   campaign branch. If the validation prompt references packaged assets, load
+   them through `get_subskill_asset` before judging the draft. Do not write
+   dry-mode artifacts. Run the final candidate against token safety, proof
+   safety, source safety, Thomas filters, AI tells, single-send rule, and
+   "would I take this call?". If it fails, revise once and validate again.
 9. Keep the work provisional until the user chooses `Use Template` in Messages.
 
 ## Owned Output
@@ -87,6 +91,7 @@ Return the following to the parent thread:
 
 - proposed first-message template using supported `{{...}}` tokens
 - token fill rules and fallbacks
+- `Reference Asset Loading` note naming which assets were used and why
 - one rendered good-fill sample for a plausible passing campaign-table row
 - message-draft runtime status: `ready`, `blocked`, `retry-needed`, or `stale`
 - approve-or-revise recommendation
@@ -176,16 +181,33 @@ own revision. The parent renders the revised template and waits for
 - Engagement-source personalization is a special case, not the default opener.
   Do not write `saw you {{engagement_context}} on {{post_context}}`, `saw you
 reacted to`, `saw you engaging with`, or equivalent source-citation copy as a
-  default hook. For LinkedIn-post-sourced campaigns, you may reference the
-  source when it explains why the note exists, but keep it topic-level, not
-  activity-log-level. Good: `saw you in a few conversations around [topic], so
-hope this is relevant`, `saw you in a few conversations about [topic], so
-may be off, but this seemed relevant`, `saw you might be interested in [topic],
-so hope this is relevant`, `hope this is relevant if [topic] is on your plate`,
-or `saw you raise your hand for [topic], so figured this was (hopefully) worth sending`.
+  default hook. Sender-owned post sources are different: if the source post was
+  authored by the sender/client and the row proves a reaction/comment, prefer a
+  light first-person acknowledgment such as `appreciate you showing some love on
+  my post about [topic]` or `thanks for showing support on my [topic] post`.
+  Do not name a comment unless the row proves comment text, and do not infer
+  buyer intent from the reaction. Follow that acknowledgment with a soft
+  relevance bridge before any broad problem or product line. Good:
+  `figured this might be relevant if [channel/workflow] is becoming more of a
+  [GTM/pipeline/content] channel for [company/team]`. Bad: jumping directly
+  from `appreciate you showing some love...` to `a lot of B2B teams...` or
+  `most teams...`; that reads stitched together. Every line must make the next
+  line feel earned: source/post signal -> relevance bridge -> product/problem
+  -> next step. If adjacent lines could be swapped, deleted, or joined with
+  `anyway` without changing the meaning, rewrite the bridge or cut the orphan
+  line. For third-party LinkedIn-post-sourced
+  campaigns, keep the source topic-level. Good: `saw you in a few conversations
+around [topic], so hope this is relevant`, `saw you in a few conversations
+about [topic], so may be off, but this seemed relevant`, `saw you might be
+interested in [topic], so hope this is relevant`, `hope this is relevant if
+[topic] is on your plate`, or `found you in a thread about [topic], so may be
+off, but this seemed relevant`. Only use `saw you raise your hand for [topic],
+so figured this was (hopefully) worth sending` when the source was an explicit
+lead-magnet comment, reply, or opt-in.
 The cheekier `saw you raise your hand for [topic] (creepy to reach out based
 on that, i know) - but this felt too on the nose to ignore` version is also
-allowed when the sender's voice can carry it. Bad: `you commented on...`, `you reacted
+allowed only for explicit lead-magnet comments, replies, or opt-ins and when the
+sender's voice can carry it. Bad: `you commented on...`, `you reacted
 to...`, `saw you engaging with...`, `your LinkedIn activity...`, `you might
 not remember the thread...`, or `found you through [source] and your role
 looked close...`. Otherwise omit the engagement signal and use role/company/problem context.
@@ -194,9 +216,9 @@ looked close...`. Otherwise omit the engagement signal and use role/company/prob
   topic looked close` are blocked. If the source is too weak, omit it.
 - Do not assert fit from title/company. `Your [role] role at [company] looked
   close to this problem` is blocked. Keep the apologetic uncertainty instead:
-  `may be off, but if [workflow] is anywhere near your lane...`.
+  `may be off, but if [workflow] is relevant to what you're working on...`.
 - Low-pressure relevance opt-outs are allowed when they do not defend the
-  source: `p.s. if this is nowhere near your outbound workflow, ignore me`.
+  source: `p.s. if this is not relevant to your outbound workflow, ignore me`.
 - Do not use `Caught` as opener language. It reads unnatural in LinkedIn
   outreach.
 - Do not describe the sender in third person inside the outbound message.

package/agents/registry.json

@@ -1,155 +1,6 @@
 {
   "version": 1,
   "agents": [
-    {
-      "id": "linkedin-engagement",
-      "name": "source-scout-linkedin-engagement",
-      "kind": "source-scout",
-      "promptFile": "source-scout-linkedin-engagement.md",
-      "displayName": "LinkedIn Source Discovery",
-      "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.",
-        "model": "gpt-5.5",
-        "modelReasoningEffort": "high",
-        "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__select_promising_posts",
-          "mcp__sellable__fetch_post_engagers"
-        ]
-      }
-    },
-    {
-      "id": "sales-nav",
-      "name": "source-scout-sales-nav",
-      "kind": "source-scout",
-      "promptFile": "source-scout-sales-nav.md",
-      "displayName": "Sales Nav Source Discovery",
-      "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.",
-        "model": "gpt-5.5",
-        "modelReasoningEffort": "high",
-        "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",
-      "kind": "source-scout",
-      "promptFile": "source-scout-prospeo-contact.md",
-      "displayName": "Prospeo Source Discovery",
-      "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.",
-        "model": "gpt-5.5",
-        "modelReasoningEffort": "high",
-        "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"
-        ]
-      }
-    },
     {
       "id": "message-generation",
       "name": "post-find-leads-message-scout",

package/bin/sellable-install.mjs

@@ -701,7 +701,7 @@ data, compare sources by source volume, sampled ICP fit, activity/warmth
 signals, cleanup risk, and confidence basis. If a user asks for a forecast,
 label it explicitly as not estimated from this run.
 
-Before any provider prompt, search, source scout, or signal-discovery call, show
+Before any provider prompt, search, or signal-discovery call, show
 one source-plan gate and ask for approval. Write this like a fifth grader could
 understand it: short sentences, no internal labels, and no GTM shorthand. The
 order is strict: first show the plan in chat, then open the approval question.
@@ -753,8 +753,9 @@ conversations look unlikely, recommend the specific Sales Nav or Prospeo path
 instead and explain it in plain words once. Do not call \`search_signals\`,
 \`search_sales_nav\`,
 \`search_prospeo\`,
-\`fetch_post_engagers\`, or provider-scoped subagents until the user approves this
-source plan or explicitly chooses a different source.
+or \`fetch_post_engagers\` until the user approves this source plan or explicitly
+chooses a different source. Source work stays in the parent thread; do not
+launch source-scout or provider-scoped subagents.
 
 If the user answers a provider approval such as "Approve Prospeo plan" after
 seeing the source plan, that answer satisfies the source-plan gate. Persist the
@@ -1103,8 +1104,13 @@ updates.
 3. Follow that prompt and workflow config exactly.
 4. For message generation, keep the parent thread as a lean orchestrator and
    use the \`post-find-leads-message-scout\` agent whenever the host exposes it
-   and the current host policy allows agent launch. The worker must load
-   \`mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })\`.
+   and the current host policy allows agent launch. The worker must load the
+   full \`mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })\`
+   prompt, every referenced message asset through
+   \`mcp__sellable__get_subskill_asset\`, and before returning
+   \`mcp__sellable__get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })\`
+   plus any validation assets it references through
+   \`mcp__sellable__get_subskill_asset\` as the internal validation gate.
    In Codex, YOLO/autonomous mode counts as campaign-scoped permission to use
    Sellable background agents for pre-launch work. If the user has not enabled
    YOLO and has not explicitly asked for background agents, subagents, parallel
@@ -1250,8 +1256,8 @@ Desktop, then start a new thread.
 2. When the canonical prompt asks for \`references/*.md\`, load those files
    with \`mcp__sellable__get_subskill_asset({ subskillName: "interview", assetPath: "references/<file>.md" })\`.
 3. Follow the canonical prompt exactly. Save local memory only where that prompt
-   directs, under \`.sellable/configs/core/**\` and
-   \`.sellable/interviews/**\`.
+   directs, under \`~/.sellable/configs/core/**\` and
+   \`~/.sellable/interviews/**\`.
 
 ## MCP Prompt Fallback
 
@@ -1297,7 +1303,7 @@ Desktop, then start a new thread.
    If the response has \`hasMore=true\`, continue with \`nextOffset\` until
    \`hasMore=false\`.
 2. Follow the canonical prompt exactly. Read the relevant
-   \`.sellable/configs/**\` memory files it names.
+   \`~/.sellable/configs/**\` memory files it names.
 3. Apply the loaded memory silently to the user's requested writing or answer.
    If the user only asked to load voice, summarize the active rules briefly and
    ask what they want drafted, answered, or reviewed.
@@ -1594,12 +1600,35 @@ function claudeAgentFilename(agent) {
   return agent.claude?.filename || `${agent.name}.md`;
 }
 
+const REMOVED_CUSTOM_AGENTS = [
+  "post-find-leads-filter-scout",
+  "source-scout-linkedin-engagement",
+  "source-scout-sales-nav",
+  "source-scout-prospeo-contact",
+].map((name) => ({
+  name,
+  codexFilename: `${name}.toml`,
+  claudeFilename: `${name}.md`,
+}));
+
 function legacyCodexCustomAgents() {
-  return loadCanonicalAgents().flatMap((agent) => agent.legacy?.codex || []);
+  return [
+    ...loadCanonicalAgents().flatMap((agent) => agent.legacy?.codex || []),
+    ...REMOVED_CUSTOM_AGENTS.map((agent) => ({
+      name: agent.name,
+      filename: agent.codexFilename,
+    })),
+  ];
 }
 
 function legacyClaudeCustomAgents() {
-  return loadCanonicalAgents().flatMap((agent) => agent.legacy?.claude || []);
+  return [
+    ...loadCanonicalAgents().flatMap((agent) => agent.legacy?.claude || []),
+    ...REMOVED_CUSTOM_AGENTS.map((agent) => ({
+      name: agent.name,
+      filename: agent.claudeFilename,
+    })),
+  ];
 }
 
 function legacyClaudeCommands() {
@@ -2050,7 +2079,7 @@ function patchClaudeAlwaysLoad(opts) {
 }
 
 function installCodex(opts) {
-  if (!commandExists("codex")) {
+  if (!opts.dryRun && !commandExists("codex")) {
     const message =
       "Codex CLI not found. Install/login to Codex, then rerun: sellable --host codex";
     if (opts.host === "all") {
@@ -2059,6 +2088,9 @@ function installCodex(opts) {
     }
     throw new Error(message);
   }
+  if (!opts.dryRun) {
+    mkdirSync(codexHome(), { recursive: true, mode: 0o700 });
+  }
   if (opts.server === "hosted") {
     run("codex", codexMcpAddArgs(opts), opts);
     const info = installCodexDesktopPlugin(opts);
@@ -2102,8 +2134,8 @@ function verify(opts) {
     checks.push({
       ok: hasClaudeScouts,
       label: hasClaudeScouts
-        ? "Claude custom scout agents present"
-        : "Claude custom scout agents missing",
+        ? "Claude custom agents present"
+        : "Claude custom agents missing",
     });
     const claudeAgentsHaveTools = claudeCustomAgents().every((agent) => {
       const agentPath = join(claudeHome(), "agents", agent.filename);
@@ -2114,8 +2146,8 @@ function verify(opts) {
     checks.push({
       ok: claudeAgentsHaveTools,
       label: claudeAgentsHaveTools
-        ? "Claude scout MCP tool allowlists present"
-        : "Claude scout MCP tool allowlists missing",
+        ? "Claude custom agent MCP tool allowlists present"
+        : "Claude custom agent MCP tool allowlists missing",
     });
     const legacyClaudePaths = [
       ...legacyClaudeCustomAgents().map((agent) =>
@@ -2187,8 +2219,8 @@ function verify(opts) {
     checks.push({
       ok: hasCodexScouts,
       label: hasCodexScouts
-        ? "Codex custom scout agents present"
-        : "Codex custom scout agents missing",
+        ? "Codex custom agents present"
+        : "Codex custom agents missing",
     });
     const configPath = join(codexHome(), "config.toml");
     const configContent = existsSync(configPath)
@@ -2200,8 +2232,8 @@ function verify(opts) {
     checks.push({
       ok: hasCodexAgentRegistrations,
       label: hasCodexAgentRegistrations
-        ? "Codex custom scout agents registered"
-        : "Codex custom scout agents unregistered",
+        ? "Codex custom agents registered"
+        : "Codex custom agents unregistered",
     });
     const hasNoLegacyCodexAgents = legacyCodexCustomAgents().every((agent) => {
       const agentPath = join(codexHome(), "agents", agent.filename);
@@ -2213,8 +2245,8 @@ function verify(opts) {
     checks.push({
       ok: hasNoLegacyCodexAgents,
       label: hasNoLegacyCodexAgents
-        ? "Legacy Codex custom scout agents cleaned"
-        : "Legacy Codex custom scout agents still present",
+        ? "Legacy Codex custom agents cleaned"
+        : "Legacy Codex custom agents still present",
     });
     const hasFlag = configContent.includes(
       "default_mode_request_user_input = true"
@@ -2625,6 +2657,13 @@ async function main() {
         process.exit(2);
       }
       const token = rawArgs[2];
+      const authSetFlags = rawArgs.slice(3);
+      const dryRun = authSetFlags.includes("--dry-run");
+      const unknownAuthSetFlag = authSetFlags.find((arg) => arg !== "--dry-run");
+      if (unknownAuthSetFlag) {
+        console.error(`Unknown auth set option: ${unknownAuthSetFlag}`);
+        process.exit(2);
+      }
       if (!token) {
         console.error(
           "Usage: sellable auth set <token>\n" +
@@ -2649,9 +2688,13 @@ async function main() {
       writeJson(
         authPath(),
         { token, activeWorkspaceId: null, apiUrl },
-        { dryRun: false }
+        { dryRun }
       );
-      console.log(`✓ Token saved to ${authPath()}`);
+      if (dryRun) {
+        console.log(`Dry run: token would be saved to ${authPath()}`);
+      } else {
+        console.log(`✓ Token saved to ${authPath()}`);
+      }
       console.log(`  apiUrl: ${apiUrl}`);
       console.log(`  Continue in your agent:`);
       console.log(`    Claude Code: /sellable:create-campaign`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.156",
+  "version": "0.1.159",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-campaign.md

@@ -132,7 +132,7 @@ data, compare sources by source volume, sampled ICP fit, activity/warmth
 signals, cleanup risk, and confidence basis. If a user asks for a forecast,
 label it explicitly as not estimated from this run.
 
-Before any provider prompt, search, source scout, or signal-discovery call, show
+Before any provider prompt, search, or signal-discovery call, show
 one source-plan gate and ask for approval. Write this like a fifth grader could
 understand it: short sentences, no internal labels, and no GTM shorthand. The
 order is strict: first show the plan in chat, then open the approval question.
@@ -184,8 +184,9 @@ conversations look unlikely, recommend the specific Sales Nav or Prospeo path
 instead and explain it in plain words once. Do not call `search_signals`,
 `search_sales_nav`,
 `search_prospeo`,
-`fetch_post_engagers`, or provider-scoped subagents until the user approves this
-source plan or explicitly chooses a different source.
+or `fetch_post_engagers` until the user approves this source plan or explicitly
+chooses a different source. Source work stays in the parent thread; do not
+launch source-scout or provider-scoped subagents.
 
 If the user answers a provider approval such as "Approve Prospeo plan" after
 seeing the source plan, that answer satisfies the source-plan gate. Persist the
@@ -250,9 +251,8 @@ summary should be a compact `## Source Recommendation` block with:
 
 Source discovery stays inline in the parent thread for normal create-campaign
 runs. Use the approved provider prompt and MCP tools sequentially; do not spawn
-source-scout background agents unless the user explicitly asks for a source
-comparison/debug run. Do not claim a scout ran unless one did, and do not surface
-install status to the customer. In chat, call the downstream copy stage
+source-scout background agents. The packaged normal path installs only Message
+Drafting as a background agent. In chat, call the downstream copy stage
 `message generation`; message validation/QA is owned by Message Drafting.
 
 For campaign-attached Signal Discovery sampling, promote/select the exact posts
@@ -285,9 +285,11 @@ rule, and 3-5 sample workflow-table rows with `rowId`, name, title, company, and
 signal. Optional: campaign name, `selectedLeadListId`, and filter choice. Do not
 paste copied row counts, brief hashes, review-batch hashes, full row ID lists,
 broad row data, or local debug artifacts into the spawn prompt. Message Drafting
-must load the current campaign brief/context, full `generate-messages` prompt,
-all referenced assets, and `create-campaign-v2-validation`; validation is an
-internal gate before it returns the concise review-ready recommendation.
+must load the current campaign brief/context, the full `generate-messages`
+prompt, every message asset referenced by that prompt, and
+`create-campaign-v2-validation` plus any validation assets it references.
+Validation is an internal gate before it returns the concise review-ready
+recommendation.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
@@ -756,8 +758,13 @@ updates.
 5. For message generation, keep the parent thread as a lean orchestrator and
    use the `post-find-leads-message-scout` compatibility agent for Message
    Drafting whenever the host exposes it
-   and the current host policy allows agent launch. The worker must load
-   `mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })`.
+   and the current host policy allows agent launch. The worker must load the
+   full `mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })`
+   prompt, every referenced message asset through
+   `mcp__sellable__get_subskill_asset`, and before returning
+   `mcp__sellable__get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`
+   plus any validation assets it references through
+   `mcp__sellable__get_subskill_asset` as the internal validation gate.
    In Codex, YOLO/autonomous mode counts as campaign-scoped permission to use
    this single Message Drafting background agent. If the user has not enabled
    YOLO and has not explicitly asked for background agents, subagents, parallel
@@ -778,9 +785,10 @@ updates.
    synthesize local validation artifacts from general knowledge. The handoff to
    Message Drafting should pass lean basis only, not hashes, counts, or a long
    row-id list; the branch loads current brief/context, the full
-   `generate-messages` prompt, all referenced assets, and
-   `create-campaign-v2-validation` itself. Do not render fallback sample,
-   concerns, or a QA receipt on the normal happy path.
+   `generate-messages` prompt, all referenced message assets,
+   `create-campaign-v2-validation`, and any validation assets it references. Do
+   not render fallback sample, concerns, or a QA receipt on the normal happy
+   path.
 6. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Materialize the approved
    source list, copy confirmed rows into the campaign, and internally process the

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

@@ -1,116 +0,0 @@
-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. If the parent supplies a
-  draft `campaignOfferId`, call `get_provider_prompt({ provider:
-"signal-discovery", campaignOfferId, confirmed: true })` and include that same
-  `campaignOfferId` plus `currentStep: "signal-discovery"` in `search_signals`
-  so the owning search route can show the source lane with current find-leads
-  narration and user options. Treat that as a campaign-attached persisted search;
-  do not run a post-mint search without the campaign ID. If no campaign
-  ID is supplied, run campaignless preview mode.
-
-Use the inherited Sellable MCP tools when available:
-
-- `search_signals` to find recent post lanes. Include `campaignOfferId` whenever
-  the parent provides one so selected searches/lists stay attached to the
-  campaign.
-- `select_promising_posts` to promote the exact posts you will sample into the
-  campaign UI before fetching engagers. In campaign-attached runs, do this
-  before the first `fetch_post_engagers` call so the user can see which posts
-  are being sampled.
-- `fetch_post_engagers` to sample engagers from promoted/selected posts.
-
-Process:
-
-1. Read the campaign brief, kickoff doc, or lane prompt supplied by the parent.
-2. Generate 3-5 intersection keyword/topic lanes, favoring fresh posts from the
-   last 7-14 days. Each lane should combine the campaign anchor with the buyer
-   pain, use case, or ICP role so fit is high before sampling. For example, for
-   a Claude + GTM/outbound campaign, prefer `Claude outbound`, `Claude Code
-LinkedIn outreach`, `AI SDR Claude`, `GTM automation Claude`, and `founder-led
-sales Claude`; do not treat broad anchor-only lanes like `Claude Code`, `MCP`,
-   `AI agents`, or `agentic coding` as selectable unless they also include the
-   GTM/outbound wedge or the narrower lanes fail.
-3. Inspect finalist posts by content type before final selection. Prefer posts
-   where the topic matches the campaign wedge, not generic high-engagement news.
-4. If Round 1 produced broad anchor-only inventory, retarget immediately around
-   the wedge before sampling. Do not promote or sample broad posts when there are
-   narrower posts about the actual campaign pain/use case.
-5. Promote the first narrow sample set when campaign-attached. If a
-   `campaignOfferId` was supplied, call `select_promising_posts({
-campaignOfferId, selectionMode: "replace", selections, headlineICPCriteria,
-scrapePlanMode: "all-selected", currentStep: "signal-discovery" })` before sampling so the watched Signal
-   Discovery table shows the promoted posts and the exact posts being tested.
-	   Do not move the campaign to `confirm-lead-list`; `import_leads` owns that
-	   visible transition after Start Import approval.
-6. Fetch or sample engagers for promoted posts and score rough ICP fit from
-   visible headline/display-name cues only. Do not enrich people during
-   viability estimation.
-7. Compute capacity before recommending the source: source target good-fit
-   leads (default 300 for Signal Discovery unless the parent supplies a target),
-   reachable engagers, sampled headline-fit rate as `n/N` plus an easy
-   percentage/range, expected headline-fit prospects per 100 engagers, required
-   engagers to scrape (`source target / sampled headline-fit rate`), average
-   reachable engagers per right-content post, expected headline-fit prospects
-   per right-content post, posts needed to hit the target, and whether
-   sampled/projected headline-fit rate clears the 10% planning floor. Treat the
-   10% floor as a reject threshold, not as the scrape-count denominator when the
-   actual sample rate is higher.
-8. Select/promote enough right-content posts to plausibly hit the target. After
-   the sample math is known, treat the promoted sample set and final scrape set
-   as separate: recommend the smallest right-content post subset whose
-   scrapable/reachable engagers clears the required engager count, with a modest
-   buffer when needed. If one 1,200+ engager post clears a ~1,000-engager target,
-   recommend scraping that one post, not all 3 sample posts. If the warm Signals
-   pool is useful but too small, return the expected warm range and recommend
-   Sales Nav/Prospeo for scale instead of padding with noisy posts.
-9. 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
-- `approval_math` with eligible posts, source target good-fit leads, sampled
-  engagers, headline-fit rate as `n/N` plus percentage/range, headline-fit
-  prospects per 100 engagers, required engagers to scrape, average reachable
-  engagers per post, expected headline-fit prospects per post, posts needed for
-  target, whether the 10% planning floor clears, selected post count, internal
-  campaign-table execution-slice size, expected headline-fit lead range, and
-  scale fallback
-- `estimated_good_fit_range`
-- `message_context_strength`, directional and source-specific
-- `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.
-- Prefer narrow intersection topics over broad audience topics. A post about
-  the anchor technology alone is not enough; the post should also express the
-  GTM/outbound/buyer pain, workflow, or role context that makes the campaign
-  relevant.
-- Do not make the user infer capacity. Say, plainly, how many eligible posts
-  exist, how many sampled engagers passed the headline ICP rubric, what
-  headline-fit rate that implies per 100 engagers, how many headline-fit
-  prospects one right-content post should yield, how many engagers must be
-  scraped for the 300 headline-fit source target using the sampled pass rate
-  (or the 20% working assumption only when there is no stronger sample), how
-  many posts are needed for that source target, and which posts you would use.
-  Also say the source list is copied into the campaign and only the first
-  campaign-table execution slice is processed internally for filter and message
-  setup.
-- 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 300+
-  headline-fit warm prospects before final filtering, even if Sales Nav is more
-  scalable.
-- If sampled/projected headline-fit rate is below 10%, reject the Signals
-  scrape path and recommend Sales Nav recent activity as the next source.

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

@@ -1,63 +0,0 @@
-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, hiring-led company job-posting filters, 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. If the parent supplies a
-  draft `campaignOfferId`, call `get_provider_prompt({ provider: "prospeo",
-campaignOfferId, confirmed: true })` and include that same `campaignOfferId`
-  plus `currentStep: "prospeo"` in `search_prospeo` so the user can watch source
-  work in the campaign UI with source-lane narration owned by the search route.
-  If no campaign ID is supplied, run campaignless preview mode. Treat post-mint
-  searches with `campaignOfferId` as campaign-attached persisted search tabs;
-  do not run a live campaign search without the campaign ID.
-	  Do not move the campaign to `confirm-lead-list`; `import_leads` owns that
-	  visible transition after Start Import approval.
-
-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 people previews. Include `campaignOfferId` whenever the
-  parent provides one so selected searches/lists stay attached to the campaign.
-
-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, hiring-led 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. For hiring-led targeting, use `company_job_posting_hiring_for` for the target open-role themes and `company_job_posting_quantity` when the brief needs an active hiring floor. Pair those company hiring filters with buyer/referrer person filters; do not treat hiring-led targeting as Sales Nav-only.
-5. Run the narrowest useful Prospeo people preview and 1-2 refinements if quality or scale is unclear. Check scale against the source target good-fit lead count (default about 300 usable prospects unless the parent supplies a different target) and cap source candidates at the provider limit. Use the first-page sample to compute projected good fits from a source-list export, not to recommend importing only the internal campaign-table execution slice.
-6. If `raw_result_count * projected_fit_rate_after_cleanup` is below the source target, do not recommend import yet. Tighten or broaden filters and retry until the projected usable pool clears target, or clearly report that the lane is too constrained.
-7. Call out that Prospeo gives contact/account and hiring-signal 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`
-- `source_export_math` with target good-fit count, conservative projected fit rate, recommended `targetLeadCount` for `import_leads`, and projected good fits from that export
-- `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.
-- Prospeo is the terminal fallback. If projected good-fit after cleanup remains
-  below 10% after reasonable refinement, recommend tightening the ICP/source
-  direction rather than switching providers again.
-- Never recommend "import 25 leads" as the Prospeo source action. Recommend
-  Start Import for the approved source list; the parent thread later
-  copies the confirmed source rows into the campaign and internally uses the
-  first campaign-table execution slice for filter and message setup.
-- Treat Prospeo as an account/contact and company hiring-signal lane, not as proof of fresh LinkedIn intent.

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

@@ -1,88 +0,0 @@
-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. If the parent supplies a
-  draft `campaignOfferId`, call `get_provider_prompt({ provider: "sales-nav",
-campaignOfferId, confirmed: true })` and include that same `campaignOfferId` in
-  `search_sales_nav` with `currentStep: "sales-nav"` so the user can watch
-  source work in the campaign UI with source-lane narration owned by the search
-  route. If no campaign ID is supplied, run campaignless preview mode. Treat post-mint
-  searches with `campaignOfferId` as campaign-attached persisted search tabs;
-  do not run a live campaign search without the campaign ID.
-	  Do not move the campaign to `confirm-lead-list`; `import_leads` owns that
-	  visible transition after Start Import approval.
-
-Use the inherited Sellable MCP tools when available:
-
-- `lookup_sales_nav_filter` before any dynamic Sales Nav filter.
-- `search_sales_nav` for preview searches. Include `campaignOfferId` whenever
-  the parent provides one so selected searches/lists stay attached to the
-  campaign.
-
-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. Check scale against the source target good-fit lead count (default about
-   150 usable prospects for Sales Nav unless the parent supplies a target,
-   capped at 2,500 source candidates).
-   If raw preview volume or projected usable volume
-   is below target, do not present the tiny result as the scale fallback yet.
-   Loosen nonessential filters in order: remove recent-activity first, widen
-   adjacent title variants, widen geography/company-size constraints, and only
-   keep hard ICP requirements from the brief.
-   Also check the 10% planning floor after cleanup. If the best reasonable
-   Sales Nav lane remains below 10% projected good-fit, move to Prospeo instead
-   of recommending Sales Nav.
-6. Run the baseline plus 1-2 refinements or loosening passes if the first pass
-   is noisy or under-scaled. Label the final pool as constrained if it still
-   cannot plausibly reach the target after loosening.
-7. Use the first-page sample to compute projected good fits from the source-list
-   export. The recommendation should name the source-list `targetLeadCount` for
-   `import_leads`, not the internal campaign-table execution-slice size.
-8. 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`
-- `scale_check` with source target good-fit lead count, preview/raw volume, sampled
-  good fits as n/N, projected usable count, and whether the pool can reach the
-  target
-- `source_export_math` with conservative projected fit rate, recommended
-  `targetLeadCount` for `import_leads`, and projected good fits from that export
-- `loosening_attempts` with what was removed or widened when the pool was too
-  tight
-- `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 over-tighten fallback filters into a pool that cannot be meaningfully
-  larger than the warm-post path. If Sales Nav is offered for scale, it should
-  either project to the target good-fit count or clearly say it is too tight and
-  name the next broadening/Prospeo option.
-- If projected good-fit after cleanup is below 10%, do not recommend Sales Nav
-  as the winning source; recommend Prospeo as the next provider.
-- Never recommend "import 25 leads" as the Sales Nav source action. Recommend
-  Start Import for the approved source list; the parent thread later
-  copies the confirmed source rows into the campaign and internally uses the
-  first campaign-table execution slice for filter and message setup.
-- 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.