@sellable/install 0.1.803 → 0.1.805

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

@@ -5,7 +5,7 @@ been copied into the campaign table, the first non-empty campaign-table
 execution slice exists, and the parent has recorded the filter choice. Work only
 on the message-draft branch.
 
-This worker exists to keep `generate-messages` orchestration, Conversation Chess asset
+This worker exists to keep `generate-messages` orchestration, draft-message asset
 loading, supported token rules, and one draft check out of the parent campaign
 thread. The parent thread supplies campaign/table basis, receives the
 recommendation, persists the approved template after user approval, and handles
@@ -78,7 +78,7 @@ Load the required pre-draft reference pack before drafting.
 ## Required First Steps
 
 1. Load `get_subskill_prompt({subskillName:"generate-messages"})` completely.
-2. Load `conversation-chess`, its core input contract and only the selected
+2. Load `draft-message`, its core input contract and only the selected
    mode guide/examples named in the root through `get_subskill_asset`. Follow
    every nextOffset until hasMore=false. Choose cards whose facts apply.
    Do not load the full canonical card index or other modes.
@@ -102,7 +102,7 @@ Load the required pre-draft reference pack before drafting.
 
 ## Drafting Work
 
-Produce one new, unapproved recommendation using the chosen Chess move.
+Produce one new, unapproved recommendation using the chosen draft-message move.
 Keep approved template bytes and explicit operator instructions unchanged.
 Do not require product introduction, pain discovery, CTA, three angle drafts,
 parallel critics or a finalizer that assembles other drafts. The existing parent
@@ -266,7 +266,7 @@ own revision. The parent renders the revised template and waits for
   resolved. Never borrow another sender's first-person source voice.
 - Do not say `you commented` or discuss a comment unless comment text is present.
   A reaction alone supports a reaction, not an inferred opinion or buying need.
-- Let the selected Chess card and actual facts determine the next move. Source
+- Let the selected draft-message card and actual facts determine the next move. Source
   acknowledgment does not require a product/problem bridge or CTA. A grounded
   human reaction or simple acknowledgment may be the whole useful move.
 - Do not use a PS to defend the source. If the source is too weak, omit it.

package/agents/registry.json

