@sellable/install 0.1.326 → 0.1.327

package/lib/runtime-verify.mjs

@@ -11,13 +11,25 @@ export const REQUIRED_SELLABLE_MCP_TOOLS = [
   "start_cli_login",
   "wait_for_cli_login",
   "bootstrap_create_campaign",
+  "bootstrap_find_leads",
+  "get_find_leads_run",
+  "update_find_leads_run",
+  "wait_for_find_leads_run",
+  "cancel_find_leads",
+  "reissue_find_leads_watch_link",
+  "preflight_find_leads_provider",
   "get_subskill_prompt",
   "get_subskill_asset",
   "search_subskill_prompts",
   "create_campaign",
   "import_leads",
+  "search_sales_nav",
+  "search_prospeo",
+  "search_signals",
+  "select_promising_posts",
   "confirm_lead_list",
   "wait_for_lead_list_ready",
+  "export_table_csv",
   "wait_for_campaign_table_ready",
   "update_campaign",
   "update_campaign_brief",
@@ -76,6 +88,14 @@ export const CREATE_CAMPAIGN_SMOKE_CALLS = [
       limit: 1200,
     },
   },
+  {
+    name: "get_subskill_prompt",
+    arguments: {
+      subskillName: "find-leads-v2",
+      offset: 0,
+      limit: 1200,
+    },
+  },
   {
     name: "get_subskill_prompt",
     arguments: {
@@ -117,6 +137,15 @@ export const CREATE_CAMPAIGN_SMOKE_CALLS = [
       limit: 1200,
     },
   },
+  {
+    name: "get_subskill_asset",
+    arguments: {
+      subskillName: "find-leads-v2",
+      assetPath: "core/flow.v1.json",
+      offset: 0,
+      limit: 1200,
+    },
+  },
 ];
 
 function collectStderrLines(stream) {
@@ -343,7 +372,7 @@ async function verifyCreateCampaignSmoke({
       ok: false,
       missingTools,
       calls,
-      error: `Missing smoke tool(s): ${missingTools.join(", ")}`,
+      error: `Missing or stale Sellable MCP tool(s): ${missingTools.join(", ")}. Reinstall @sellable/install and @sellable/mcp, restart or reload the host, then retry Find Leads.`,
       startedAt,
       completedAt: new Date().toISOString(),
     };
@@ -662,7 +691,7 @@ async function verifySellableMcpRuntimeOnce({
         ),
         calls: [],
         error:
-          "Skipping create-campaign smoke because required MCP tools are missing.",
+          "Sellable MCP is missing required tools. Reinstall @sellable/install and @sellable/mcp, restart or reload the host, then retry Find Leads.",
         startedAt: new Date().toISOString(),
         completedAt: new Date().toISOString(),
       };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.326",
+  "version": "0.1.327",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code, Codex, and Hermes",
   "bin": {
@@ -15,8 +15,7 @@
     "lib",
     "agents",
     "skill-templates",
-    "README.md",
-    "HERMES-SLACK-PROFILE-SCOPING.md"
+    "README.md"
   ],
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.25.2",

package/skill-templates/create-campaign.md

@@ -721,7 +721,7 @@ Treat host capabilities as concrete functions, not prose conventions:
   import and before dispatching Message Drafting only.
 - `launch_message_drafting`: Claude Code uses `Task` with `subagent_type`
   `post-find-leads-message-scout` when listed; Codex uses the returned
-  compatibility agent or a generic `gpt-5.6-sol` / `high` Message Drafting agent.
+  compatibility agent or a generic `gpt-5.5` / `xhigh` Message Drafting agent.
 
 If a required interactive question function or MCP loader is missing, stop and
 explain the Sellable install/reload problem. Source work uses product-native MCP
@@ -1082,8 +1082,8 @@ updates.
    In Codex, the filter-choice answer is the campaign-scoped go-ahead to use
    this single Message Drafting background agent in step-wise and YOLO modes.
    Do not ask a separate question to start it. If the named custom agent is not
-   available, spawn a generic background agent with `model: "gpt-5.6-sol"` and
-   `reasoning_effort: "high"` using the same lean campaign/table basis. If no
+   available, spawn a generic background agent with `model: "gpt-5.5"` and
+   `reasoning_effort: "xhigh"` using the same lean campaign/table basis. If no
    background-agent tool is callable, start the same full message branch inline
    before filter drafting or skip-filter message review and record it as
    `statusSource: "parent-thread-fallback"`.

package/skill-templates/create-evergreen-campaigns.md

@@ -437,7 +437,7 @@ fallback only when app thread tools are unavailable; the receipt must include
 `fallbackReason`, or backend verify rejects it.
 When visible Codex app thread tools are unavailable but local Codex CLI is
 available, the accepted durable streaming-worker command shape is:
-`codex -a never -s danger-full-access -c model_reasoning_effort=high exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
+`codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
 The approval, sandbox, and reasoning-effort config flags must come before the
 `exec` subcommand for Codex CLI builds that expose `-a`/`-s`/`-c` only at top
 level. `--skip-git-repo-check` belongs after `exec` because current customer and VPS Codex CLI builds expose it
@@ -447,26 +447,26 @@ forms fail on current customer CLI installs. Pipe the lane packet prompt on
 stdin, require the worker to write `workerDispatch.receiptArtifactHint`, and
 pass exactly one lane packet per worker.
 When launching durable Codex CLI workers from an automation parent, pass an
-explicit supported worker model and explicit `high` reasoning effort instead
+explicit supported worker model and explicit `xhigh` reasoning effort instead
 of relying on the Codex CLI defaults. Use the parent runtime model when known,
 for example:
-`codex -a never -s danger-full-access -c model_reasoning_effort=high exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
+`codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
 In Codex CLI, the parent runtime model is visible in the run header as
 `model: <model-name>`. Copy that exact model string into child worker launches
-first. If the parent header says `model: gpt-5.6-sol`, launch workers with
-`-m gpt-5.6-sol` plus `-c model_reasoning_effort=high`; do not invent or probe
+first. If the parent header says `model: gpt-5.5`, launch workers with
+`-m gpt-5.5` plus `-c model_reasoning_effort=xhigh`; do not invent or probe
 nearby aliases such as `gpt-5.3-codex`, `gpt-5.2`, `gpt-5-codex`,
 `codex-latest`, or `codex-mini-latest` before trying the exact parent model. A
-one-line probe must include the same `-c model_reasoning_effort=high` override
+one-line probe must include the same `-c model_reasoning_effort=xhigh` override
 and count as supported only when it exits 0 and returns the requested output; a
 session header followed by a `not supported` error is rejected, not accepted.
 Do not rely on the Codex CLI default model or default reasoning effort; some
-customer and VPS installs default to unavailable model aliases or to reasoning
-below `high`. `-m gpt-5.6-sol` alone is not enough. If a child worker reports GPT 5.6-Sol
-with reasoning below `high`, treat that as a launcher bug, relaunch with the explicit
-`high` config before mutation, and do not ask the user to continue through the
+customer and VPS installs default to unavailable model aliases or to `high`
+reasoning. `-m gpt-5.5` alone is not enough. If a child worker reports GPT 5.5
+with `high` reasoning, treat that as a launcher bug, relaunch with the explicit
+`xhigh` config before mutation, and do not ask the user to continue through the
 model-quality warning. If the parent cannot identify a supported worker model
-and launch it with `high` reasoning, stop with
+and launch it with `xhigh` reasoning, stop with
 `blocked: worker_model_unavailable` before mutation.
 When wrapping multiple local Codex CLI workers in a shell launcher, run the
 wrapper with `/bin/bash -lc` or another explicitly chosen portable shell. Do not
@@ -479,7 +479,7 @@ Do not embed `<<'WORKER_PROMPT'` heredocs inside a single quoted or double
 quoted `/bin/bash -lc '...'` command string; nested quoting is brittle and can
 truncate the first worker before mutation. For multi-worker launchers, write one
 plain prompt file per lane under the current run directory, then start each
-worker with `codex -a never -s danger-full-access -c model_reasoning_effort=high exec --skip-git-repo-check -m "$WORKER_MODEL" -C "$REPO" -o
+worker with `codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m "$WORKER_MODEL" -C "$REPO" -o
 "$worker_final_file" - < "$worker_prompt_file"`. Keep launcher shell variables
 double-quoted and keep the prompt heredoc only in a standalone script/prompt-file
 write step, not inside an already quoted shell argument. If the first launcher
@@ -585,7 +585,7 @@ launchers, write the same prompt body to `<worker-prompt-file>` and launch the
 worker with stdin redirected from that file:
 
 ```
-codex -a never -s danger-full-access -c model_reasoning_effort=high exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
+codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
 Use $sellable:create-campaign as the governing campaign workflow for this one lane worker.
 Use the evergreen plan/packet below only for lane scope, source metadata,
 postconditions, side-effect caps, and durable receipt proof.
@@ -632,10 +632,10 @@ Do not launch, start, schedule, send, or use paid InMail.
 For filter proof, durable receipt status must be `filterDecisionReceipt.status:"applied"` only; never `completed`, `confirmed`, `done`, or aliases.
 For generated messages, `update_cell` is allowed only for the semantic Approved checkbox. Never use `update_cell` for generated message text/body/sample copy. Bad copy requires `revise_message_template_and_rerun` or brief/template revision plus Generate Message rerun. Any generated-message cell override is `blocked: generated_message_cell_override`.
 If `bootstrap_create_campaign.modelQuality.status === "warn"` because the child
-worker reports GPT 5.6-Sol with reasoning below `high`, that is a parent launcher
+worker reports GPT 5.5 with `high` reasoning, that is a parent launcher
 configuration bug, not an operator approval path inside the worker. Stop before
 mutation, tell the parent to relaunch this lane with
-`-c model_reasoning_effort=high`, and do not mark the worker goal complete.
+`-c model_reasoning_effort=xhigh`, and do not mark the worker goal complete.
 Complete only this lane. Do not end with narration only. Before your final
 response, run a local file-existence and JSON self-check for
 <receiptArtifactPath>. If the lane succeeded, write the canonical success
@@ -656,7 +656,7 @@ receipt, or an accepted Post Engagers no-source blocked/no-op receipt.
 WORKER_PROMPT
 
 # Multi-worker launcher equivalent:
-codex -a never -s danger-full-access -c model_reasoning_effort=high exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - < <worker-prompt-file>
+codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - < <worker-prompt-file>
 ```
 
 If any placeholder cannot be filled from the current plan, matching

package/skill-templates/find-leads.md

@@ -0,0 +1,57 @@
+---
+name: find-leads
+description: Find or source prospects, build and watch a live Sellable lead list, and export the finished list without creating a campaign.
+visibility: public
+allowed-tools:
+  - mcp__sellable__get_auth_status
+  - mcp__sellable__start_cli_login
+  - mcp__sellable__wait_for_cli_login
+  - mcp__sellable__get_active_workspace
+  - mcp__sellable__list_workspaces
+  - mcp__sellable__set_active_workspace
+  - mcp__sellable__get_subskill_prompt
+  - mcp__sellable__get_subskill_asset
+  - mcp__sellable__search_subskill_prompts
+  - mcp__sellable__get_provider_prompt
+  - mcp__sellable__bootstrap_find_leads
+  - mcp__sellable__get_find_leads_run
+  - mcp__sellable__update_find_leads_run
+  - mcp__sellable__wait_for_find_leads_run
+  - mcp__sellable__cancel_find_leads
+  - mcp__sellable__reissue_find_leads_watch_link
+  - mcp__sellable__preflight_find_leads_provider
+  - mcp__sellable__lookup_sales_nav_filter
+  - mcp__sellable__search_sales_nav
+  - mcp__sellable__search_prospeo
+  - mcp__sellable__search_signals
+  - mcp__sellable__select_promising_posts
+  - mcp__sellable__import_leads
+  - mcp__sellable__wait_for_lead_list_ready
+  - mcp__sellable__get_rows_minimal
+  - mcp__sellable__export_table_csv
+---
+
+# Sellable Find Leads
+
+Use this public command when the user asks to find or source prospects, build a lead list,
+watch the list fill in real time, review leads, or export the list.
+It works without an existing campaign.
+
+## Load the canonical workflow
+
+1. Call `mcp__sellable__get_auth_status({})` and complete login/workspace setup
+   if required.
+2. Load `mcp__sellable__get_subskill_prompt({ subskillName: "find-leads-v2" })`.
+   Continue chunks until `hasMore` is false.
+3. Load `mcp__sellable__get_subskill_asset({ subskillName: "find-leads-v2",
+   assetPath: "core/flow.v1.json" })`.
+4. Execute that prompt and flow as the operational source of truth.
+
+Do not emulate the workflow from memory or local files. If prompt or asset
+loading fails, use `search_subskill_prompts({ query: "find-leads-v2",
+includePublic: true, includeInternal: true })`, retry once, then give the
+workflow's reinstall/reload guidance.
+
+Keep approval questions in the current chat. A source-plan approval allows only
+the bounded provider search. A later import approval is required before rows
+are materialized. Export uses the source list directly.

package/skill-templates/refill-sends-v2.md

@@ -1,9 +1,9 @@
 ---
 name: refill-sends-v2
 description: Execute refill sends v2 through the fenced evergreen refill loop, with dry-run and resume support.
-visibility: internal
+visibility: public
 allowed-tools:
-  - mcp__sellable__refill_sends
+  - mcp__sellable__refill_sends_v2
   - mcp__sellable__get_refill_plan_v2
   - mcp__sellable__get_subskill_prompt
   - mcp__sellable__get_subskill_asset
@@ -24,7 +24,7 @@ Host command names:
 - Claude Code: `/sellable:refill-sends-v2`
 - Codex: `$sellable:refill-sends-v2`
 
-`refill_sends` is the execution surface. In real-run mode it starts or
+`refill_sends_v2` is the execution surface. In real-run mode it starts or
 resumes a fenced refill run, reads a fresh packet, executes only the packet's
 named bounded work, verifies the result, and returns either a terminal report, a
 blocked report, or an in-progress resume handle. In dry-run mode it stays
@@ -40,19 +40,19 @@ with `WORKSPACE_REQUIRED`; do not switch the shared active workspace.
 For a real refill run:
 
 ```text
-refill_sends({ workspaceId, intent:"auto", senderIds?, approvalMode? })
+refill_sends_v2({ workspaceId, intent:"auto", senderIds?, approvalMode? })
 ```
 
 For read-only inspection:
 
 ```text
-refill_sends({ workspaceId, dryRun:true, intent:"auto", senderIds? })
+refill_sends_v2({ workspaceId, dryRun:true, intent:"auto", senderIds? })
 ```
 
 To resume an in-progress run, pass the handle back exactly:
 
 ```text
-refill_sends({ workspaceId, runId, fence })
+refill_sends_v2({ workspaceId, runId, fence })
 ```
 
 If a stale handle loses the lease, the tool reports the holder status and the