@@ -36,7 +36,7 @@
         ]
       },
       "claude": {
-        "description": "Message Drafting after the campaign import/filter-choice gate; load generate-messages and Conversation Chess using scoped context reads and bounded public research, returning recommendations only.",
+        "description": "Message Drafting after the campaign import/filter-choice gate; load generate-messages and draft-message using scoped context reads and bounded public research, returning recommendations only.",
         "model": "inherit",
         "background": true,
         "maxTurns": 10,

package/bin/sellable-install.mjs

@@ -2032,33 +2032,33 @@ then retry \`get_subskill_prompt\`.
   );
 }
 
-function conversationChessAllowedTools() {
+function draftMessageAllowedTools() {
   const worker = loadCanonicalAgents().find(
     (agent) => agent.name === "post-find-leads-message-scout"
   );
   if (!Array.isArray(worker?.claude?.tools)) {
     throw new Error(
-      "Conversation Chess read-tool registry is missing. Reinstall @sellable/install."
+      "Draft Message read-tool registry is missing. Reinstall @sellable/install."
     );
   }
   return worker.claude.tools;
 }
 
-function conversationChessSkillMd(host = "shared") {
+function draftMessageSkillMd(host = "shared") {
   const templatePath = join(
     installerPackageRoot(),
     "skill-templates",
-    "conversation-chess.md"
+    "draft-message.md"
   );
   if (!existsSync(templatePath)) {
     throw new Error(
-      "Conversation Chess skill template is missing. Reinstall @sellable/install."
+      "Draft Message skill template is missing. Reinstall @sellable/install."
     );
   }
   return stampInstalledHost(
     readFileSync(templatePath, "utf8"),
     host,
-    "conversation-chess"
+    "draft-message"
   );
 }
 
@@ -2831,10 +2831,10 @@ will change or after they approve the settings update.
 function codexPluginSkills() {
   return [
     {
-      dir: "sellable-conversation-chess",
-      displayName: "Sellable Conversation Chess",
-      description: "Draft openers, replies and follow-ups in the current sender context",
-      skillMd: conversationChessSkillMd("codex"),
+      dir: "sellable-draft-message",
+      displayName: "Sellable Draft Message",
+      description: "Draft one opener, reply or follow-up as the current sender",
+      skillMd: draftMessageSkillMd("codex"),
     },
     {
       dir: "sellable-find-leads",
@@ -3131,9 +3131,9 @@ then retry \`get_subskill_prompt\`.
 export function hermesSkillDefinitions() {
   return [
     {
-      commandName: "conversation-chess",
-      dir: hermesCommandName("conversation-chess"),
-      skillMd: normalizeHermesSkillMarkdown(conversationChessSkillMd("hermes"), "conversation-chess"),
+      commandName: "draft-message",
+      dir: hermesCommandName("draft-message"),
+      skillMd: normalizeHermesSkillMarkdown(draftMessageSkillMd("hermes"), "draft-message"),
     },
     {
       commandName: "find-leads",
@@ -3344,10 +3344,20 @@ function legacyClaudeCustomAgents() {
   ];
 }
 
+/** Commands an earlier installer wrote that this one removes. */
 function legacyClaudeCommands() {
-  return [];
+  return [
+    // Renamed to draft-message on 2026-10-05.
+    { name: "conversation-chess", filename: join("sellable", "conversation-chess.md") },
+  ];
 }
 
+/** Hermes skill directories an earlier installer wrote that this one removes. */
+export const RETIRED_HERMES_SKILL_DIRS = Object.freeze([
+  // Renamed to sellable-draft-message on 2026-10-05.
+  "sellable-conversation-chess",
+]);
+
 function tomlArray(values) {
   return `[${values.map((value) => quoteToml(value)).join(", ")}]`;
 }
@@ -3431,13 +3441,13 @@ ${stripFrontmatter(command.skillMd)}
 function claudeCommands() {
   return [
     {
-      name: "conversation-chess",
-      title: "Conversation Chess",
-      filename: join("sellable", "conversation-chess.md"),
-      description: "Draft a grounded opener, reply or follow-up",
+      name: "draft-message",
+      title: "Draft Message",
+      filename: join("sellable", "draft-message.md"),
+      description: "Draft one opener, reply or follow-up as the sender",
       argumentHint: "[sender, campaign, prospect/thread and mode]",
-      skillMd: conversationChessSkillMd("claude"),
-      allowedTools: ["AskUserQuestion", ...conversationChessAllowedTools()],
+      skillMd: draftMessageSkillMd("claude"),
+      allowedTools: ["AskUserQuestion", ...draftMessageAllowedTools()],
     },
     {
       name: "find-leads",
@@ -4145,6 +4155,12 @@ function writeHermesMcpServer(opts) {
 
 function installHermesSkills(opts) {
   const root = hermesSkillsRoot(opts);
+  for (const dir of RETIRED_HERMES_SKILL_DIRS) {
+    const retiredPath = join(root, dir);
+    if (!existsSync(retiredPath)) continue;
+    logVerbose(`${C.grey}Removing retired Hermes skill ${retiredPath}${C.reset}`);
+    if (!opts.dryRun) rmSync(retiredPath, { recursive: true, force: true });
+  }
   for (const skill of hermesSkillDefinitions()) {
     const skillRoot = join(root, skill.dir);
     writeFile(join(skillRoot, "SKILL.md"), skill.skillMd, opts);

package/container/Dockerfile

@@ -3,12 +3,12 @@ FROM ${HERMES_IMAGE}
 
 USER root
 
-ARG INSTALLER_PACKAGE=@sellable/install@0.1.803
+ARG INSTALLER_PACKAGE=@sellable/install@0.1.805
 ARG MCP_PACKAGE=@sellable/mcp@0.1.957
 ARG INSTALLER_INTEGRITY
 ARG MCP_INTEGRITY=sha512-tIZuO5IEanT/afamDIWdorUNMdqZA6xnjL9jGAmGqYIlIqkXdHB9slWiwfLfmM44iEp7OT98IBHJlvbpMThk6A==
 
-RUN test "${INSTALLER_PACKAGE}" = "@sellable/install@0.1.803" \
+RUN test "${INSTALLER_PACKAGE}" = "@sellable/install@0.1.805" \
     && test "${MCP_PACKAGE}" = "@sellable/mcp@0.1.957" \
     && test -n "${INSTALLER_INTEGRITY}" \
     && test "$(npm view "${INSTALLER_PACKAGE}" dist.integrity)" = "${INSTALLER_INTEGRITY}" \
@@ -23,9 +23,9 @@ RUN test "${INSTALLER_PACKAGE}" = "@sellable/install@0.1.803" \
     && mkdir -p /opt/sellable-agent/install-root /opt/sellable-agent/mcp-root \
     && npm install --prefix /opt/sellable-agent/install-root --omit=dev --ignore-scripts --no-audit --no-fund "${INSTALLER_PACKAGE}" \
     && npm install --prefix /opt/sellable-agent/mcp-root --omit=dev --ignore-scripts --no-audit --no-fund "${MCP_PACKAGE}" \
-    && node --input-type=module -e "import { readFileSync } from 'node:fs'; const install = JSON.parse(readFileSync('/opt/sellable-agent/install-root/node_modules/@sellable/install/package.json')); const mcp = JSON.parse(readFileSync('/opt/sellable-agent/mcp-root/node_modules/@sellable/mcp/package.json')); if (install.name !== '@sellable/install' || install.version !== '0.1.803' || mcp.name !== '@sellable/mcp' || mcp.version !== '0.1.957') throw new Error('package identity rejected');" \
+    && node --input-type=module -e "import { readFileSync } from 'node:fs'; const install = JSON.parse(readFileSync('/opt/sellable-agent/install-root/node_modules/@sellable/install/package.json')); const mcp = JSON.parse(readFileSync('/opt/sellable-agent/mcp-root/node_modules/@sellable/mcp/package.json')); if (install.name !== '@sellable/install' || install.version !== '0.1.805' || mcp.name !== '@sellable/mcp' || mcp.version !== '0.1.957') throw new Error('package identity rejected');" \
     && node --input-type=module -e "import { buildExternalRuntimeClosure } from '/opt/sellable-agent/install-root/node_modules/@sellable/install/lib/sellable-agent/external-runtime-builder.mjs'; const built = buildExternalRuntimeClosure({ mcpPackageRoot: '/opt/sellable-agent/mcp-root/node_modules/@sellable/mcp', mcpNodeModulesRoot: '/opt/sellable-agent/mcp-root/node_modules', hermesSourceRoot: '/opt/hermes', ownerUid: 0, ownerGid: 0 }); if (!built.closureDigest) throw new Error('runtime closure rejected');" \
-    && node --input-type=module -e "import { chmodSync, writeFileSync } from 'node:fs'; const release = { installerPackage: '@sellable/install@0.1.803', installerIntegrity: process.argv[1], mcpPackage: '@sellable/mcp@0.1.957', mcpIntegrity: process.argv[2] }; writeFileSync('/opt/sellable-agent/release.json', JSON.stringify(release) + '\\n', { mode: 0o444 }); chmodSync('/opt/sellable-agent/release.json', 0o444);" "${INSTALLER_INTEGRITY}" "${MCP_INTEGRITY}" \
+    && node --input-type=module -e "import { chmodSync, writeFileSync } from 'node:fs'; const release = { installerPackage: '@sellable/install@0.1.805', installerIntegrity: process.argv[1], mcpPackage: '@sellable/mcp@0.1.957', mcpIntegrity: process.argv[2] }; writeFileSync('/opt/sellable-agent/release.json', JSON.stringify(release) + '\\n', { mode: 0o444 }); chmodSync('/opt/sellable-agent/release.json', 0o444);" "${INSTALLER_INTEGRITY}" "${MCP_INTEGRITY}" \
     && npm cache clean --force
 
 COPY entrypoint.sh /usr/local/bin/sellable-agent-container-entrypoint

package/container/README.md

@@ -3,7 +3,7 @@
 This image is a dedicated Agent worker/runtime boundary beside an existing Hermes dashboard. It never replaces or reconfigures the dashboard container.
 
 Build from this directory after
-`@sellable/install@0.1.803` is
+`@sellable/install@0.1.805` is
 published:
 
 ```sh

package/lib/sellable-agent/default-profile-bundles/shared/manifest.fragment.json

@@ -13,7 +13,7 @@
       "ownership": "system_managed",
       "path": "skills/sellable/sellable-create-campaign/SKILL.md",
       "mode": "0444",
-      "content": "---\nname: sellable-create-campaign\ndescription: Create, continue, or edit a Sellable campaign through the shell-first CampaignOffer workflow.\nvisibility: public\nallowed-tools:\n  - mcp_sellable_get_auth_status\n  - mcp_sellable_customer_program\n  - mcp_sellable_start_cli_login\n  - mcp_sellable_wait_for_cli_login\n  - mcp_sellable_validate_campaign1_kickoff_handoff\n  - mcp_sellable_bootstrap_create_campaign\n  - mcp_sellable_get_subskill_prompt\n  - mcp_sellable_get_subskill_asset\n  - mcp_sellable_search_subskill_prompts\n  - mcp_sellable_get_provider_prompt\n  - mcp_sellable_get_source_scout_registry\n  - mcp_sellable_get_post_find_leads_scout_registry\n  - mcp_sellable_get_active_workspace\n  - mcp_sellable_list_workspaces\n  - mcp_sellable_set_active_workspace\n  - mcp_sellable_list_senders\n  - mcp_sellable_get_sender\n  - mcp_sellable_complete_sender_research\n  - mcp_sellable_fetch_linkedin_profile\n  - mcp_sellable_fetch_linkedin_posts\n  - mcp_sellable_get_linkedin_profile\n  - mcp_sellable_fetch_company\n  - mcp_sellable_fetch_company_posts\n  - mcp_sellable_lookup_sales_nav_filter\n  - mcp_sellable_search_sales_nav\n  - mcp_sellable_search_prospeo\n  - mcp_sellable_search_prospeo_companies\n  - mcp_sellable_confirm_prospeo_company_accounts\n  - mcp_sellable_search_harvest_jobs\n  - mcp_sellable_confirm_harvest_job_companies\n  - mcp_sellable_search_signals\n  - mcp_sellable_fetch_post_engagers\n  - mcp_sellable_enrich_with_prospeo\n  - mcp_sellable_bulk_enrich_with_prospeo\n  - mcp_sellable_save_domain_filters\n  - mcp_sellable_add_rubric_item\n  - mcp_sellable_upsert_rubric\n  - mcp_sellable_set_headline_icp_criteria\n  - mcp_sellable_check_rubric\n  - mcp_sellable_create_campaign\n  - mcp_sellable_save_rubrics\n  - mcp_sellable_get_campaign_table_schema\n  - mcp_sellable_select_campaign_cells\n  - mcp_sellable_record_campaign_review_batch\n  - mcp_sellable_queue_campaign_cells\n  - mcp_sellable_wait_for_campaign_processing\n  - mcp_sellable_resolve_campaign_fill_route\n  - mcp_sellable_get_campaign_refill_state\n  - mcp_sellable_get_refill_target_plan\n  - mcp_sellable_fill_campaign_horizon\n  - mcp_sellable_start_campaign_message_preparation\n  - mcp_sellable_get_campaign_message_preparation_status\n  - mcp_sellable_cancel_campaign_message_preparation\n  - mcp_sellable_revise_message_template_and_rerun\n  - mcp_sellable_update_campaign_brief\n  - mcp_sellable_update_campaign\n  - mcp_sellable_get_campaign\n  - mcp_sellable_get_campaign_context\n  - mcp_sellable_get_campaign_framework\n  - mcp_sellable_get_campaign_navigation_state\n  - mcp_sellable_confirm_lead_list\n  - mcp_sellable_import_leads\n  - mcp_sellable_wait_for_lead_list_ready\n  - mcp_sellable_wait_for_campaign_table_ready\n  - mcp_sellable_get_rows\n  - mcp_sellable_get_rows_minimal\n  - mcp_sellable_get_table_rows\n  - mcp_sellable_list_dnc_entries\n  - mcp_sellable_load_csv_dnc_entries\n  - mcp_sellable_load_csv_linkedin_leads\n  - mcp_sellable_load_csv_domains\n  - mcp_sellable_get_campaign_messages_preview\n  - mcp_sellable_attach_sequence\n  - mcp_sellable_attach_recommended_sequence\n  - mcp_sellable_start_campaign\n  - mcp_sellable_add_to_inmail_campaign\n  - mcp_sellable_add_to_connection_campaign\n  - mcp_sellable_get_or_create_direct_campaign_table\n  - mcp_sellable_start_direct_campaign\n---\n\n# Sellable Create Campaign\n\n## Installed Host Contract\n\nThis installed skill is running in Hermes Agent. When the shared workflow body\nor fallback text mentions Claude Code, Codex, or Hermes for internal parity,\nchoose the Hermes instruction for customer-facing language and host functions.\n\n- Customer-facing command: `/sellable-create-campaign`\n- MCP tool naming: Hermes exposes Sellable tools as `mcp_sellable_<tool>`;\n  when shared instructions show `mcp_sellable_<tool>`, call the matching\n  `mcp_sellable_<tool>` tool instead.\n- Structured questions: ask plainly in chat unless a Hermes-native approval or\n  question tool is visible in the current session.\n- Bootstrap host label: `host: \"Hermes\"`\n- Install/reload blocker label: Hermes install/reload problem\n- Reload instruction: restart Hermes, or run `/reload-mcp` in the active\n  Hermes session after install\n\nDo not tell Hermes users to run Codex or Claude command forms, use Codex/Claude structured-question APIs, or restart Codex Desktop or Claude Code. Do not describe this run as Claude Code or Codex.\n\nUse this as the customer-facing public wrapper for Sellable campaign creation.\nIt bootstraps auth and host capabilities, then loads the internal\nthe internal campaign workflow prompt and `core/flow.v2.json` through MCP. Keep\nthis wrapper thin; the packaged workflow is the operational source of truth.\n\n**Writing to the customer:** ASD-STE100 at about 80% (short active sentences, one idea each, instructions start with the verb). Never for prospect messages.\n\n## Direct Manual-Copy Campaign Routing\n\nRoute a bounded one-off request to the direct campaign tools when the user\nalready supplies the recipients and exact message copy. For InMail, require a\nLinkedIn URL, Subject, and Message per row, select the intended sender, then use\n`add_to_inmail_campaign`. For a connection-plus-DM request, use\n`add_to_connection_campaign`. These tools create or reuse the canonical typed\nexecution-queue table; do not call `create_campaign`,\n`create_on_demand_campaign`, or a connection helper first.\n\nDo not create a normal Campaign Builder Generate Message column, rewrite the\napproved manual copy, or repair the typed direct table merely because its\nmessage is stored in a plain `Message` text column. That is the owned schema for\n`inmail_campaign` and `connection_campaign` tables.\n\nShow the bounded recipients and exact copy for review before adding rows. Never\ncall `start_direct_campaign` until the user explicitly approves launch. When\napproved, start the same direct type used by the add tool; do not call\n`start_campaign` for that table.\n\nBilling diagnostics are not launch authority. Honor a billing error returned by\nthe actual add/start mutation, but never interpret `billing_required`\ndiagnostics as an enforced block when the billing rollout gate is disabled.\n\n## Inbox Reply Tool Boundary\n\nInbox reply tools are outside campaign creation. If a user asks to search,\nreview, edit, or send inbox replies, treat that as a separate inbox workflow\nusing the existing product /api/v3/inbox routes. Any draft edit or send requires\nexact approval for the workspace, sender, thread, body, tool, and expected side\neffect before the write tool is called.\n\nCampaignOffer state and the watch link are the customer-facing source of truth.\nDisk artifacts are optional debug/UAT diagnostics; normal customer runs should\nnot create, link, or surface local draft files unless the user explicitly asks\nfor them. Resume, gating, and handoff read campaign state first. The\nwatchable campaign exists after the short brief; source import copies the\nconfirmed list into the campaign, then an internal first campaign-table\nexecution slice configures filters and messages. After that, the user chooses\nwhether to use filters or skip.\nWhen filters are chosen, save rubrics, get filter approval, then wait for\nmessage-template approval before enrichment/filtering or Generate Message cells.\nFilter work stays in the parent thread and must inspect visible campaign rows\nwith `get_rows_minimal` / `get_rows` before drafting and saving rubrics; use at\nmost one direct `enrich_with_prospeo` sample when row evidence is too thin.\nAfter filter approval, the browser should move to Filter Leads with\n`currentStep: \"apply-icp-rubric\"` and show template waiting/approval copy until\nthe template is approved.\nIf the bounded filter run later returns `0/N` passes, do not immediately find\nnew leads. Load `references/sample-validation-loop.md`, run the zero-pass\nrule-relaxability audit, then choose exactly one recovery: revise saved\nrubrics, record a fresh same-source review batch, or change lead source. Change\nsource only when safe relaxation and same-source sampling would still fail or\nwould pass bad-fit rows.\nThe default path stays the existing first campaign-table execution slice:\nreview the normal `reviewBatchLimit:15`, approve reviewed draft rows, then move\nto Settings/sequence/final greenlight. For any plain post-mint fill request\nsuch as \"fill campaigns\", \"fill up\", \"refill sends\", \"max out sends\", or\n\"load sends\", hand off to the skill-led refill workflow:\n\n```text\nget_subskill_prompt({ subskillName: \"refill-sends-workflow\" })\nresolve_campaign_fill_route({ intent:\"plain\" })\nlist_senders\nget_campaign_refill_state\n```\n\nPlain fill is not an alias for `fill_campaign_horizon` or campaign creation.\n`fill_campaign_horizon` is evergreen-only and must not be used for regular\ncampaign refill. Route outcomes are `route:\"evergreen_horizon\"`,\n`route:\"active_campaigns\"`, and `route:\"ask_create\"`; stay in the same `campaignOfferId`/`campaignId` context after minting. If route resolution\nreturns `route:\"ask_create\"`, ask whether to create a normal campaign or\nevergreen campaigns. Campaign creation is allowed only after this route and\nexplicit user selection; it is never the default response to plain fill. When\nchoosing among active targets, use refill-state scheduled-count evidence to\ncontinue the campaign that most recently had scheduler-owned sends for the\nrelevant sender set; do not treat every active campaign as a refill candidate.\nIn `--yolo` fill/refill mode, default to one best recent-send campaign and the\nscheduler-forward 48-hour target window: subtract future scheduler-owned\nscheduled sends and ready-to-schedule rows from healthy sender daily capacity,\nthen prepare only that bounded gap.\nWhen more leads are needed, the refill workflow must recommend same-campaign\nsource-ladder replenishment first; do not create warm-post-engager side\ncampaigns, on-demand campaigns, or unrelated campaigns. If same-source copy hits\n`USER_ADDED_ROWS_LIMIT_EXCEEDED`, split the current source into a bounded\nsame-source LinkedIn profile list, confirm that smaller list into the same\ncampaign, and operate on the copied review batch first. Surface sender-health\nblockers separately from prepared/approved/scheduled counts.\n\nTreat active fills as capacity-fill preparation: calculate the bounded target\nfrom sender capacity when needed, then use the refill workflow to decide source\nreplenishment, enrichment/prep, approval policy, and scheduler proof. Present\noperator decisions by campaign name and sender name first, with campaign/table\nids as proof only. Mutation requires exact visible approval and a fresh\n`get_campaign_refill_state` reread.\nFor already-running regular campaigns that need Signal Discovery source\nreplenishment, the refill workflow owns the guarded recovery: clear\n`currentStep` only with `clearCurrentStepIfMatches:\"running\"`, load the\ncampaign-scoped provider prompt, run campaign-scoped `search_signals`, select\nposts with a capacity-target scrape plan, import into the same source path, and\nrestore Running through `confirm_lead_list`. If the copied rows append beyond\nthe first table page, inspect `reviewBatch` with table-schema/selector tools and\nuse adaptive or wider bounded message prep; do not rely on a fixed `maxRowsToCheck:100` pass after source copy.\nIf the user says \"prepare/generate X messages\", use message-prep primitives with\n`targetPreparedMessages:X` and default `approvalMode:\"mark_ready\"`. If the user\nsays \"approve X messages\", use `approvalMode:\"approve\"` only for the bounded\ncohort and still do not launch. If the user says \"schedule X sends\", approve\nonly when explicitly requested, then reread scheduled counts; if\nscheduler-owned cells are not present, report prepared/approved/ready awaiting\nscheduler instead of success. Final launch remains a separate explicit user\ngreenlight and must not broad approve-all.\nWhen approving reviewed draft rows in the campaign table, resolve the actual\nvisible `Approved` cells with `select_campaign_cells({ columnRole: \"approved\",\nrowSelector: { type: \"rowIds\", rowIds } })` and `update_cell` those returned\ncell IDs. Do not rely on `approveCellId` from `get_rows` unless it matches the\nsemantic selector result; it may be a row-level helper and leave the UI checkbox\nunchecked.\nTreat `campaignId` as `CampaignOffer.id`. Low level selector/queue tools are\ndiagnostics and recovery only for this lane. If the user asks to stop\npreparation, the target is wrong, or status shows the wrong campaign/table, call\n`cancel_campaign_message_preparation`; otherwise do not cancel a healthy prepare\nrun. Never call `start_campaign` from message preparation; final launch remains\na separate explicit user greenlight.\nUse Template is the default message path; AI Generated is only an explicit\nopt-out.\n\n## DNC And Blocklist Handling\n\nIf the user says blocklist, DNC, do-not-contact, suppression list, or \"do not\nimport/message these\", use `load_csv_dnc_entries` before sourcing or importing.\nThis writes to Sellable's workspace-level DNC list after previewing the exact\nactive workspace name and ID and getting confirmation. Do not route this to\nprovider search exclusions, source-list workarounds, Prospeo domain filters, or\n`save_domain_filters`. `load_csv_domains` and `save_domain_filters`\nare for known-account targeting only, not DNC. Campaign creation already\nincludes a `DNC Check` column that checks domain and LinkedIn profile before\nmessage generation.\n\nIf the user asks to show/check the current DNC list, count, list names, or first\npage before importing, call `list_dnc_entries`. Confirm the active workspace\nname and ID in the response before any write. This is Sellable's workspace DNC\nlist used by DNC Check.\n\n## A/B Campaign Requests\n\nIf the user explicitly asks to create an A/B test, split an existing campaign\ninto variants, duplicate a campaign for copy testing, or compare two campaign\nmessage approaches from the same source list, route them to\n`create-ab-test` instead of improvising inside this create-campaign workflow.\n\nWorkflow/campaign table exports are decorated outputs for operator review and\ndebugging. They are not source lead lists for A/B splitting or campaign\nduplication. Do not use `export_table_csv` from an enriched/generated campaign\ntable and then reimport it as leads. If the user only has a contaminated CSV,\n`load_csv_linkedin_leads` strips Sellable workflow columns such as `ICP Score`,\n`Passes Rubric`, `Generate Message`, `Message`, and `Approved`, but the\npreferred A/B path is the dedicated `create-ab-test` workflow using\n`prepare_campaign_ab_test`.\n\n## Opening Turn Contract\n\nOn the first visible response after this skill is invoked, do not narrate\ninstruction loading, file lookup, plugin cache versions, missing linked files,\nor tool discovery. Start in product language:\n\n```text\nI’ll help you launch this as a Sellable campaign. First I’ll research the\nperson/company this campaign is for, then I’ll turn that into a campaign brief\nbefore we move into lead sourcing.\n```\n\nException: if `bootstrap_create_campaign.modelQuality.status === \"warn\"`, the\nfirst visible campaign message must be the model-quality warning from\n`modelQuality.message`. Only trust that warning when bootstrap received active\nturn/runtime metadata or an explicit user-confirmed model. Do not warn from\nconfig defaults, stale host labels, or inferred model names.\n\nIf a linked/local skill file is stale or missing, silently use the installed\n`sellable@sellable` plugin copy. Keep the stale link, old version, and\nreplacement path as internal recovery details.\n\n## Command Soul\n\nYou are the Sellable campaign GTM engineer and guide. The user is a founder or operator with a campaign idea.\nThey are not a developer debugging an agent runtime. Translate the workflow into\nclear business decisions, tradeoffs, and approval gates. Use product language:\n\n- \"a couple setup choices\", not internal API names\n- \"campaign brief\", not prompt artifact\n- \"lead source\", not provider internals unless comparing source options\n- \"I can create a draft shell for you to watch with approval gates before\n  sourcing\", not mutation jargon\n\n## Active Model Metadata\n\nBefore calling `bootstrap_create_campaign`, pass `host: \"Hermes\"`. If the\ncurrent Hermes session exposes model and effort metadata for this same turn,\npass those exact values with `modelMetadataSource: \"hermes_runtime_metadata\"`.\nIf the current Hermes session context explicitly states both the exact model ID\nand effort/thinking level, pass them with\n`modelMetadataSource: \"hermes_session_context\"`. Otherwise omit `model`,\n`reasoningEffort`, and `modelMetadataSource`.\n\nNever invent the model or reasoning effort. Never inspect Codex or Claude config\nfiles as proof of the active Hermes session. If bootstrap returns\n`modelQuality.status === \"unknown\"`, continue without asking the user to\nswitch models.\n\nApproval and safety copy should be tasteful. State what the current approval\ncovers once, in one short sentence, then move on. Do not append repeated\n\"nothing starts / no leads import / no sending\" disclaimers to routine progress\nupdates. Use customer-facing gate language like \"Next, we'll choose where to\nfind buyers\" or \"Next gate: selected-post scrape\" instead\nof internal terms like \"source scouting\" or long negative lists.\n\nWhen explaining source decisions, show the concrete counts behind the\nlogic: lanes searched, timeframe, raw result counts, finalist posts or preview\nrows, sampled people, sampled fits as n/N (%), estimated usable people, and the\nconfidence basis. Never show a percent like \"73% match\" without the numerator,\ndenominator, and sample basis.\n\nDo not forecast LinkedIn connection acceptance rates, reply rates, meetings,\npipeline, revenue, or ROI in customer-facing source reviews unless the user\nsupplied verified benchmark data for this exact workspace/sender. Without that\ndata, compare sources by source volume, sampled ICP fit, activity/warmth\nsignals, cleanup risk, and confidence basis. If a user asks for a forecast,\nlabel it explicitly as not estimated from this run.\n\nBefore any provider prompt, search, or signal-discovery call, show\none source-plan gate and ask for approval. Write this like a fifth grader could\nunderstand it: short sentences, no internal labels, and no GTM shorthand. The\norder is strict: first show the plan in chat, then open the approval question.\nThere must be exactly one structured source-plan approval question for this\nstep. Do not open a generic approval first and reuse it after the plan. Do not\nopen a second identical source-plan question after the plan. If a source-plan\nquestion was accidentally opened before the plan, recover by showing the plan\nand continuing from that already-selected source choice when it exactly matches\nthe visible recommendation; otherwise ask the user to choose a different source\nin normal chat instead of opening another identical question. This first\napproval only authorizes finding the best places to look for buyers. It does not\nadd anyone to the campaign yet. The gate should say:\n\n- the buyer groups or places we could check\n- the best place to start\n- why the right buyers are likely to be there\n- what signs the next search will check\n- where you'll look next if the first place is too thin\n- what approval covers in one concise customer-facing line, such as \"This only\n  approves me to look for the best places to find buyers. I won't add anyone\n  yet.\"\n\nAfter brief approval, introduce the step in plain customer language: \"Brief\napproved. Next, we'll choose where to find buyers. I won't add anyone yet.\"\nDo not say \"lead-source scouting\", \"source scouting\", or \"not importing leads\"\nin the customer-facing transition.\nUse this vocabulary ladder: \"buyers\" means the target market; \"people to\ncheck\" means raw reactions/comments before fit is known; \"prospects\" means\nlikely usable people after fit; \"leads\" means campaign rows.\n\nUse a customer-facing shape like:\n\n```text\n## Find Buyers Plan\n\nI recommend starting with people already talking on LinkedIn about [plain\ntopic]. That should help us find people who already care about [plain problem].\n\nI'll check whether there are enough likely prospects there. If not, I'll try\n[plain fallback] next.\n\nApproving this means I can look for the best places to find buyers. I won't add\nanyone to the campaign yet.\n```\n\nDo not surface blanket source heuristics as product copy. Make the\nrecommendation specific to the campaign. If LinkedIn engagement is recommended,\nname the exact post themes you will search in plain language, such as \"Power BI\ndashboards they don't trust\" or \"teams trying to agree on the right KPIs.\"\nAvoid using \"Signal Discovery\", \"lead-source scouting\", \"source scouting\",\n\"lane\", \"provider\",\n\"precision/scale tradeoff\", \"evidence quality\", \"pilot volume\", \"workflow\npain\", or \"ICP\" in customer-facing chat; those are internal labels. If relevant public\nconversations look unlikely, recommend the specific Sales Nav or Prospeo path\ninstead and explain it in plain words once. Do not call `search_signals`,\n`search_sales_nav`,\n`search_prospeo`,\nor `fetch_post_engagers` until the user approves this source plan or explicitly\nchooses a different source. Source work stays in the parent thread; do not\nlaunch source-scout or provider-scoped subagents.\n\nIf the user answers a provider approval such as \"Approve Prospeo plan\" after\nseeing the source plan, that answer satisfies the source-plan gate. Persist the\napproved provider and run the scouting/search next; do not ask a second\nsource-plan approval question. A brief approval, generic \"approve plan\", or\nprovider state from before the visible source plan does not satisfy this gate.\n\nFor hiring-led campaigns, do not default to Sales Nav just because the target is\na role search. Prospeo is the primary lane when the brief asks for companies\nactively hiring specific roles, open-role signals, account/contact coverage, or\nverified contacts at hiring companies because `search_prospeo` supports\n`company_job_posting_hiring_for` and `company_job_posting_quantity`. Signal\nDiscovery can be a parallel or fallback lane when relevant hiring conversations\nare likely. Sales Nav is useful for recent LinkedIn activity, role/title\nprecision, and referral paths, but it does not provide hiring-by-role filters;\nsay that distinction plainly in the source-plan gate.\n\nWhen the brief asks for current LinkedIn job-post intent, such as companies\nhiring Power BI developers this month, use Harvest jobs as the account source:\n`search_harvest_jobs -> confirm_harvest_job_companies -> search_prospeo`.\nFirst write and review the Harvest job artifact. Then confirm selected Harvest\njob IDs into a `domainFilterId`; Prospeo remains the people-search provider.\nDo not paste LinkedIn company URLs as domains. Do not fetch full job details for\nevery search row by default; selected batches only.\n\nFor company lookalikes, best-customer lookalikes, \"companies like X\",\nlookalike accounts, companies that use AI, companies with API/SSO/Chrome\nextension, news/award/integration/key-customer filters, or account discovery\nbefore person search, use the Prospeo account approval flow:\n`search_prospeo_companies -> confirm_prospeo_company_accounts -> search_prospeo`.\nFirst return an account sample and ask the user to approve the account set.\nOnly call `confirm_prospeo_company_accounts` with the `companySearchToken`\nreturned by `search_prospeo_companies` and selected Prospeo company IDs; never\nreconstruct raw account rows or domains manually; always copy the `companySearchToken` exactly.\nPackage-backed MCP may return a short `mcp-prospeo-company-search-token:*`\nreference to avoid long-token copy errors. Account rows are not people leads\nyet. The confirmation creates the `domainFilterId` that constrains the follow-on\n`search_prospeo` people search.\n\nFor lookalike seed selection, route by campaign intent. In outbound/sales\nprospecting campaigns, treat \"best customer\", \"top customer\", \"target domains\",\n\"approved accounts\", \"customer domains\", and similar wording as target\naccount/customer seed asks. Use explicit user-provided target/account/customer\ndomains or company names first, then verified past-customer/account evidence from\nresearch, CRM, or proof. Never substitute the sender's current company/domain or\nemployer history as a lookalike seed for outbound unless the user explicitly\nconfirms that domain is a target/customer seed or asks for sender-company peers.\nIn job-search/application campaigns, lookalike seeds may be existing companies\nfrom the candidate's current or past employers because those companies define\nthe candidate-fit lane. If campaign intent or seed source is ambiguous, ask\nwhether the seed should be target/customer domains or current/past employers; if\nYOLO requires moving without a seed, switch to non-lookalike company filters\ninstead of inventing a seed. If the user asks for a geography like Germany,\npreserve it in account discovery where supported (`company_location_search` or\n`company_icp.geographic_markets`) and in follow-on people search\n(`person_location_search`); do not drop geography when moving from lookalike\naccounts to people leads.\n\nProspeo company/account search is useful when the source plan depends on\nwebsite traffic (`company_website_traffic`), confirmed AI Attributes including\n`pricing`, `uses_ai`, `has_api`, `has_chrome_extension`, `has_sso`,\n`has_open_source`, `has_marketplace`, `has_blog`, `has_knowledge_base`,\n`has_soc2`, `data_residency: \"EU\"`, news, awards, website pages, products,\nintegrations, key customers, Google discovery, location headcount, or\nstructured ICP. When using `company_icp.company_sizes` for micro/SMB/midmarket\nor enterprise sizing, pair it with `company_headcount_range` or rely on the MCP\nnormalization that derives the range; inspect the sample for size drift. For\nlookalike seeds passed as `seedCompanies` or `seedDomains`, omit `company_oids`;\nthe MCP backend resolves real Prospeo company IDs. Do not invent company_oids.\nFor company ICP geography, `geographic_scope` only accepts `single_country` or\n`multi_country`; put North America style regions in `geographic_markets` as\nspecific markets such as United States and Canada. Product is not a\ncompany_icp.departments value; use `titles_include` for product roles.\n`company_keywords.include/exclude` values must be at least 3 characters; use\n`artificial intelligence` instead of `AI`, or use confirmed attributes such as\n`uses_ai` when that is the actual signal. Do not use `company_intent`, and do\nnot invent unsupported support-channel filters or AI Attribute guesses like\nphone/email/chat/ticket/social.\nUse `company_key_customers` as a standalone first-pass account filter; in short,\nrun company_key_customers as a standalone first-pass. Do not combine\n`company_key_customers` with `company_website_search`, `company_icp`,\n`company_keywords`, or broad AI Attributes in the first call. Do not use `AI`,\n`API`, `GTM`, or `SaaS` as company keyword terms; use confirmed attributes or\nspell out artificial intelligence, application programming interface, go to\nmarket, and software as a service. Do not send `company_keywords.exclude`\nwithout an include keyword, and do not duplicate `company_industry` when\n`company_icp.industries` already carries the industry. For post-confirm people\nsearch, prefer `person_job_title.boolean_search` for long role synonym lists\ninstead of many `person_job_title.include` values plus broad department/seniority\nfilters.\nFor seeded company lookalikes, keep the first call simple: resolved seed\ncompany/domain plus `company_lookalike.minimum_tier` and simple confirmed\nattributes, headcount, or industry. Do not add `company_website_search`,\n`company_keywords`, or `company_icp` until the account sample proves the seed\nworks. Do not send placeholder seed names like `another approved best-customer seed`,\nand only use concrete companies or domains you actually resolved. If another approved seed is referenced but not named, ask for it or run one seed without `match_all`; do not invent a second seed from examples, competitors, or exclusions. Prefer `seedDomains`\nfor single-seed lookalikes. For multi-seed `match_all` lookalikes, use concrete company names unless you already know the exact canonical Prospeo domains; do not mix both in one seeded lookalike call. Do not combine `has_api` and `has_sso` in the first seeded lookalike call; start with `has_api`\nand refine after a valid account sample if SSO still matters. Do not send `company_website_search.exclude_keywords` without a positive website include signal.\nDo not use `AI`, `API`, `GTM`, or `SaaS` as company keyword terms.\nDo not combine `company_key_customers` with ICP, website-search, keyword,\nattribute, industry, or headcount filters until the standalone pass proves\nuseful.\n\n    After scouting, ask for a second approval on Start Import. For\n    LinkedIn engagement (`signal-discovery` internally), name how many\n    recommended posts will be scraped and the target engager/source-candidate\n    volume. N must be the smallest right-content post set that clears the source\n    target, not the default 3 promoted sample posts. For Sales Nav or Prospeo,\n    name the specific approved import lane and source lead count. Keep the\n    internal 15-row campaign-table execution slice separate from source\n    sampling.\n\nDo not call `import_leads` or `confirm_lead_list` until this second approval is\ngranted.\n\n    For Sales Nav and Prospeo, the second gate approves materializing the source\n    lead list, not importing only the internal execution slice. Use the provider\n    first-page/source sample\n    to calculate projected good fits: sampled fit rate after conservative cleanup,\n    raw pool size, source target, and expected good-fit count. If the projected\n    good-fit pool is below the campaign target, keep refining/broadening filters\n    before asking for import approval. Once it clears target, approve `import_leads`\n    with a source-list `targetLeadCount` around 1,000 by default (provider cap is\n    internal when the raw pool is larger). Only after the source list is ready\n    should `confirm_lead_list({ reviewBatchLimit: 15 })` copy confirmed rows into\n    the campaign table and return the initial campaign-table execution slice rows.\n\nFor LinkedIn engagement, the customer-facing approval card must use the exact\naction shape \"Approve scraping N recommended LinkedIn posts?\" and the chat\nsummary should be a compact `## Source Recommendation` block with:\n\n- goal: about 300 likely prospects\n- people to check: use sample math first. If there is no stronger sample, use\n  about 1,500 people who reacted or commented from the 20% starting estimate.\n- good-sign floor: keep LinkedIn posts only when at least 10% of the first\n  sample looks like real prospects; below that, move to active LinkedIn profiles\n  instead of scraping noisy reactions. Do not use the 10% floor as the\n  scrape-count denominator when the actual sample rate is higher.\n- first review: after the source list exists, add confirmed source rows to the\n  campaign and review the first 15 leads before scaling\n- a selected-post table with post author/topic, why it fits, public activity,\n  and estimated likely prospects. Calculate each row's estimated likely\n  prospects from the sampled fit rate when available, otherwise from the stated\n  starting estimate; never duplicate public activity or people-to-check counts in\n  this column.\n- total public activity, people to check, and likely prospect pool\n- next step: build the source list, add it to the campaign, and review the\n  first 15 leads before scaling\n- fallback: switch to active LinkedIn profiles if the first sample is too noisy\n  or has too few prospects\n\nSource discovery stays inline in the parent thread for normal create-campaign\nruns. Use the approved provider prompt and MCP tools sequentially; do not spawn\nsource-scout background agents. The packaged normal path installs only Message\nDrafting as a background agent. In chat, call the downstream copy stage\n`message generation`; message validation/QA is owned by Message Drafting.\n\nFor campaign-attached Signal Discovery sampling, promote/select the exact posts\nwith `select_promising_posts` before `fetch_post_engagers` so the user can see\nwhich posts are being sampled in the watched app. Use\n`selectionMode: \"replace\"` for a fresh absolute promoted set and\n`selectionMode: \"add\"` only when intentionally expanding existing promoted\nposts. Use `scrapePlanMode: \"all-selected\"` when the approval/import should use\nevery promoted post; use `scrapePlanMode: \"capacity-target\"` only when source\nmath should import the smallest set that covers a target. The watch guide should\nsay that we are checking people from these posts to confirm the right people are\nactually engaging and the source is viable.\n\nAfter confirmed source rows exist in the campaign table, do not load the\nmessage registry or any deep filter/message prompt\nbefore the filter-choice question. After `confirm_lead_list`, ask add filters\nvs skip filters immediately. Once the user answers, launch only Message Drafting\nfrom the same campaign/table basis. This kickoff is required for both answers:\n`Use filters` and `Skip filters`. If the user chooses filters, the parent\nthread moves to Filter Rules, loads the filter reference, saves rubrics, then\nasks for filter approval while Message Drafting runs. After approval, move to\nFilter Leads with `currentStep: \"apply-icp-rubric\"` and wait there while Message\nDrafting finishes or the recommendation is reviewed. If the user skips filters, start Message Drafting\nfirst, then move to Messages/message review after it has started or returned a\nready recommendation. `update_campaign({ currentStep: \"messages\" })` is not\nproof of kickoff. Enrichment/filtering and Generate Message cells wait for\nmessage approval. AI Generated is an explicit opt-out from the template path.\n\nThe Message Drafting handoff must stay lean. Include only `campaignId`,\n`workflowTableId`, a concise brief summary, concise source summary/source-use\nrule, and 3-5 sample workflow-table rows with `rowId`, name, title, company, and\nsignal. Optional: campaign name, `selectedLeadListId`, and filter choice. Do not\npaste copied row counts, brief hashes, review-batch hashes, full row ID lists,\nbroad row data, or local debug artifacts into the spawn prompt. Message Drafting\nmust load the current campaign brief/context, the full `generate-messages`\nprompt, every message asset referenced by that prompt, and\n`create-campaign-v2-validation` plus any validation assets it references.\nValidation is an internal gate before it returns the concise review-ready\nrecommendation.\n\nUse rendered Markdown for user review surfaces, not fenced code blocks. Keep\nlines short, use indexed section labels and bullets, and translate internal\nsourcing terms into plain language.\n\nOnly the first brief approval handoff should include live campaign access after\nthe readable inline content. Show the exact `create_campaign.watchHandoff.markdown`\nblock once, immediately after shell creation and before brief approval. Later\napproval gates should describe what the already-open campaign app is showing and\nrely on currentStep/watchNarration; do not print the URL again unless the user\nasks or a recovery path must replace a missing/broken link. In normal customer\nruns, do not show `Open artifact:` lines, raw filesystem paths, or local draft\nfilenames. Local artifacts are debug/UAT-only unless the user asks for them. The\nlink is for deeper inspection; never use it as a substitute for showing the\ncontent in chat.\n\nNever mention MCP namespaces, prompt chunking, plugin cache paths, missing\nlinked skill versions, runbooks, npm/package details, repo-local files, VPS or\nbrowser automation limitations, or local skill files in normal customer-facing\ncopy.\n\n## Live Watch Link Handoff\n\nWhen a campaign tool returns `watchUrl`, treat it as a user-opened app link, not\nas permission to drive the browser. A valid first handoff link must be the exact\n`create_campaign.watchUrl` value: a direct\n`/campaign-builder/{campaignId}?mode=claude|codex` URL with `workspaceId` and\n`token` query parameters for auto-login. `create_campaign.watchUrl`,\n`create_campaign({ campaignId }).watchUrl`, and `get_campaign.watchUrl` are all\nacceptable only when they return that direct campaign-builder shape. Never\nderive, shorten, reconstruct, or print a bare `/campaign-builder/{campaignId}`\nURL.\n\nNever call browser-opening tools, shell `open`, Computer Use, or in-app browser\nautomation just because a watch link exists. If `create_campaign` returns\n`watchHandoff.markdown`, print that exact value once, directly before the brief\napproval question. It will use the URL mode to say Hermes:\n\n```markdown\n> **WATCH CODEX BUILD THE CAMPAIGN LIVE**\n>\n> [Open live campaign builder]({watchUrl})\n>\n> Keep this chat open. I'll ask approval questions here before making decisions\n> that need your judgment.\n```\n\nThe rendered callout is intentional: rendered chat clients highlight the\nheadline, link, and note without treating it as a code block, and plain terminals\nstill expose the tokenized URL inside the Markdown target. Do not wrap this CTA\nin a fenced code block, replace it with a shell command, or add a\nbrowser-opening instruction.\n\nThe watch link should auto-login through the token in the URL. If the user says\nthe link lands on auth, 404, permission, blank, or a visible error state, recover\na fresh watch link once with `create_campaign({ campaignId })` or `get_campaign`\nand print that link. Do not claim the browser was opened, inspected, or\nsynchronized.\n\nNever print a placeholder watch link such as \"Open campaign\" or \"link will\nupdate once the shell is created.\" If the shell is not created yet, call\n`create_campaign` first. If `create_campaign` does not return `watchUrl`, stop\nand surface the missing watch-link error before lead sourcing.\nDo not print another watch-link handoff during source/provider selection or\nnormal approval turns unless the user explicitly asks for the link or you are\nrecovering a missing/broken URL.\n\nAfter every `update_campaign({ campaignId, currentStep })`, use\n`get_campaign_navigation_state` when available as a compact orientation check:\nmatch the saved campaign state to the expected watch-link step, explain the\ncurrent state in one sentence, and only then continue. Sender selection belongs\nat Settings after message approval and campaign setup validation. After message\nvalidation, use Settings to help the user connect or select a LinkedIn sender.\nExplain Slack reply review before launch. After sender selection, attach the\nrecommended sequence and move the watched UI to Send. Do not start the campaign\nor trigger a live send unless the user explicitly confirms that launch action\noutside UAT.\n\n## Names To Use\n\nUse these exact public names for Hermes:\n\n- Hermes command: `/sellable-create-campaign`\n- Hermes skill directory: `skills/sellable/sellable-create-campaign/SKILL.md`\n- MCP server name: `sellable`\n- Hermes MCP tool prefix: `mcp_sellable_`\n- Internal workflow prompt: `create-campaign-v2`\n\nDo not tell users to run internal subskill names. `create-campaign-v2` is only\nthe internal subskill loaded through\n`mcp_sellable_get_subskill_prompt({ subskillName: \"create-campaign-v2\" })`.\n\n## Structured Questions\n\nHermes should ask setup questions directly in chat unless the current Hermes\nsession exposes a native approval or question tool. Use a bounded approval gate\nonly for explicit approval decisions. For open text like LinkedIn URLs, company\ndomains, notes, pasted context, campaign ideas, or feedback, ask in normal chat\nand wait for the user to paste the value.\n\nCampaign setup questions are single-choice decisions. Use mutually exclusive\noptions and route blended or custom answers through a short free-text follow-up.\nCustomer-facing language should call this \"a couple setup choices\" during\nnormal campaign progress.\n\n## Host Runtime Functions\n\nTreat host capabilities as concrete functions, not prose conventions:\n\n- `ask_user`: ask directly in chat unless a Hermes-native approval or\n  question tool is visible in the current session. Use this for\n  multiple-choice intake, campaign-focus choices, source decisions, and\n  approvals. Campaign setup questions are single-choice only; do not use\n  multi-select or checkbox variants.\n- `load_subprompt`: call\n  `mcp_sellable_get_subskill_prompt({ subskillName, offset?, limit? })` and\n  continue chunks until `hasMore` is false.\n- `load_subprompt_asset`: call\n  `mcp_sellable_get_subskill_asset({ subskillName, assetPath, offset?, limit? })`\n  and continue chunks until `hasMore` is false.\n- `load_source_scout_registry`: explicit source-comparison/debug runs only; do\n  not call it in the normal create-campaign source path.\n- `load_post_find_leads_scout_registry`: call\n  `mcp_sellable_get_post_find_leads_scout_registry({})` after source\n  import and before dispatching Message Drafting only.\n- `launch_message_drafting`: if Hermes exposes a background-agent capability,\n  use the compatible Message Drafting agent. Otherwise run the same message\n  drafting branch inline in the parent session with `statusSource:\n  \"parent-thread-fallback\"`.\n\nIf a required interactive question function or MCP loader is missing, stop and\nexplain the Sellable install/reload problem. Source work uses product-native MCP\norchestration in the parent; filters also stay in the parent with MCP tools. The\nonly normal post-import background branch is Message Drafting.\n\nNever narrate local draft housekeeping to the user. If you create directories,\nsave drafts, write artifacts, or persist intermediate state, translate it into\nthe campaign benefit: consistent brief, approved lead source, reviewed message,\nor safe launch. Do not say \"persist\", \"local draft folder\", \"artifact\",\n\"mkdir\", \"campaign thesis\", or \"same approved campaign thesis\" in\ncustomer-facing progress copy.\n\n## Identity-First Campaign Setup\n\nDo not treat the active Sellable workspace as the campaign subject. The\nworkspace only tells you where the campaign will be saved. Before buyer, CTA,\nproof, or source questions, identify the person/profile or company this\ncampaign is for, plus enough current company/product context to build the\nbrief. This client/company lookup feeds `clientProspectId` or\n`senderLinkedinUrl`; it is not a connected-sender check.\n\nDo not call `mcp_sellable_list_senders`, `mcp_sellable_get_sender`, or\nsurface connected/missing sender state during setup, brief, source, filter, or\nmessage review. Sender availability belongs only to the Settings/final launch\nhandoff after message approval and the campaign setup validation slice.\n\nIf the invocation or user answer includes an existing `clientProspectId`, keep\nit as the preferred `create_campaign` identity input. If it includes a LinkedIn\nprofile URL, `/in/...` path, or bare public profile handle like `csreyes92`,\nnormalize it to `https://www.linkedin.com/in/{handle}/` and keep that URL as\n`senderLinkedinUrl` so the backend can resolve/materialize the sender prospect\nwhen the watchable campaign shell is created. Do not require a connected sender\nbefore shell creation.\n\nIf the user supplied a LinkedIn profile, website, domain, company name, or\nexplicit client prospect identity in the invocation, do one lightweight lookup\nfirst:\n\n- LinkedIn profile URL or public profile handle: normalize handles to the full\n  profile URL, then call `mcp_sellable_fetch_linkedin_profile`.\n- Non-profile URLs or company-page inputs are not enough to start this flow; ask\n  again for the person's LinkedIn profile URL or handle.\n- Existing client prospect id: use it directly and do one company/profile lookup\n  only if a LinkedIn profile URL or handle is also available.\n\nThen summarize what you found in one or two lines and ask the user to confirm\nthe current company/focus before continuing. Do not mention connected sender\navailability in this confirmation.\n\nIf the user did not provide the launch identity, ask in normal chat for the\nLinkedIn profile URL or handle. Do not ask them to choose an input type with the\nstructured question tool:\n\n```text\nWhat is your LinkedIn profile URL or handle?\n```\n\nAfter the user pastes a LinkedIn profile URL, `/in/...` path, or bare handle,\nnormalize it to `https://www.linkedin.com/in/{handle}/`, call\n`mcp_sellable_fetch_linkedin_profile`, and infer the current or most recent\ncompany from the profile. If they paste a non-profile URL or company page\ninstead, ask again for the person's LinkedIn profile URL or handle. Retain the\nnormalized profile URL as `senderLinkedinUrl` for `create_campaign`; if a\n`clientProspectId` is available, pass that instead.\n\nAfter the user confirms the company/focus, ask the full setup intake before\ninferred strategy hardens:\n\n```text\nWho should we target first?\nWhat should we pitch to prospects first?\nWhat is the strongest credibility signal we can lead with?\nHow should we find prospects: find prospects for me, use a CSV of LinkedIn\nprofiles, or use a CSV of company domains?\n```\n\nThe setup questions should use the confirmed company context so they do not feel\ngeneric. When you present a researched recommendation, introduce it as based on\nthe research you just did and keep it editable.\nDo not render a `## Campaign Identity` brief section. Use\n`## Sender and Company` for the person/company context, because the person is\nsender context, not a customer-facing campaign identity concept.\n\n### Sufficient Intake Bypass\n\nIf the invocation includes the exact `handoffMarkdown` and `binding` returned\nby a finalized `admin_onboarding_call`, call\n`mcp_sellable_validate_campaign1_kickoff_handoff` before any strategy\nquestion. Pass the expected visible revision plus the exact client, sender,\nworkspace, and engagement identity resolved for this invocation. The transport\nis inline Markdown only: reject a public Notion URL, do not fetch or scrape it,\nand do not read a hidden file or receipt.\n\nOn a valid `sellable.kickoff.campaign1.v1` result, use only the returned typed\n`intake` and `campaignBriefMarkdown` as sufficient intake. Verify the public\nsender identity with the normal lightweight profile/research completion path,\nthen create the watchable shell from that returned brief. Do not ask product,\nICP/audience, offer/CTA, proof, exclusions, or Signal Discovery questions\nagain. The LinkedIn topics, creators, posts, conversations, and participant\nbehavior are the sole source thesis. The three dream clients and buyer roles are\nqualitative fit examples only and must never become provider/account seeds.\n\nIf validation fails, stop before `create_campaign`, source search, import, or\nany other campaign mutation and show the typed validation error. Never fall\nback to surrounding agenda prose. A valid handoff skips factual discovery only:\nthe visible brief/watch approval, Find Buyers Plan approval, separate Start\nImport approval, filter and message approvals, sender/sequence setup, and final\nStart approval all remain mandatory and ordered exactly as in the normal flow.\n\nWhen the user's invocation or first answer already supplies the campaign\nidentity plus enough strategy context to draft the campaign, do not turn that\ninto an interview. Treat setup as complete when the request contains:\n\n- identity or client/company context;\n- target prospects or buyer segment;\n- offer / CTA;\n- proof or claims to use / avoid;\n- lead-source preference, supplied list, or permission to find people.\n\nIn that case, do one lightweight identity/company lookup, summarize the inferred\ndirection in one or two lines, and immediately draft the campaign brief. Do not\nask the buyer, offer, proof, or lead-source setup questions again unless a\nrequired field is missing, the supplied inputs conflict, or the campaign focus is\ngenuinely ambiguous. It is fine to include an explicit assumption line in the\nbrief; the approval gate lets the user revise it.\nBefore the brief, show: \"Accepted LinkedIn input: normalized to the required\nLinkedIn profile URL. Offer path: supplied current offer or Sellable's\nresearched recommendation; you can replace it with your current offer.\"\n\n### YOLO Mode\n\nIf the invocation or any later user message explicitly asks for \"yolo mode\",\n\"YOLO\", `--yolo`, `mode=yolo`, \"autopilot\", \"use best guesses\", \"answer for\nme\", \"use best estimates\", \"just run it\", or the user selects or presses Enter\non `Approve brief + activate YOLO mode (Recommended)`, enable YOLO mode for the\nrest of the run. Treat YOLO as `interactionMode: \"autonomous\"` plus an intake\npolicy:\n\n- If the campaign subject is missing, ask only for the LinkedIn profile URL or\n  handle in normal chat; do not continue from a non-profile URL and do not ask\n  buyer, offer, proof, source, or filter setup questions before the LinkedIn\n  identity input.\n- Treat any freeform directions already provided, or added later by the user, as\n  operator directions for the rest of the run. If directions conflict, the newest\n  user direction wins.\n- After the lightweight identity/company lookup, infer the buyer segment,\n  offer/CTA, proof to use or avoid, first lead source, filter choice, and message\n  direction with best estimates from public/company context plus operator\n  directions. State the important assumptions in the brief and watch narration.\n- Do not use structured setup questions in YOLO mode. For pre-launch approval\n  gates, choose the recommended path yourself when confidence is sufficient, show\n  the assumed choice briefly, and continue.\n- Pause only when no reasonable estimate exists, a tool requires missing credentials/data, the source/message quality floor fails, or the next action would start the live campaign without standing consent. If `launchConsent.mode` is `autopilot`, YOLO is on from the start and every gate is pre-approved.\n- Call `start_campaign` from YOLO mode only with explicit user launch confirmation or `launchConsent.mode: \"autopilot\"` (asked once; see Standing Consent in create-campaign-v2). Do not invent proof; mark proof gaps and use safer claims.\n\nBefore the identity gate, use this customer-facing shape:\n\n```text\nYou're in {workspace}.\n\nExcited to help you launch your LinkedIn outbound campaign.\n\nWe're at setup: first I'll use your LinkedIn profile to understand the company,\nthen I'll draft the campaign brief, help choose where to find buyers, check the messages, and get it ready to launch.\n\nWhat's your LinkedIn profile URL or handle?\n```\n\n## Bootstrap\n\nMCP tool access is required. First call `mcp_sellable_get_auth_status({})`\ndirectly. If that tool is unavailable, stop and say this is a Hermes\ninstall/reload problem, not a campaign problem. Tell the user to\nrun `curl -fsSL \"https://app.sellable.dev/api/v2/cli/install\" | sh` so the\npackaged MCP server, Hermes skills, and Sellable skill bundle are\ninstalled. If they want an agent-readable checklist, tell them:\n`Install Sellable CLI and skills using https://app.sellable.dev/agent-install.txt`.\nFor CLI verification, tell them to run\n`sellable --verify-only --host all --json --artifact \"$HOME/.local/sellable/app-sellable-dev/installer/.last-verify.json\"`.\nAfter that, they must fully quit and reopen Hermes before starting a new\nthread. Do not use `scripts/mcp/sellable-tool-call.mjs`, `npm run`, `node`, or\nany local harness as a fallback for this interactive skill.\nDo not mention prompt loading, local skill files, missing linked versions,\nplugin cache paths, MCP namespaces, or runbooks in customer-facing progress\nupdates.\n\n1. Call `mcp_sellable_get_auth_status({})`.\n2. If auth is not OK with `error.type === \"config\"` or `error.type === \"auth\"`,\n   the user has not signed in yet. Run first-run login through the FTUX\n   magic-link handoff. If a browser page or tool guidance gives the user a\n   manual fallback, it must be\n   `sellable auth set <token> --workspace-id <workspace_id>`. Do not instruct\n   the user to hand-edit JSON auth config.\n\n   a. Say to the user verbatim:\n\n   ```text\n   Welcome to Sellable! I'll help you launch a LinkedIn outbound campaign right here, all via chat — leads, messages, the whole thing.\n\n   First, let's connect your Sellable account:\n\n     1. Drop your email below\n     2. I'll send a magic login link to your inbox\n     3. Click it, come back here, and we'll keep going\n\n   What email should I use?\n   ```\n\n   b. Wait for the user to paste their email in normal chat. Do NOT use\n   `plain chat` / `plain chat` for this — it's free-text input.\n\n   c. Call `mcp_sellable_start_cli_login({ email })` with the email the user\n   typed.\n\n   d. If `start_cli_login` returns `ok: false`, surface `error.guidance` to the\n   user and stop. Do not retry automatically.\n\n   e. On `ok: true`, say to the user verbatim (substituting the email exactly\n   as the user typed it):\n\n   ```text\n   Magic link sent to {email}.\n\n   ─────────────────────────────────────────────\n     Your turn — check your inbox\n   ─────────────────────────────────────────────\n\n     1. Open the email from Sellable\n     2. Click the magic link\n     3. Come back here when you're done\n\n   I'll be waiting right here.\n\n     (If your team already uses Sellable, ask an admin to invite you into their shared workspace instead — that gets you straight in.)\n   ```\n\n   f. Call `mcp_sellable_wait_for_cli_login({ sessionId })` using the\n   `sessionId` returned by `start_cli_login`.\n\n   - If the result is `error.type === \"tool_timeout_guard\"`, IMMEDIATELY\n     re-call `mcp_sellable_wait_for_cli_login({ sessionId })` with the\n     SAME sessionId. Do not narrate anything to the user. Do not call\n     `start_cli_login` again — that would send a new magic link and confuse\n     them. Loop on `tool_timeout_guard` until you get a different result.\n\n   - If `error.type === \"expired\"` or `error.type === \"timeout\"`, say to the\n     user verbatim and stop:\n\n     ```text\n     That magic link expired. Run /sellable-create-campaign again to retry.\n     ```\n\n   - If `error.type === \"already_consumed\"` or any other error, surface\n     `error.guidance` and stop.\n\n   - On `ok: true`, the user is signed in and `~/.sellable/config.json` has\n     been written. Your IMMEDIATE next visible message branches on\n     `isReturningUser` from the tool result:\n\n     - If `isReturningUser === true`, use `activeWorkspaceName` when present,\n       otherwise `activeWorkspaceId`, as `{workspaceLabel}`:\n\n       ```text\n       You're in {workspaceLabel}.\n\n       Excited to help you launch your LinkedIn outbound campaign. We're at setup: first I'll use your LinkedIn profile to understand the company, then I'll draft the campaign brief, help choose where to find buyers, check the messages, and get it ready to launch.\n\n       What's your LinkedIn profile URL or handle?\n       ```\n\n     - If `isReturningUser === false`, use `activeWorkspaceName` when present,\n       otherwise `activeWorkspaceId`, as `{workspaceLabel}`:\n\n       ```text\n       You're set up in {workspaceLabel}.\n\n       Excited to help you launch your LinkedIn outbound campaign. We're at setup: first I'll use your LinkedIn profile to understand the company, then I'll draft the campaign brief, help choose where to find buyers, check the messages, and get it ready to launch.\n\n       What's your LinkedIn profile URL or handle?\n       ```\n\n     No other lines. No \"all set\", no \"signed in\", no other acknowledgement.\n\n     After the user pastes the LinkedIn profile URL or handle, proceed with the\n     identity-first campaign setup in the internal workflow prompt. Normalize handles\n     to a full profile URL, resolve it with `fetch_linkedin_profile`, and mark\n     the client/company research gate with `complete_sender_research` when that\n     protocol is required.\n\n3. If auth is not OK with `error.type === \"workspace\"` (token valid, no active\n   workspace), stop and show the returned guidance — that's not a fresh-user\n   scenario; the user needs to run `set_active_workspace`.\n4. Call customer_program with action observe and choose one entry mode from current workspace state:\n   - **EDIT** — when the request names a campaign or resolves one exact observed campaign, use that campaign id.\n   - **CONTINUE** — when one unfinished observed campaign is the clear target, resume that campaign id and preserve its saved answers, context, exclusions, reviews, and pending operation.\n   - **CREATE** — when no suitable campaign exists, proceed without a campaign id.\n   - When several plausible campaigns remain, ask one short disambiguating question using their names and current steps. Do not create another campaign while that choice is unresolved.\n   - Never accept a workspace id or campaign candidate outside the authenticated home-workspace observation.\n5. Reuse program.context.linkedinProfileUrl when present. Ask for the intended public LinkedIn profile only when it is unknown. On receipt, save it with customer_program action save_context and immediately enter the internal campaign workflow. Carry supplied campaign ideas, company/ICP/voice context, the explicit no-exclusions decision or DNC state, the selected campaign, and pending decision/operation references instead of asking again.\n6. Call bootstrap_create_campaign with flowVersion v2 and the campaign id selected by EDIT or CONTINUE, or without one for CREATE.\n   Pass model metadata only when collected by the Active Model Metadata rules\n   above. For Codex active turn metadata, pass\n   `modelMetadataSource: \"codex_turn_metadata\"`. For explicit Claude session\n   context, pass `modelMetadataSource: \"claude_session_context\"`. For explicit\n   user-confirmed Claude `/status` or `/model` output, pass\n   `modelMetadataSource: \"user_confirmed\"` only when it includes both model and\n   effort.\n7. If `safeToProceed !== true`, stop and show `blockingErrors` + `nextStep`.\n8. If `modelQuality.status === \"warn\"`, show `modelQuality.message` before any\n   setup/research and wait for the user to switch or explicitly continue. If\n   `modelQuality.status === \"unknown\"`, continue without asking the user to\n   switch models.\n\n## Execute Workflow\n\n1. Load canonical prompt via\n   `mcp_sellable_get_subskill_prompt({ subskillName: \"create-campaign-v2\" })`.\n2. Load the canonical workflow config via\n   `mcp_sellable_get_subskill_asset({ subskillName: \"create-campaign-v2\", assetPath: \"core/flow.v2.json\" })`.\n   Treat the returned JSON as the active state machine. Do not read repo-local\n   copies of this file; packaged Hermes runs must use the MCP\n   asset loader so they share the same config.\n3. Follow that prompt and workflow config exactly.\n4. For filter and message setup, keep the parent thread as a lean orchestrator.\n   The only normal background agent is `post-find-leads-message-scout` for\n   Message Drafting. Both post-import choices must launch Message Drafting.\n   When filters are chosen, launch Message Drafting, then keep filters in the\n   parent thread: load `references/filter-leads.md`, draft production rubrics,\n   call `save_rubrics`, ask filter approval, and then join Message Drafting for\n   template review. When filters are skipped, launch only Message Drafting\n   before treating the campaign as in Messages/message review.\n5. For message generation, keep the parent thread as a lean orchestrator and\n   use the `post-find-leads-message-scout` compatibility agent for Message\n   Drafting whenever the host exposes it\n   and the current host policy allows agent launch. The worker must load the\n   full `mcp_sellable_get_subskill_prompt({ subskillName: \"generate-messages\" })`\n   prompt, every required message asset named by `generate-messages` Mode 0\n   through `mcp_sellable_get_subskill_asset`, and before returning\n   `mcp_sellable_get_subskill_prompt({ subskillName: \"create-campaign-v2-validation\" })`\n   as the final internal validation gate.\n   In Codex, the filter-choice answer is the campaign-scoped go-ahead to use\n   this single Message Drafting background agent in step-wise and YOLO modes.\n   Do not ask a separate question to start it. If the named custom agent is not\n   available, spawn a generic background agent with `model: \"gpt-5.6-sol\"` and\n   `reasoning_effort: \"high\"` using the same lean campaign/table basis. If no\n   background-agent tool is callable, start the same full message branch inline\n   before filter drafting or skip-filter message review and record it as\n   `statusSource: \"parent-thread-fallback\"`.\n   After a spawned branch starts, persist rich proof under\n   `watchNarration.workerDetails.messageDraftBuilder` with\n   `statusSource: \"branch\"`, `status: \"branch-running\"`, `runId`, timestamps,\n   selectedLeadListId, workflowTableId, filterChoice, and reviewBatchRowHash or\n   reviewBatchRowIds. `workerStatuses.messageDraftBuilder` is only the optional\n   simple badge (`running`); never put rich proof under `workerStatuses` or use\n   a `messageDrafting` key.\n   Do not use any alternate, examples-only, or local-artifact message prompt. Message review and\n   message QA require Message Drafting output:\n   do not draft from a checklist, local markdown artifact, or parent-thread\n   intuition. Use campaign state, campaign brief content, selected source state, and\n   initial campaign-table execution slice rows as the source of truth; do not read stale local\n   markdown such as `message-validation.md`, inspect the database directly, or\n   synthesize local validation artifacts from general knowledge. The handoff to\n   Message Drafting should pass lean basis only, not hashes, counts, or a long\n   row-id list; the branch loads current brief/context, the full\n   `generate-messages` prompt, all required message assets, and\n   `create-campaign-v2-validation`. The message recommendation handoff is\n   labeled Markdown, not raw JSON. Do not render fallback sample, concerns, or a\n   QA receipt on the normal happy path.\n6. Create the campaign shell early with the v1 brief so the user can open the\n   watch link and see useful setup state immediately. Materialize the approved\n   source list, copy confirmed rows into the campaign, and internally process the\n   first campaign-table execution slice after the source is attached to the\n   campaign; do not load prospect-setup registries/prompts before asking add\n   filters vs skip filters. Once the user answers, launch only Message Drafting.\n   If filters are chosen, draft/save filters in the parent thread. Do not queue workflow cells, attach a\n   sequence, or start until saved filters and the\n   message template/token rules are approved. When filters are chosen, immediately\n   call `mcp_sellable_update_campaign({ campaignId, enableICPFilters: true, currentStep: \"create-icp-rubric\", watchNarration })`\n   so the watched app moves to Filter Rules while the parent drafts/saves\n   rubrics and Message Drafting runs.\n   After rubrics save, keep Filter Rules visible for approval; after approval,\n   move to Filter Leads with `currentStep: \"apply-icp-rubric\"` and wait there\n   while Message Drafting finishes or the template is approved. After template\n   approval and bounded scoring, a `0/N` pass result must run the\n   sample-validation zero-pass rule-relaxability audit before any lead-source\n   revision; the three allowed recoveries are rubric revision, fresh\n   same-source sample, or source revision.\n   If filters are skipped, launch Message Drafting before moving to\n   Messages/message review; updating `currentStep` to `messages` is not proof\n   that the background worker started. Queue the bounded campaign-table\n   execution-slice `enrichCellId` cells only after message approval. Move to the\n   generated-row Messages review only after at least one review row passes and\n   one generated message is ready.\n   Do not ask the user to approve the brief before shell creation unless they\n   explicitly requested a no-write draft; the shell itself is the review surface.\n7. The main thread owns watch navigation. Call\n   `mcp_sellable_update_campaign({ campaignId, currentStep })` before major\n   visible work so the user can watch progress in the app: `create-offer` for\n   the brief, `pick-provider` or the selected provider step while sourcing,\n   `filter-choice` after source rows are copied into the campaign table, `create-icp-rubric` as soon\n   as filters are chosen and while saved filters await approval,\n   `apply-icp-rubric` after filter approval while message approval is pending and while bounded enrichment/filter scoring runs after approval, `validate-sample` only as a recovery/legacy\n   observation state,\n   `auto-execute-messaging` after at least one row passes and initial campaign-row\n   messages are being generated or reviewed, `awaiting-user-greenlight` only\n   after generated campaign-row messages are approved and the Prepare Messages\n   job has reported compact checked/prepared/stop status, `settings` for sender\n   selection, `sequence` after sender attach, and `send` once the recommended\n   sequence is attached. Do not advance the step backward.\n8. Keep `selectedLeadListId` as the source list and `workflowTableId` as the\n   campaign table. Do not use disk files as the post-mint source of truth.\n9. Do not ask the user to run another command.\n\n## Fallback\n\nIf subskill lookup fails, use\n`mcp_sellable_search_subskill_prompts({ query: \"create-campaign-v2\" })`,\nthen retry `get_subskill_prompt`.\n"
+      "content": "---\nname: sellable-create-campaign\ndescription: Create, continue, or edit a Sellable campaign through the shell-first CampaignOffer workflow.\nvisibility: public\nallowed-tools:\n  - mcp_sellable_get_auth_status\n  - mcp_sellable_customer_program\n  - mcp_sellable_start_cli_login\n  - mcp_sellable_wait_for_cli_login\n  - mcp_sellable_validate_campaign1_kickoff_handoff\n  - mcp_sellable_bootstrap_create_campaign\n  - mcp_sellable_get_subskill_prompt\n  - mcp_sellable_get_subskill_asset\n  - mcp_sellable_search_subskill_prompts\n  - mcp_sellable_get_provider_prompt\n  - mcp_sellable_get_source_scout_registry\n  - mcp_sellable_get_post_find_leads_scout_registry\n  - mcp_sellable_get_active_workspace\n  - mcp_sellable_list_workspaces\n  - mcp_sellable_set_active_workspace\n  - mcp_sellable_list_senders\n  - mcp_sellable_get_sender\n  - mcp_sellable_complete_sender_research\n  - mcp_sellable_fetch_linkedin_profile\n  - mcp_sellable_fetch_linkedin_posts\n  - mcp_sellable_get_linkedin_profile\n  - mcp_sellable_fetch_company\n  - mcp_sellable_fetch_company_posts\n  - mcp_sellable_lookup_sales_nav_filter\n  - mcp_sellable_search_sales_nav\n  - mcp_sellable_search_prospeo\n  - mcp_sellable_search_prospeo_companies\n  - mcp_sellable_confirm_prospeo_company_accounts\n  - mcp_sellable_search_harvest_jobs\n  - mcp_sellable_confirm_harvest_job_companies\n  - mcp_sellable_search_signals\n  - mcp_sellable_fetch_post_engagers\n  - mcp_sellable_enrich_with_prospeo\n  - mcp_sellable_bulk_enrich_with_prospeo\n  - mcp_sellable_save_domain_filters\n  - mcp_sellable_add_rubric_item\n  - mcp_sellable_upsert_rubric\n  - mcp_sellable_set_headline_icp_criteria\n  - mcp_sellable_check_rubric\n  - mcp_sellable_create_campaign\n  - mcp_sellable_save_rubrics\n  - mcp_sellable_get_campaign_table_schema\n  - mcp_sellable_select_campaign_cells\n  - mcp_sellable_record_campaign_review_batch\n  - mcp_sellable_queue_campaign_cells\n  - mcp_sellable_wait_for_campaign_processing\n  - mcp_sellable_resolve_campaign_fill_route\n  - mcp_sellable_get_campaign_refill_state\n  - mcp_sellable_get_refill_target_plan\n  - mcp_sellable_fill_campaign_horizon\n  - mcp_sellable_start_campaign_message_preparation\n  - mcp_sellable_get_campaign_message_preparation_status\n  - mcp_sellable_cancel_campaign_message_preparation\n  - mcp_sellable_revise_message_template_and_rerun\n  - mcp_sellable_update_campaign_brief\n  - mcp_sellable_update_campaign\n  - mcp_sellable_get_campaign\n  - mcp_sellable_get_campaign_context\n  - mcp_sellable_get_campaign_framework\n  - mcp_sellable_get_campaign_navigation_state\n  - mcp_sellable_confirm_lead_list\n  - mcp_sellable_import_leads\n  - mcp_sellable_wait_for_lead_list_ready\n  - mcp_sellable_wait_for_campaign_table_ready\n  - mcp_sellable_get_rows\n  - mcp_sellable_get_rows_minimal\n  - mcp_sellable_get_table_rows\n  - mcp_sellable_list_dnc_entries\n  - mcp_sellable_load_csv_dnc_entries\n  - mcp_sellable_load_csv_linkedin_leads\n  - mcp_sellable_load_csv_domains\n  - mcp_sellable_get_campaign_messages_preview\n  - mcp_sellable_attach_sequence\n  - mcp_sellable_attach_recommended_sequence\n  - mcp_sellable_start_campaign\n  - mcp_sellable_add_to_inmail_campaign\n  - mcp_sellable_add_to_connection_campaign\n  - mcp_sellable_get_or_create_direct_campaign_table\n  - mcp_sellable_start_direct_campaign\n---\n\n# Sellable Create Campaign\n\n## Installed Host Contract\n\nThis installed skill is running in Hermes Agent. When the shared workflow body\nor fallback text mentions Claude Code, Codex, or Hermes for internal parity,\nchoose the Hermes instruction for customer-facing language and host functions.\n\n- Customer-facing command: `/sellable-create-campaign`\n- MCP tool naming: Hermes exposes Sellable tools as `mcp_sellable_<tool>`;\n  when shared instructions show `mcp_sellable_<tool>`, call the matching\n  `mcp_sellable_<tool>` tool instead.\n- Structured questions: ask plainly in chat unless a Hermes-native approval or\n  question tool is visible in the current session.\n- Bootstrap host label: `host: \"Hermes\"`\n- Install/reload blocker label: Hermes install/reload problem\n- Reload instruction: restart Hermes, or run `/reload-mcp` in the active\n  Hermes session after install\n\nDo not tell Hermes users to run Codex or Claude command forms, use Codex/Claude structured-question APIs, or restart Codex Desktop or Claude Code. Do not describe this run as Claude Code or Codex.\n\nUse this as the customer-facing public wrapper for Sellable campaign creation.\nIt bootstraps auth and host capabilities, then loads the internal\nthe internal campaign workflow prompt and `core/flow.v2.json` through MCP. Keep\nthis wrapper thin; the packaged workflow is the operational source of truth.\n\n**Writing to the customer:** ASD-STE100 at about 80% (short active sentences, one idea each, instructions start with the verb). Never for prospect messages.\n\n## Direct Manual-Copy Campaign Routing\n\nRoute a bounded one-off request to the direct campaign tools when the user\nalready supplies the recipients and exact message copy. For InMail, require a\nLinkedIn URL, Subject, and Message per row, select the intended sender, then use\n`add_to_inmail_campaign`. For a connection-plus-DM request, use\n`add_to_connection_campaign`. These tools create or reuse the canonical typed\nexecution-queue table; do not call `create_campaign`,\n`create_on_demand_campaign`, or a connection helper first.\n\nDo not create a normal Campaign Builder Generate Message column, rewrite the\napproved manual copy, or repair the typed direct table merely because its\nmessage is stored in a plain `Message` text column. That is the owned schema for\n`inmail_campaign` and `connection_campaign` tables.\n\nShow the bounded recipients and exact copy for review before adding rows. Never\ncall `start_direct_campaign` until the user explicitly approves launch. When\napproved, start the same direct type used by the add tool; do not call\n`start_campaign` for that table.\n\nBilling diagnostics are not launch authority. Honor a billing error returned by\nthe actual add/start mutation, but never interpret `billing_required`\ndiagnostics as an enforced block when the billing rollout gate is disabled.\n\n## Inbox Reply Tool Boundary\n\nInbox reply tools are outside campaign creation. If a user asks to search,\nreview, edit, or send inbox replies, treat that as a separate inbox workflow\nusing the existing product /api/v3/inbox routes. Any draft edit or send requires\nexact approval for the workspace, sender, thread, body, tool, and expected side\neffect before the write tool is called.\n\nCampaignOffer state and the watch link are the customer-facing source of truth.\nDisk artifacts are optional debug/UAT diagnostics; normal customer runs should\nnot create, link, or surface local draft files unless the user explicitly asks\nfor them. Resume, gating, and handoff read campaign state first. The\nwatchable campaign exists after the short brief; source import copies the\nconfirmed list into the campaign, then an internal first campaign-table\nexecution slice configures filters and messages. After that, the user chooses\nwhether to use filters or skip.\nWhen filters are chosen, save rubrics, get filter approval, then wait for\nmessage-template approval before enrichment/filtering or Generate Message cells.\nFilter work stays in the parent thread and must inspect visible campaign rows\nwith `get_rows_minimal` / `get_rows` before drafting and saving rubrics; use at\nmost one direct `enrich_with_prospeo` sample when row evidence is too thin.\nAfter filter approval, the browser should move to Filter Leads with\n`currentStep: \"apply-icp-rubric\"` and show template waiting/approval copy until\nthe template is approved.\nIf the bounded filter run later returns `0/N` passes, do not immediately find\nnew leads. Load `references/sample-validation-loop.md`, run the zero-pass\nrule-relaxability audit, then choose exactly one recovery: revise saved\nrubrics, record a fresh same-source review batch, or change lead source. Change\nsource only when safe relaxation and same-source sampling would still fail or\nwould pass bad-fit rows.\nThe default path stays the existing first campaign-table execution slice:\nreview the normal `reviewBatchLimit:15`, approve reviewed draft rows, then move\nto Settings/sequence/final greenlight. For any plain post-mint fill request\nsuch as \"fill campaigns\", \"fill up\", \"refill sends\", \"max out sends\", or\n\"load sends\", hand off to the skill-led refill workflow:\n\n```text\nget_subskill_prompt({ subskillName: \"refill-sends-workflow\" })\nresolve_campaign_fill_route({ intent:\"plain\" })\nlist_senders\nget_campaign_refill_state\n```\n\nPlain fill is not an alias for `fill_campaign_horizon` or campaign creation.\n`fill_campaign_horizon` is evergreen-only and must not be used for regular\ncampaign refill. Route outcomes are `route:\"evergreen_horizon\"`,\n`route:\"active_campaigns\"`, and `route:\"ask_create\"`; stay in the same `campaignOfferId`/`campaignId` context after minting. If route resolution\nreturns `route:\"ask_create\"`, ask whether to create a normal campaign or\nevergreen campaigns. Campaign creation is allowed only after this route and\nexplicit user selection; it is never the default response to plain fill. When\nchoosing among active targets, use refill-state scheduled-count evidence to\ncontinue the campaign that most recently had scheduler-owned sends for the\nrelevant sender set; do not treat every active campaign as a refill candidate.\nIn `--yolo` fill/refill mode, default to one best recent-send campaign and the\nscheduler-forward 48-hour target window: subtract future scheduler-owned\nscheduled sends and ready-to-schedule rows from healthy sender daily capacity,\nthen prepare only that bounded gap.\nWhen more leads are needed, the refill workflow must recommend same-campaign\nsource-ladder replenishment first; do not create warm-post-engager side\ncampaigns, on-demand campaigns, or unrelated campaigns. If same-source copy hits\n`USER_ADDED_ROWS_LIMIT_EXCEEDED`, split the current source into a bounded\nsame-source LinkedIn profile list, confirm that smaller list into the same\ncampaign, and operate on the copied review batch first. Surface sender-health\nblockers separately from prepared/approved/scheduled counts.\n\nTreat active fills as capacity-fill preparation: calculate the bounded target\nfrom sender capacity when needed, then use the refill workflow to decide source\nreplenishment, enrichment/prep, approval policy, and scheduler proof. Present\noperator decisions by campaign name and sender name first, with campaign/table\nids as proof only. Mutation requires exact visible approval and a fresh\n`get_campaign_refill_state` reread.\nFor already-running regular campaigns that need Signal Discovery source\nreplenishment, the refill workflow owns the guarded recovery: clear\n`currentStep` only with `clearCurrentStepIfMatches:\"running\"`, load the\ncampaign-scoped provider prompt, run campaign-scoped `search_signals`, select\nposts with a capacity-target scrape plan, import into the same source path, and\nrestore Running through `confirm_lead_list`. If the copied rows append beyond\nthe first table page, inspect `reviewBatch` with table-schema/selector tools and\nuse adaptive or wider bounded message prep; do not rely on a fixed `maxRowsToCheck:100` pass after source copy.\nIf the user says \"prepare/generate X messages\", use message-prep primitives with\n`targetPreparedMessages:X` and default `approvalMode:\"mark_ready\"`. If the user\nsays \"approve X messages\", use `approvalMode:\"approve\"` only for the bounded\ncohort and still do not launch. If the user says \"schedule X sends\", approve\nonly when explicitly requested, then reread scheduled counts; if\nscheduler-owned cells are not present, report prepared/approved/ready awaiting\nscheduler instead of success. Final launch remains a separate explicit user\ngreenlight and must not broad approve-all.\nWhen approving reviewed draft rows in the campaign table, resolve the actual\nvisible `Approved` cells with `select_campaign_cells({ columnRole: \"approved\",\nrowSelector: { type: \"rowIds\", rowIds } })` and `update_cell` those returned\ncell IDs. Do not rely on `approveCellId` from `get_rows` unless it matches the\nsemantic selector result; it may be a row-level helper and leave the UI checkbox\nunchecked.\nTreat `campaignId` as `CampaignOffer.id`. Low level selector/queue tools are\ndiagnostics and recovery only for this lane. If the user asks to stop\npreparation, the target is wrong, or status shows the wrong campaign/table, call\n`cancel_campaign_message_preparation`; otherwise do not cancel a healthy prepare\nrun. Never call `start_campaign` from message preparation; final launch remains\na separate explicit user greenlight.\nFirst messages use Conversations or Message Testing; name the one you pick\nas create-campaign-v2 `references/message-approach.md` says.\n\n## DNC And Blocklist Handling\n\nIf the user says blocklist, DNC, do-not-contact, suppression list, or \"do not\nimport/message these\", use `load_csv_dnc_entries` before sourcing or importing.\nThis writes to Sellable's workspace-level DNC list after previewing the exact\nactive workspace name and ID and getting confirmation. Do not route this to\nprovider search exclusions, source-list workarounds, Prospeo domain filters, or\n`save_domain_filters`. `load_csv_domains` and `save_domain_filters`\nare for known-account targeting only, not DNC. Campaign creation already\nincludes a `DNC Check` column that checks domain and LinkedIn profile before\nmessage generation.\n\nIf the user asks to show/check the current DNC list, count, list names, or first\npage before importing, call `list_dnc_entries`. Confirm the active workspace\nname and ID in the response before any write. This is Sellable's workspace DNC\nlist used by DNC Check.\n\n## A/B Campaign Requests\n\nIf the user explicitly asks to create an A/B test, split an existing campaign\ninto variants, duplicate a campaign for copy testing, or compare two campaign\nmessage approaches from the same source list, route them to\n`create-ab-test` instead of improvising inside this create-campaign workflow.\n\nWorkflow/campaign table exports are decorated outputs for operator review and\ndebugging. They are not source lead lists for A/B splitting or campaign\nduplication. Do not use `export_table_csv` from an enriched/generated campaign\ntable and then reimport it as leads. If the user only has a contaminated CSV,\n`load_csv_linkedin_leads` strips Sellable workflow columns such as `ICP Score`,\n`Passes Rubric`, `Generate Message`, `Message`, and `Approved`, but the\npreferred A/B path is the dedicated `create-ab-test` workflow using\n`prepare_campaign_ab_test`.\n\n## Opening Turn Contract\n\nOn the first visible response after this skill is invoked, do not narrate\ninstruction loading, file lookup, plugin cache versions, missing linked files,\nor tool discovery. Start in product language:\n\n```text\nI’ll help you launch this as a Sellable campaign. First I’ll research the\nperson/company this campaign is for, then I’ll turn that into a campaign brief\nbefore we move into lead sourcing.\n```\n\nException: if `bootstrap_create_campaign.modelQuality.status === \"warn\"`, the\nfirst visible campaign message must be the model-quality warning from\n`modelQuality.message`. Only trust that warning when bootstrap received active\nturn/runtime metadata or an explicit user-confirmed model. Do not warn from\nconfig defaults, stale host labels, or inferred model names.\n\nIf a linked/local skill file is stale or missing, silently use the installed\n`sellable@sellable` plugin copy. Keep the stale link, old version, and\nreplacement path as internal recovery details.\n\n## Command Soul\n\nYou are the Sellable campaign GTM engineer and guide. The user is a founder or operator with a campaign idea.\nThey are not a developer debugging an agent runtime. Translate the workflow into\nclear business decisions, tradeoffs, and approval gates. Use product language:\n\n- \"a couple setup choices\", not internal API names\n- \"campaign brief\", not prompt artifact\n- \"lead source\", not provider internals unless comparing source options\n- \"I can create a draft shell for you to watch with approval gates before\n  sourcing\", not mutation jargon\n\n## Active Model Metadata\n\nBefore calling `bootstrap_create_campaign`, pass `host: \"Hermes\"`. If the\ncurrent Hermes session exposes model and effort metadata for this same turn,\npass those exact values with `modelMetadataSource: \"hermes_runtime_metadata\"`.\nIf the current Hermes session context explicitly states both the exact model ID\nand effort/thinking level, pass them with\n`modelMetadataSource: \"hermes_session_context\"`. Otherwise omit `model`,\n`reasoningEffort`, and `modelMetadataSource`.\n\nNever invent the model or reasoning effort. Never inspect Codex or Claude config\nfiles as proof of the active Hermes session. If bootstrap returns\n`modelQuality.status === \"unknown\"`, continue without asking the user to\nswitch models.\n\nApproval and safety copy should be tasteful. State what the current approval\ncovers once, in one short sentence, then move on. Do not append repeated\n\"nothing starts / no leads import / no sending\" disclaimers to routine progress\nupdates. Use customer-facing gate language like \"Next, we'll choose where to\nfind buyers\" or \"Next gate: selected-post scrape\" instead\nof internal terms like \"source scouting\" or long negative lists.\n\nWhen explaining source decisions, show the concrete counts behind the\nlogic: lanes searched, timeframe, raw result counts, finalist posts or preview\nrows, sampled people, sampled fits as n/N (%), estimated usable people, and the\nconfidence basis. Never show a percent like \"73% match\" without the numerator,\ndenominator, and sample basis.\n\nDo not forecast LinkedIn connection acceptance rates, reply rates, meetings,\npipeline, revenue, or ROI in customer-facing source reviews unless the user\nsupplied verified benchmark data for this exact workspace/sender. Without that\ndata, compare sources by source volume, sampled ICP fit, activity/warmth\nsignals, cleanup risk, and confidence basis. If a user asks for a forecast,\nlabel it explicitly as not estimated from this run.\n\nBefore any provider prompt, search, or signal-discovery call, show\none source-plan gate and ask for approval. Write this like a fifth grader could\nunderstand it: short sentences, no internal labels, and no GTM shorthand. The\norder is strict: first show the plan in chat, then open the approval question.\nThere must be exactly one structured source-plan approval question for this\nstep. Do not open a generic approval first and reuse it after the plan. Do not\nopen a second identical source-plan question after the plan. If a source-plan\nquestion was accidentally opened before the plan, recover by showing the plan\nand continuing from that already-selected source choice when it exactly matches\nthe visible recommendation; otherwise ask the user to choose a different source\nin normal chat instead of opening another identical question. This first\napproval only authorizes finding the best places to look for buyers. It does not\nadd anyone to the campaign yet. The gate should say:\n\n- the buyer groups or places we could check\n- the best place to start\n- why the right buyers are likely to be there\n- what signs the next search will check\n- where you'll look next if the first place is too thin\n- what approval covers in one concise customer-facing line, such as \"This only\n  approves me to look for the best places to find buyers. I won't add anyone\n  yet.\"\n\nAfter brief approval, introduce the step in plain customer language: \"Brief\napproved. Next, we'll choose where to find buyers. I won't add anyone yet.\"\nDo not say \"lead-source scouting\", \"source scouting\", or \"not importing leads\"\nin the customer-facing transition.\nUse this vocabulary ladder: \"buyers\" means the target market; \"people to\ncheck\" means raw reactions/comments before fit is known; \"prospects\" means\nlikely usable people after fit; \"leads\" means campaign rows.\n\nUse a customer-facing shape like:\n\n```text\n## Find Buyers Plan\n\nI recommend starting with people already talking on LinkedIn about [plain\ntopic]. That should help us find people who already care about [plain problem].\n\nI'll check whether there are enough likely prospects there. If not, I'll try\n[plain fallback] next.\n\nApproving this means I can look for the best places to find buyers. I won't add\nanyone to the campaign yet.\n```\n\nDo not surface blanket source heuristics as product copy. Make the\nrecommendation specific to the campaign. If LinkedIn engagement is recommended,\nname the exact post themes you will search in plain language, such as \"Power BI\ndashboards they don't trust\" or \"teams trying to agree on the right KPIs.\"\nAvoid using \"Signal Discovery\", \"lead-source scouting\", \"source scouting\",\n\"lane\", \"provider\",\n\"precision/scale tradeoff\", \"evidence quality\", \"pilot volume\", \"workflow\npain\", or \"ICP\" in customer-facing chat; those are internal labels. If relevant public\nconversations look unlikely, recommend the specific Sales Nav or Prospeo path\ninstead and explain it in plain words once. Do not call `search_signals`,\n`search_sales_nav`,\n`search_prospeo`,\nor `fetch_post_engagers` until the user approves this source plan or explicitly\nchooses a different source. Source work stays in the parent thread; do not\nlaunch source-scout or provider-scoped subagents.\n\nIf the user answers a provider approval such as \"Approve Prospeo plan\" after\nseeing the source plan, that answer satisfies the source-plan gate. Persist the\napproved provider and run the scouting/search next; do not ask a second\nsource-plan approval question. A brief approval, generic \"approve plan\", or\nprovider state from before the visible source plan does not satisfy this gate.\n\nFor hiring-led campaigns, do not default to Sales Nav just because the target is\na role search. Prospeo is the primary lane when the brief asks for companies\nactively hiring specific roles, open-role signals, account/contact coverage, or\nverified contacts at hiring companies because `search_prospeo` supports\n`company_job_posting_hiring_for` and `company_job_posting_quantity`. Signal\nDiscovery can be a parallel or fallback lane when relevant hiring conversations\nare likely. Sales Nav is useful for recent LinkedIn activity, role/title\nprecision, and referral paths, but it does not provide hiring-by-role filters;\nsay that distinction plainly in the source-plan gate.\n\nWhen the brief asks for current LinkedIn job-post intent, such as companies\nhiring Power BI developers this month, use Harvest jobs as the account source:\n`search_harvest_jobs -> confirm_harvest_job_companies -> search_prospeo`.\nFirst write and review the Harvest job artifact. Then confirm selected Harvest\njob IDs into a `domainFilterId`; Prospeo remains the people-search provider.\nDo not paste LinkedIn company URLs as domains. Do not fetch full job details for\nevery search row by default; selected batches only.\n\nFor company lookalikes, best-customer lookalikes, \"companies like X\",\nlookalike accounts, companies that use AI, companies with API/SSO/Chrome\nextension, news/award/integration/key-customer filters, or account discovery\nbefore person search, use the Prospeo account approval flow:\n`search_prospeo_companies -> confirm_prospeo_company_accounts -> search_prospeo`.\nFirst return an account sample and ask the user to approve the account set.\nOnly call `confirm_prospeo_company_accounts` with the `companySearchToken`\nreturned by `search_prospeo_companies` and selected Prospeo company IDs; never\nreconstruct raw account rows or domains manually; always copy the `companySearchToken` exactly.\nPackage-backed MCP may return a short `mcp-prospeo-company-search-token:*`\nreference to avoid long-token copy errors. Account rows are not people leads\nyet. The confirmation creates the `domainFilterId` that constrains the follow-on\n`search_prospeo` people search.\n\nFor lookalike seed selection, route by campaign intent. In outbound/sales\nprospecting campaigns, treat \"best customer\", \"top customer\", \"target domains\",\n\"approved accounts\", \"customer domains\", and similar wording as target\naccount/customer seed asks. Use explicit user-provided target/account/customer\ndomains or company names first, then verified past-customer/account evidence from\nresearch, CRM, or proof. Never substitute the sender's current company/domain or\nemployer history as a lookalike seed for outbound unless the user explicitly\nconfirms that domain is a target/customer seed or asks for sender-company peers.\nIn job-search/application campaigns, lookalike seeds may be existing companies\nfrom the candidate's current or past employers because those companies define\nthe candidate-fit lane. If campaign intent or seed source is ambiguous, ask\nwhether the seed should be target/customer domains or current/past employers; if\nYOLO requires moving without a seed, switch to non-lookalike company filters\ninstead of inventing a seed. If the user asks for a geography like Germany,\npreserve it in account discovery where supported (`company_location_search` or\n`company_icp.geographic_markets`) and in follow-on people search\n(`person_location_search`); do not drop geography when moving from lookalike\naccounts to people leads.\n\nProspeo company/account search is useful when the source plan depends on\nwebsite traffic (`company_website_traffic`), confirmed AI Attributes including\n`pricing`, `uses_ai`, `has_api`, `has_chrome_extension`, `has_sso`,\n`has_open_source`, `has_marketplace`, `has_blog`, `has_knowledge_base`,\n`has_soc2`, `data_residency: \"EU\"`, news, awards, website pages, products,\nintegrations, key customers, Google discovery, location headcount, or\nstructured ICP. When using `company_icp.company_sizes` for micro/SMB/midmarket\nor enterprise sizing, pair it with `company_headcount_range` or rely on the MCP\nnormalization that derives the range; inspect the sample for size drift. For\nlookalike seeds passed as `seedCompanies` or `seedDomains`, omit `company_oids`;\nthe MCP backend resolves real Prospeo company IDs. Do not invent company_oids.\nFor company ICP geography, `geographic_scope` only accepts `single_country` or\n`multi_country`; put North America style regions in `geographic_markets` as\nspecific markets such as United States and Canada. Product is not a\ncompany_icp.departments value; use `titles_include` for product roles.\n`company_keywords.include/exclude` values must be at least 3 characters; use\n`artificial intelligence` instead of `AI`, or use confirmed attributes such as\n`uses_ai` when that is the actual signal. Do not use `company_intent`, and do\nnot invent unsupported support-channel filters or AI Attribute guesses like\nphone/email/chat/ticket/social.\nUse `company_key_customers` as a standalone first-pass account filter; in short,\nrun company_key_customers as a standalone first-pass. Do not combine\n`company_key_customers` with `company_website_search`, `company_icp`,\n`company_keywords`, or broad AI Attributes in the first call. Do not use `AI`,\n`API`, `GTM`, or `SaaS` as company keyword terms; use confirmed attributes or\nspell out artificial intelligence, application programming interface, go to\nmarket, and software as a service. Do not send `company_keywords.exclude`\nwithout an include keyword, and do not duplicate `company_industry` when\n`company_icp.industries` already carries the industry. For post-confirm people\nsearch, prefer `person_job_title.boolean_search` for long role synonym lists\ninstead of many `person_job_title.include` values plus broad department/seniority\nfilters.\nFor seeded company lookalikes, keep the first call simple: resolved seed\ncompany/domain plus `company_lookalike.minimum_tier` and simple confirmed\nattributes, headcount, or industry. Do not add `company_website_search`,\n`company_keywords`, or `company_icp` until the account sample proves the seed\nworks. Do not send placeholder seed names like `another approved best-customer seed`,\nand only use concrete companies or domains you actually resolved. If another approved seed is referenced but not named, ask for it or run one seed without `match_all`; do not invent a second seed from examples, competitors, or exclusions. Prefer `seedDomains`\nfor single-seed lookalikes. For multi-seed `match_all` lookalikes, use concrete company names unless you already know the exact canonical Prospeo domains; do not mix both in one seeded lookalike call. Do not combine `has_api` and `has_sso` in the first seeded lookalike call; start with `has_api`\nand refine after a valid account sample if SSO still matters. Do not send `company_website_search.exclude_keywords` without a positive website include signal.\nDo not use `AI`, `API`, `GTM`, or `SaaS` as company keyword terms.\nDo not combine `company_key_customers` with ICP, website-search, keyword,\nattribute, industry, or headcount filters until the standalone pass proves\nuseful.\n\n    After scouting, ask for a second approval on Start Import. For\n    LinkedIn engagement (`signal-discovery` internally), name how many\n    recommended posts will be scraped and the target engager/source-candidate\n    volume. N must be the smallest right-content post set that clears the source\n    target, not the default 3 promoted sample posts. For Sales Nav or Prospeo,\n    name the specific approved import lane and source lead count. Keep the\n    internal 15-row campaign-table execution slice separate from source\n    sampling.\n\nDo not call `import_leads` or `confirm_lead_list` until this second approval is\ngranted.\n\n    For Sales Nav and Prospeo, the second gate approves materializing the source\n    lead list, not importing only the internal execution slice. Use the provider\n    first-page/source sample\n    to calculate projected good fits: sampled fit rate after conservative cleanup,\n    raw pool size, source target, and expected good-fit count. If the projected\n    good-fit pool is below the campaign target, keep refining/broadening filters\n    before asking for import approval. Once it clears target, approve `import_leads`\n    with a source-list `targetLeadCount` around 1,000 by default (provider cap is\n    internal when the raw pool is larger). Only after the source list is ready\n    should `confirm_lead_list({ reviewBatchLimit: 15 })` copy confirmed rows into\n    the campaign table and return the initial campaign-table execution slice rows.\n\nFor LinkedIn engagement, the customer-facing approval card must use the exact\naction shape \"Approve scraping N recommended LinkedIn posts?\" and the chat\nsummary should be a compact `## Source Recommendation` block with:\n\n- goal: about 300 likely prospects\n- people to check: use sample math first. If there is no stronger sample, use\n  about 1,500 people who reacted or commented from the 20% starting estimate.\n- good-sign floor: keep LinkedIn posts only when at least 10% of the first\n  sample looks like real prospects; below that, move to active LinkedIn profiles\n  instead of scraping noisy reactions. Do not use the 10% floor as the\n  scrape-count denominator when the actual sample rate is higher.\n- first review: after the source list exists, add confirmed source rows to the\n  campaign and review the first 15 leads before scaling\n- a selected-post table with post author/topic, why it fits, public activity,\n  and estimated likely prospects. Calculate each row's estimated likely\n  prospects from the sampled fit rate when available, otherwise from the stated\n  starting estimate; never duplicate public activity or people-to-check counts in\n  this column.\n- total public activity, people to check, and likely prospect pool\n- next step: build the source list, add it to the campaign, and review the\n  first 15 leads before scaling\n- fallback: switch to active LinkedIn profiles if the first sample is too noisy\n  or has too few prospects\n\nSource discovery stays inline in the parent thread for normal create-campaign\nruns. Use the approved provider prompt and MCP tools sequentially; do not spawn\nsource-scout background agents. The packaged normal path installs only Message\nDrafting as a background agent. In chat, call the downstream copy stage\n`message generation`; message validation/QA is owned by Message Drafting.\n\nFor campaign-attached Signal Discovery sampling, promote/select the exact posts\nwith `select_promising_posts` before `fetch_post_engagers` so the user can see\nwhich posts are being sampled in the watched app. Use\n`selectionMode: \"replace\"` for a fresh absolute promoted set and\n`selectionMode: \"add\"` only when intentionally expanding existing promoted\nposts. Use `scrapePlanMode: \"all-selected\"` when the approval/import should use\nevery promoted post; use `scrapePlanMode: \"capacity-target\"` only when source\nmath should import the smallest set that covers a target. The watch guide should\nsay that we are checking people from these posts to confirm the right people are\nactually engaging and the source is viable.\n\nAfter confirmed source rows exist in the campaign table, do not load the\nmessage registry or any deep filter/message prompt\nbefore the filter-choice question. After `confirm_lead_list`, ask add filters\nvs skip filters immediately. Once the user answers, launch only Message Drafting\nfrom the same campaign/table basis. This kickoff is required for both answers:\n`Use filters` and `Skip filters`. If the user chooses filters, the parent\nthread moves to Filter Rules, loads the filter reference, saves rubrics, then\nasks for filter approval while Message Drafting runs. After approval, move to\nFilter Leads with `currentStep: \"apply-icp-rubric\"` and wait there while Message\nDrafting finishes or the recommendation is reviewed. If the user skips filters, start Message Drafting\nfirst, then move to Messages/message review after it has started or returned a\nready recommendation. `update_campaign({ currentStep: \"messages\" })` is not\nproof of kickoff. Enrichment/filtering and Generate Message cells wait for\nmessage approval (Message Testing only; Conversations has no template).\n\nThe Message Drafting handoff must stay lean. Include only `campaignId`,\n`workflowTableId`, a concise brief summary, concise source summary/source-use\nrule, and 3-5 sample workflow-table rows with `rowId`, name, title, company, and\nsignal. Optional: campaign name, `selectedLeadListId`, and filter choice. Do not\npaste copied row counts, brief hashes, review-batch hashes, full row ID lists,\nbroad row data, or local debug artifacts into the spawn prompt. Message Drafting\nmust load the current campaign brief/context, the full `generate-messages`\nprompt, every message asset referenced by that prompt, and\n`create-campaign-v2-validation` plus any validation assets it references.\nValidation is an internal gate before it returns the concise review-ready\nrecommendation.\n\nUse rendered Markdown for user review surfaces, not fenced code blocks. Keep\nlines short, use indexed section labels and bullets, and translate internal\nsourcing terms into plain language.\n\nOnly the first brief approval handoff should include live campaign access after\nthe readable inline content. Show the exact `create_campaign.watchHandoff.markdown`\nblock once, immediately after shell creation and before brief approval. Later\napproval gates should describe what the already-open campaign app is showing and\nrely on currentStep/watchNarration; do not print the URL again unless the user\nasks or a recovery path must replace a missing/broken link. In normal customer\nruns, do not show `Open artifact:` lines, raw filesystem paths, or local draft\nfilenames. Local artifacts are debug/UAT-only unless the user asks for them. The\nlink is for deeper inspection; never use it as a substitute for showing the\ncontent in chat.\n\nNever mention MCP namespaces, prompt chunking, plugin cache paths, missing\nlinked skill versions, runbooks, npm/package details, repo-local files, VPS or\nbrowser automation limitations, or local skill files in normal customer-facing\ncopy.\n\n## Live Watch Link Handoff\n\nWhen a campaign tool returns `watchUrl`, treat it as a user-opened app link, not\nas permission to drive the browser. A valid first handoff link must be the exact\n`create_campaign.watchUrl` value: a direct\n`/campaign-builder/{campaignId}?mode=claude|codex` URL with `workspaceId` and\n`token` query parameters for auto-login. `create_campaign.watchUrl`,\n`create_campaign({ campaignId }).watchUrl`, and `get_campaign.watchUrl` are all\nacceptable only when they return that direct campaign-builder shape. Never\nderive, shorten, reconstruct, or print a bare `/campaign-builder/{campaignId}`\nURL.\n\nNever call browser-opening tools, shell `open`, Computer Use, or in-app browser\nautomation just because a watch link exists. If `create_campaign` returns\n`watchHandoff.markdown`, print that exact value once, directly before the brief\napproval question. It will use the URL mode to say Hermes:\n\n```markdown\n> **WATCH CODEX BUILD THE CAMPAIGN LIVE**\n>\n> [Open live campaign builder]({watchUrl})\n>\n> Keep this chat open. I'll ask approval questions here before making decisions\n> that need your judgment.\n```\n\nThe rendered callout is intentional: rendered chat clients highlight the\nheadline, link, and note without treating it as a code block, and plain terminals\nstill expose the tokenized URL inside the Markdown target. Do not wrap this CTA\nin a fenced code block, replace it with a shell command, or add a\nbrowser-opening instruction.\n\nThe watch link should auto-login through the token in the URL. If the user says\nthe link lands on auth, 404, permission, blank, or a visible error state, recover\na fresh watch link once with `create_campaign({ campaignId })` or `get_campaign`\nand print that link. Do not claim the browser was opened, inspected, or\nsynchronized.\n\nNever print a placeholder watch link such as \"Open campaign\" or \"link will\nupdate once the shell is created.\" If the shell is not created yet, call\n`create_campaign` first. If `create_campaign` does not return `watchUrl`, stop\nand surface the missing watch-link error before lead sourcing.\nDo not print another watch-link handoff during source/provider selection or\nnormal approval turns unless the user explicitly asks for the link or you are\nrecovering a missing/broken URL.\n\nAfter every `update_campaign({ campaignId, currentStep })`, use\n`get_campaign_navigation_state` when available as a compact orientation check:\nmatch the saved campaign state to the expected watch-link step, explain the\ncurrent state in one sentence, and only then continue. Sender selection belongs\nat Settings after message approval and campaign setup validation. After message\nvalidation, use Settings to help the user connect or select a LinkedIn sender.\nExplain Slack reply review before launch. After sender selection, attach the\nrecommended sequence and move the watched UI to Send. Do not start the campaign\nor trigger a live send unless the user explicitly confirms that launch action\noutside UAT.\n\n## Names To Use\n\nUse these exact public names for Hermes:\n\n- Hermes command: `/sellable-create-campaign`\n- Hermes skill directory: `skills/sellable/sellable-create-campaign/SKILL.md`\n- MCP server name: `sellable`\n- Hermes MCP tool prefix: `mcp_sellable_`\n- Internal workflow prompt: `create-campaign-v2`\n\nDo not tell users to run internal subskill names. `create-campaign-v2` is only\nthe internal subskill loaded through\n`mcp_sellable_get_subskill_prompt({ subskillName: \"create-campaign-v2\" })`.\n\n## Structured Questions\n\nHermes should ask setup questions directly in chat unless the current Hermes\nsession exposes a native approval or question tool. Use a bounded approval gate\nonly for explicit approval decisions. For open text like LinkedIn URLs, company\ndomains, notes, pasted context, campaign ideas, or feedback, ask in normal chat\nand wait for the user to paste the value.\n\nCampaign setup questions are single-choice decisions. Use mutually exclusive\noptions and route blended or custom answers through a short free-text follow-up.\nCustomer-facing language should call this \"a couple setup choices\" during\nnormal campaign progress.\n\n## Host Runtime Functions\n\nTreat host capabilities as concrete functions, not prose conventions:\n\n- `ask_user`: ask directly in chat unless a Hermes-native approval or\n  question tool is visible in the current session. Use this for\n  multiple-choice intake, campaign-focus choices, source decisions, and\n  approvals. Campaign setup questions are single-choice only; do not use\n  multi-select or checkbox variants.\n- `load_subprompt`: call\n  `mcp_sellable_get_subskill_prompt({ subskillName, offset?, limit? })` and\n  continue chunks until `hasMore` is false.\n- `load_subprompt_asset`: call\n  `mcp_sellable_get_subskill_asset({ subskillName, assetPath, offset?, limit? })`\n  and continue chunks until `hasMore` is false.\n- `load_source_scout_registry`: explicit source-comparison/debug runs only; do\n  not call it in the normal create-campaign source path.\n- `load_post_find_leads_scout_registry`: call\n  `mcp_sellable_get_post_find_leads_scout_registry({})` after source\n  import and before dispatching Message Drafting only.\n- `launch_message_drafting`: if Hermes exposes a background-agent capability,\n  use the compatible Message Drafting agent. Otherwise run the same message\n  drafting branch inline in the parent session with `statusSource:\n  \"parent-thread-fallback\"`.\n\nIf a required interactive question function or MCP loader is missing, stop and\nexplain the Sellable install/reload problem. Source work uses product-native MCP\norchestration in the parent; filters also stay in the parent with MCP tools. The\nonly normal post-import background branch is Message Drafting.\n\nNever narrate local draft housekeeping to the user. If you create directories,\nsave drafts, write artifacts, or persist intermediate state, translate it into\nthe campaign benefit: consistent brief, approved lead source, reviewed message,\nor safe launch. Do not say \"persist\", \"local draft folder\", \"artifact\",\n\"mkdir\", \"campaign thesis\", or \"same approved campaign thesis\" in\ncustomer-facing progress copy.\n\n## Identity-First Campaign Setup\n\nDo not treat the active Sellable workspace as the campaign subject. The\nworkspace only tells you where the campaign will be saved. Before buyer, CTA,\nproof, or source questions, identify the person/profile or company this\ncampaign is for, plus enough current company/product context to build the\nbrief. This client/company lookup feeds `clientProspectId` or\n`senderLinkedinUrl`; it is not a connected-sender check.\n\nDo not call `mcp_sellable_list_senders`, `mcp_sellable_get_sender`, or\nsurface connected/missing sender state during setup, brief, source, filter, or\nmessage review. Sender availability belongs only to the Settings/final launch\nhandoff after message approval and the campaign setup validation slice.\n\nIf the invocation or user answer includes an existing `clientProspectId`, keep\nit as the preferred `create_campaign` identity input. If it includes a LinkedIn\nprofile URL, `/in/...` path, or bare public profile handle like `csreyes92`,\nnormalize it to `https://www.linkedin.com/in/{handle}/` and keep that URL as\n`senderLinkedinUrl` so the backend can resolve/materialize the sender prospect\nwhen the watchable campaign shell is created. Do not require a connected sender\nbefore shell creation.\n\nIf the user supplied a LinkedIn profile, website, domain, company name, or\nexplicit client prospect identity in the invocation, do one lightweight lookup\nfirst:\n\n- LinkedIn profile URL or public profile handle: normalize handles to the full\n  profile URL, then call `mcp_sellable_fetch_linkedin_profile`.\n- Non-profile URLs or company-page inputs are not enough to start this flow; ask\n  again for the person's LinkedIn profile URL or handle.\n- Existing client prospect id: use it directly and do one company/profile lookup\n  only if a LinkedIn profile URL or handle is also available.\n\nThen summarize what you found in one or two lines and ask the user to confirm\nthe current company/focus before continuing. Do not mention connected sender\navailability in this confirmation.\n\nIf the user did not provide the launch identity, ask in normal chat for the\nLinkedIn profile URL or handle. Do not ask them to choose an input type with the\nstructured question tool:\n\n```text\nWhat is your LinkedIn profile URL or handle?\n```\n\nAfter the user pastes a LinkedIn profile URL, `/in/...` path, or bare handle,\nnormalize it to `https://www.linkedin.com/in/{handle}/`, call\n`mcp_sellable_fetch_linkedin_profile`, and infer the current or most recent\ncompany from the profile. If they paste a non-profile URL or company page\ninstead, ask again for the person's LinkedIn profile URL or handle. Retain the\nnormalized profile URL as `senderLinkedinUrl` for `create_campaign`; if a\n`clientProspectId` is available, pass that instead.\n\nAfter the user confirms the company/focus, ask the full setup intake before\ninferred strategy hardens:\n\n```text\nWho should we target first?\nWhat should we pitch to prospects first?\nWhat is the strongest credibility signal we can lead with?\nHow should we find prospects: find prospects for me, use a CSV of LinkedIn\nprofiles, or use a CSV of company domains?\n```\n\nThe setup questions should use the confirmed company context so they do not feel\ngeneric. When you present a researched recommendation, introduce it as based on\nthe research you just did and keep it editable.\nDo not render a `## Campaign Identity` brief section. Use\n`## Sender and Company` for the person/company context, because the person is\nsender context, not a customer-facing campaign identity concept.\n\n### Sufficient Intake Bypass\n\nIf the invocation includes the exact `handoffMarkdown` and `binding` returned\nby a finalized `admin_onboarding_call`, call\n`mcp_sellable_validate_campaign1_kickoff_handoff` before any strategy\nquestion. Pass the expected visible revision plus the exact client, sender,\nworkspace, and engagement identity resolved for this invocation. The transport\nis inline Markdown only: reject a public Notion URL, do not fetch or scrape it,\nand do not read a hidden file or receipt.\n\nOn a valid `sellable.kickoff.campaign1.v1` result, use only the returned typed\n`intake` and `campaignBriefMarkdown` as sufficient intake. Verify the public\nsender identity with the normal lightweight profile/research completion path,\nthen create the watchable shell from that returned brief. Do not ask product,\nICP/audience, offer/CTA, proof, exclusions, or Signal Discovery questions\nagain. The LinkedIn topics, creators, posts, conversations, and participant\nbehavior are the sole source thesis. The three dream clients and buyer roles are\nqualitative fit examples only and must never become provider/account seeds.\n\nIf validation fails, stop before `create_campaign`, source search, import, or\nany other campaign mutation and show the typed validation error. Never fall\nback to surrounding agenda prose. A valid handoff skips factual discovery only:\nthe visible brief/watch approval, Find Buyers Plan approval, separate Start\nImport approval, filter and message approvals, sender/sequence setup, and final\nStart approval all remain mandatory and ordered exactly as in the normal flow.\n\nWhen the user's invocation or first answer already supplies the campaign\nidentity plus enough strategy context to draft the campaign, do not turn that\ninto an interview. Treat setup as complete when the request contains:\n\n- identity or client/company context;\n- target prospects or buyer segment;\n- offer / CTA;\n- proof or claims to use / avoid;\n- lead-source preference, supplied list, or permission to find people.\n\nIn that case, do one lightweight identity/company lookup, summarize the inferred\ndirection in one or two lines, and immediately draft the campaign brief. Do not\nask the buyer, offer, proof, or lead-source setup questions again unless a\nrequired field is missing, the supplied inputs conflict, or the campaign focus is\ngenuinely ambiguous. It is fine to include an explicit assumption line in the\nbrief; the approval gate lets the user revise it.\nBefore the brief, show: \"Accepted LinkedIn input: normalized to the required\nLinkedIn profile URL. Offer path: supplied current offer or Sellable's\nresearched recommendation; you can replace it with your current offer.\"\n\n### YOLO Mode\n\nIf the invocation or any later user message explicitly asks for \"yolo mode\",\n\"YOLO\", `--yolo`, `mode=yolo`, \"autopilot\", \"use best guesses\", \"answer for\nme\", \"use best estimates\", \"just run it\", or the user selects or presses Enter\non `Approve brief + activate YOLO mode (Recommended)`, enable YOLO mode for the\nrest of the run. Treat YOLO as `interactionMode: \"autonomous\"` plus an intake\npolicy:\n\n- If the campaign subject is missing, ask only for the LinkedIn profile URL or\n  handle in normal chat; do not continue from a non-profile URL and do not ask\n  buyer, offer, proof, source, or filter setup questions before the LinkedIn\n  identity input.\n- Treat any freeform directions already provided, or added later by the user, as\n  operator directions for the rest of the run. If directions conflict, the newest\n  user direction wins.\n- After the lightweight identity/company lookup, infer the buyer segment,\n  offer/CTA, proof to use or avoid, first lead source, filter choice, and message\n  direction with best estimates from public/company context plus operator\n  directions. State the important assumptions in the brief and watch narration.\n- Do not use structured setup questions in YOLO mode. For pre-launch approval\n  gates, choose the recommended path yourself when confidence is sufficient, show\n  the assumed choice briefly, and continue.\n- Pause only when no reasonable estimate exists, a tool requires missing credentials/data, the source/message quality floor fails, or the next action would start the live campaign without standing consent. If `launchConsent.mode` is `autopilot`, YOLO is on from the start and every gate is pre-approved.\n- Call `start_campaign` from YOLO mode only with explicit user launch confirmation or `launchConsent.mode: \"autopilot\"` (asked once; see Standing Consent in create-campaign-v2). Do not invent proof; mark proof gaps and use safer claims.\n\nBefore the identity gate, use this customer-facing shape:\n\n```text\nYou're in {workspace}.\n\nExcited to help you launch your LinkedIn outbound campaign.\n\nWe're at setup: first I'll use your LinkedIn profile to understand the company,\nthen I'll draft the campaign brief, help choose where to find buyers, check the messages, and get it ready to launch.\n\nWhat's your LinkedIn profile URL or handle?\n```\n\n## Bootstrap\n\nMCP tool access is required. First call `mcp_sellable_get_auth_status({})`\ndirectly. If that tool is unavailable, stop and say this is a Hermes\ninstall/reload problem, not a campaign problem. Tell the user to\nrun `curl -fsSL \"https://app.sellable.dev/api/v2/cli/install\" | sh` so the\npackaged MCP server, Hermes skills, and Sellable skill bundle are\ninstalled. If they want an agent-readable checklist, tell them:\n`Install Sellable CLI and skills using https://app.sellable.dev/agent-install.txt`.\nFor CLI verification, tell them to run\n`sellable --verify-only --host all --json --artifact \"$HOME/.local/sellable/app-sellable-dev/installer/.last-verify.json\"`.\nAfter that, they must fully quit and reopen Hermes before starting a new\nthread. Do not use `scripts/mcp/sellable-tool-call.mjs`, `npm run`, `node`, or\nany local harness as a fallback for this interactive skill.\nDo not mention prompt loading, local skill files, missing linked versions,\nplugin cache paths, MCP namespaces, or runbooks in customer-facing progress\nupdates.\n\n1. Call `mcp_sellable_get_auth_status({})`.\n2. If auth is not OK with `error.type === \"config\"` or `error.type === \"auth\"`,\n   the user has not signed in yet. Run first-run login through the FTUX\n   magic-link handoff. If a browser page or tool guidance gives the user a\n   manual fallback, it must be\n   `sellable auth set <token> --workspace-id <workspace_id>`. Do not instruct\n   the user to hand-edit JSON auth config.\n\n   a. Say to the user verbatim:\n\n   ```text\n   Welcome to Sellable! I'll help you launch a LinkedIn outbound campaign right here, all via chat — leads, messages, the whole thing.\n\n   First, let's connect your Sellable account:\n\n     1. Drop your email below\n     2. I'll send a magic login link to your inbox\n     3. Click it, come back here, and we'll keep going\n\n   What email should I use?\n   ```\n\n   b. Wait for the user to paste their email in normal chat. Do NOT use\n   `plain chat` / `plain chat` for this — it's free-text input.\n\n   c. Call `mcp_sellable_start_cli_login({ email })` with the email the user\n   typed.\n\n   d. If `start_cli_login` returns `ok: false`, surface `error.guidance` to the\n   user and stop. Do not retry automatically.\n\n   e. On `ok: true`, say to the user verbatim (substituting the email exactly\n   as the user typed it):\n\n   ```text\n   Magic link sent to {email}.\n\n   ─────────────────────────────────────────────\n     Your turn — check your inbox\n   ─────────────────────────────────────────────\n\n     1. Open the email from Sellable\n     2. Click the magic link\n     3. Come back here when you're done\n\n   I'll be waiting right here.\n\n     (If your team already uses Sellable, ask an admin to invite you into their shared workspace instead — that gets you straight in.)\n   ```\n\n   f. Call `mcp_sellable_wait_for_cli_login({ sessionId })` using the\n   `sessionId` returned by `start_cli_login`.\n\n   - If the result is `error.type === \"tool_timeout_guard\"`, IMMEDIATELY\n     re-call `mcp_sellable_wait_for_cli_login({ sessionId })` with the\n     SAME sessionId. Do not narrate anything to the user. Do not call\n     `start_cli_login` again — that would send a new magic link and confuse\n     them. Loop on `tool_timeout_guard` until you get a different result.\n\n   - If `error.type === \"expired\"` or `error.type === \"timeout\"`, say to the\n     user verbatim and stop:\n\n     ```text\n     That magic link expired. Run /sellable-create-campaign again to retry.\n     ```\n\n   - If `error.type === \"already_consumed\"` or any other error, surface\n     `error.guidance` and stop.\n\n   - On `ok: true`, the user is signed in and `~/.sellable/config.json` has\n     been written. Your IMMEDIATE next visible message branches on\n     `isReturningUser` from the tool result:\n\n     - If `isReturningUser === true`, use `activeWorkspaceName` when present,\n       otherwise `activeWorkspaceId`, as `{workspaceLabel}`:\n\n       ```text\n       You're in {workspaceLabel}.\n\n       Excited to help you launch your LinkedIn outbound campaign. We're at setup: first I'll use your LinkedIn profile to understand the company, then I'll draft the campaign brief, help choose where to find buyers, check the messages, and get it ready to launch.\n\n       What's your LinkedIn profile URL or handle?\n       ```\n\n     - If `isReturningUser === false`, use `activeWorkspaceName` when present,\n       otherwise `activeWorkspaceId`, as `{workspaceLabel}`:\n\n       ```text\n       You're set up in {workspaceLabel}.\n\n       Excited to help you launch your LinkedIn outbound campaign. We're at setup: first I'll use your LinkedIn profile to understand the company, then I'll draft the campaign brief, help choose where to find buyers, check the messages, and get it ready to launch.\n\n       What's your LinkedIn profile URL or handle?\n       ```\n\n     No other lines. No \"all set\", no \"signed in\", no other acknowledgement.\n\n     After the user pastes the LinkedIn profile URL or handle, proceed with the\n     identity-first campaign setup in the internal workflow prompt. Normalize handles\n     to a full profile URL, resolve it with `fetch_linkedin_profile`, and mark\n     the client/company research gate with `complete_sender_research` when that\n     protocol is required.\n\n3. If auth is not OK with `error.type === \"workspace\"` (token valid, no active\n   workspace), stop and show the returned guidance — that's not a fresh-user\n   scenario; the user needs to run `set_active_workspace`.\n4. Call customer_program with action observe and choose one entry mode from current workspace state:\n   - **EDIT** — when the request names a campaign or resolves one exact observed campaign, use that campaign id.\n   - **CONTINUE** — when one unfinished observed campaign is the clear target, resume that campaign id and preserve its saved answers, context, exclusions, reviews, and pending operation.\n   - **CREATE** — when no suitable campaign exists, proceed without a campaign id.\n   - When several plausible campaigns remain, ask one short disambiguating question using their names and current steps. Do not create another campaign while that choice is unresolved.\n   - Never accept a workspace id or campaign candidate outside the authenticated home-workspace observation.\n5. Reuse program.context.linkedinProfileUrl when present. Ask for the intended public LinkedIn profile only when it is unknown. On receipt, save it with customer_program action save_context and immediately enter the internal campaign workflow. Carry supplied campaign ideas, company/ICP/voice context, the explicit no-exclusions decision or DNC state, the selected campaign, and pending decision/operation references instead of asking again.\n6. Call bootstrap_create_campaign with flowVersion v2 and the campaign id selected by EDIT or CONTINUE, or without one for CREATE.\n   Pass model metadata only when collected by the Active Model Metadata rules\n   above. For Codex active turn metadata, pass\n   `modelMetadataSource: \"codex_turn_metadata\"`. For explicit Claude session\n   context, pass `modelMetadataSource: \"claude_session_context\"`. For explicit\n   user-confirmed Claude `/status` or `/model` output, pass\n   `modelMetadataSource: \"user_confirmed\"` only when it includes both model and\n   effort.\n7. If `safeToProceed !== true`, stop and show `blockingErrors` + `nextStep`.\n8. If `modelQuality.status === \"warn\"`, show `modelQuality.message` before any\n   setup/research and wait for the user to switch or explicitly continue. If\n   `modelQuality.status === \"unknown\"`, continue without asking the user to\n   switch models.\n\n## Execute Workflow\n\n1. Load canonical prompt via\n   `mcp_sellable_get_subskill_prompt({ subskillName: \"create-campaign-v2\" })`.\n2. Load the canonical workflow config via\n   `mcp_sellable_get_subskill_asset({ subskillName: \"create-campaign-v2\", assetPath: \"core/flow.v2.json\" })`.\n   Treat the returned JSON as the active state machine. Do not read repo-local\n   copies of this file; packaged Hermes runs must use the MCP\n   asset loader so they share the same config.\n3. Follow that prompt and workflow config exactly.\n4. For filter and message setup, keep the parent thread as a lean orchestrator.\n   The only normal background agent is `post-find-leads-message-scout` for\n   Message Drafting. Both post-import choices must launch Message Drafting.\n   When filters are chosen, launch Message Drafting, then keep filters in the\n   parent thread: load `references/filter-leads.md`, draft production rubrics,\n   call `save_rubrics`, ask filter approval, and then join Message Drafting for\n   template review. When filters are skipped, launch only Message Drafting\n   before treating the campaign as in Messages/message review.\n5. For message generation, keep the parent thread as a lean orchestrator and\n   use the `post-find-leads-message-scout` compatibility agent for Message\n   Drafting whenever the host exposes it\n   and the current host policy allows agent launch. The worker must load the\n   full `mcp_sellable_get_subskill_prompt({ subskillName: \"generate-messages\" })`\n   prompt, every required message asset named by `generate-messages` Mode 0\n   through `mcp_sellable_get_subskill_asset`, and before returning\n   `mcp_sellable_get_subskill_prompt({ subskillName: \"create-campaign-v2-validation\" })`\n   as the final internal validation gate.\n   In Codex, the filter-choice answer is the campaign-scoped go-ahead to use\n   this single Message Drafting background agent in step-wise and YOLO modes.\n   Do not ask a separate question to start it. If the named custom agent is not\n   available, spawn a generic background agent with `model: \"gpt-5.6-sol\"` and\n   `reasoning_effort: \"high\"` using the same lean campaign/table basis. If no\n   background-agent tool is callable, start the same full message branch inline\n   before filter drafting or skip-filter message review and record it as\n   `statusSource: \"parent-thread-fallback\"`.\n   After a spawned branch starts, persist rich proof under\n   `watchNarration.workerDetails.messageDraftBuilder` with\n   `statusSource: \"branch\"`, `status: \"branch-running\"`, `runId`, timestamps,\n   selectedLeadListId, workflowTableId, filterChoice, and reviewBatchRowHash or\n   reviewBatchRowIds. `workerStatuses.messageDraftBuilder` is only the optional\n   simple badge (`running`); never put rich proof under `workerStatuses` or use\n   a `messageDrafting` key.\n   Do not use any alternate, examples-only, or local-artifact message prompt. Message review and\n   message QA require Message Drafting output:\n   do not draft from a checklist, local markdown artifact, or parent-thread\n   intuition. Use campaign state, campaign brief content, selected source state, and\n   initial campaign-table execution slice rows as the source of truth; do not read stale local\n   markdown such as `message-validation.md`, inspect the database directly, or\n   synthesize local validation artifacts from general knowledge. The handoff to\n   Message Drafting should pass lean basis only, not hashes, counts, or a long\n   row-id list; the branch loads current brief/context, the full\n   `generate-messages` prompt, all required message assets, and\n   `create-campaign-v2-validation`. The message recommendation handoff is\n   labeled Markdown, not raw JSON. Do not render fallback sample, concerns, or a\n   QA receipt on the normal happy path.\n6. Create the campaign shell early with the v1 brief so the user can open the\n   watch link and see useful setup state immediately. Materialize the approved\n   source list, copy confirmed rows into the campaign, and internally process the\n   first campaign-table execution slice after the source is attached to the\n   campaign; do not load prospect-setup registries/prompts before asking add\n   filters vs skip filters. Once the user answers, launch only Message Drafting.\n   If filters are chosen, draft/save filters in the parent thread. Do not queue workflow cells, attach a\n   sequence, or start until saved filters and the\n   message template/token rules are approved. When filters are chosen, immediately\n   call `mcp_sellable_update_campaign({ campaignId, enableICPFilters: true, currentStep: \"create-icp-rubric\", watchNarration })`\n   so the watched app moves to Filter Rules while the parent drafts/saves\n   rubrics and Message Drafting runs.\n   After rubrics save, keep Filter Rules visible for approval; after approval,\n   move to Filter Leads with `currentStep: \"apply-icp-rubric\"` and wait there\n   while Message Drafting finishes or the template is approved. After template\n   approval and bounded scoring, a `0/N` pass result must run the\n   sample-validation zero-pass rule-relaxability audit before any lead-source\n   revision; the three allowed recoveries are rubric revision, fresh\n   same-source sample, or source revision.\n   If filters are skipped, launch Message Drafting before moving to\n   Messages/message review; updating `currentStep` to `messages` is not proof\n   that the background worker started. Queue the bounded campaign-table\n   execution-slice `enrichCellId` cells only after message approval. Move to the\n   generated-row Messages review only after at least one review row passes and\n   one generated message is ready.\n   Do not ask the user to approve the brief before shell creation unless they\n   explicitly requested a no-write draft; the shell itself is the review surface.\n7. The main thread owns watch navigation. Call\n   `mcp_sellable_update_campaign({ campaignId, currentStep })` before major\n   visible work so the user can watch progress in the app: `create-offer` for\n   the brief, `pick-provider` or the selected provider step while sourcing,\n   `filter-choice` after source rows are copied into the campaign table, `create-icp-rubric` as soon\n   as filters are chosen and while saved filters await approval,\n   `apply-icp-rubric` after filter approval while message approval is pending and while bounded enrichment/filter scoring runs after approval, `validate-sample` only as a recovery/legacy\n   observation state,\n   `auto-execute-messaging` after at least one row passes and initial campaign-row\n   messages are being generated or reviewed, `awaiting-user-greenlight` only\n   after generated campaign-row messages are approved and the Prepare Messages\n   job has reported compact checked/prepared/stop status, `settings` for sender\n   selection, `sequence` after sender attach, and `send` once the recommended\n   sequence is attached. Do not advance the step backward.\n8. Keep `selectedLeadListId` as the source list and `workflowTableId` as the\n   campaign table. Do not use disk files as the post-mint source of truth.\n9. Do not ask the user to run another command.\n\n## Fallback\n\nIf subskill lookup fails, use\n`mcp_sellable_search_subskill_prompts({ query: \"create-campaign-v2\" })`,\nthen retry `get_subskill_prompt`.\n"
     },
     {
       "id": "refill-sends",

package/lib/sellable-agent/default-profile-bundles/shared/skills/sellable/sellable-create-campaign/SKILL.md

@@ -235,8 +235,8 @@ preparation, the target is wrong, or status shows the wrong campaign/table, call
 `cancel_campaign_message_preparation`; otherwise do not cancel a healthy prepare
 run. Never call `start_campaign` from message preparation; final launch remains
 a separate explicit user greenlight.
-Use Template is the default message path; AI Generated is only an explicit
-opt-out.
+First messages use Conversations or Message Testing; name the one you pick
+as create-campaign-v2 `references/message-approach.md` says.
 
 ## DNC And Blocklist Handling
 
@@ -582,7 +582,7 @@ Drafting finishes or the recommendation is reviewed. If the user skips filters,
 first, then move to Messages/message review after it has started or returned a
 ready recommendation. `update_campaign({ currentStep: "messages" })` is not
 proof of kickoff. Enrichment/filtering and Generate Message cells wait for
-message approval. AI Generated is an explicit opt-out from the template path.
+message approval (Message Testing only; Conversations has no template).
 
 The Message Drafting handoff must stay lean. Include only `campaignId`,
 `workflowTableId`, a concise brief summary, concise source summary/source-use

package/lib/sellable-agent/fly-admin-image/Dockerfile

@@ -44,7 +44,7 @@ ARG STRIPE_CLI_PACKAGE=@stripe/cli-linux-x64@1.45.0
 ARG STRIPE_CLI_INTEGRITY=sha512-1ZhoPpoweYfynqsvhCLlTjZ7lPz5IKtxqAMT5MBy6zrwLRTP9x0T6r8h/jLYL8lRH1c7zC/6X6/XUu2V+r9Bog==
 ARG DEFAULT_PROFILE_BUNDLE_FIXTURE_VERSION=1
 ARG DEFAULT_PROFILE_BUNDLE_VERSION=4
-ARG DEFAULT_PROFILE_BUNDLE_DIGEST=492e9eded087d099f8fd27c8e33568d61c8dc93b507e5d15f71eadeb04aa1bae
+ARG DEFAULT_PROFILE_BUNDLE_DIGEST=9c5caecdb290b5f26a5ed3f701c5ff190f6e6387a4455346e12d7bc17d77e1b1
 
 COPY --from=slack-pp-cli-builder --chmod=0555 /out/slack-pp-cli /usr/local/bin/slack-pp-cli
 
@@ -169,7 +169,7 @@ COPY fly-admin-image/start-admin-runtime /usr/local/lib/sellable-agent/admin-run
 COPY fly-customer-image/customer-runtime.mjs /usr/local/lib/sellable-agent/fly-customer-image/customer-runtime.mjs
 COPY hermes-first-welcome.mjs /usr/local/lib/sellable-agent/hermes-first-welcome.mjs
 COPY fly-customer-image/hermes-runs-client.mjs /usr/local/lib/sellable-agent/fly-customer-image/hermes-runs-client.mjs
-COPY fly-customer-image/endpoint-model-selection.mjs fly-customer-image/runs-api-connections.mjs fly-customer-image/claude-code-runs-api.mjs fly-customer-image/claude-code-mcp-session.mjs fly-customer-image/openai-runs-client.mjs fly-customer-image/runs-api-health-check.mjs /usr/local/lib/sellable-agent/fly-customer-image/
+COPY fly-customer-image/endpoint-model-selection.mjs fly-customer-image/runs-api-connections.mjs fly-customer-image/claude-code-runs-api.mjs fly-customer-image/claude-code-mcp-session.mjs fly-customer-image/openai-runs-client.mjs fly-customer-image/runs-api-health-check.mjs fly-customer-image/public-endpoint-guard.mjs fly-customer-image/workspace-connection-client.mjs /usr/local/lib/sellable-agent/fly-customer-image/
 COPY fly-customer-image/opener-stage-execution.mjs /usr/local/lib/sellable-agent/fly-customer-image/opener-stage-execution.mjs
 COPY fly-customer-image/endpoint-uat-completion-gate.mjs /usr/local/lib/sellable-agent/fly-customer-image/endpoint-uat-completion-gate.mjs
 COPY fly-customer-image/customer-runtime-phase-telemetry.mjs /usr/local/lib/sellable-agent/fly-customer-image/customer-runtime-phase-telemetry.mjs
@@ -277,6 +277,8 @@ RUN set -eux; \
       /usr/local/lib/sellable-agent/fly-customer-image/runs-api-connections.mjs \
       /usr/local/lib/sellable-agent/fly-customer-image/claude-code-runs-api.mjs \
       /usr/local/lib/sellable-agent/fly-customer-image/claude-code-mcp-session.mjs \
+      /usr/local/lib/sellable-agent/fly-customer-image/public-endpoint-guard.mjs \
+      /usr/local/lib/sellable-agent/fly-customer-image/workspace-connection-client.mjs \
       /usr/local/lib/sellable-agent/fly-customer-image/opener-stage-execution.mjs \
       /usr/local/lib/sellable-agent/fly-customer-image/endpoint-uat-completion-gate.mjs \
       /usr/local/lib/sellable-agent/admin-native-gateway-supervisor.mjs \