@sellable/install 0.1.101 → 0.1.103

package/README.md

@@ -16,7 +16,8 @@ sellable create
 Campaign creation itself runs inside Claude Code or Codex, where the Sellable
 MCP tools and approval flow are available.
 
-If you do not pass a token, the installer prompts you for one and shows where to get it.
+Install is auth-free by default. If you do not pass a token, the agent handles
+Sellable sign-in on the first campaign run with a magic-link handoff.
 
 The installer uses package stdio MCP by default:
 
@@ -29,13 +30,14 @@ MCP server also checks npm at startup and during `get_auth_status`, caching the
 result at `~/.sellable/update-check.json` so users are prompted to rerun the
 latest installer only when an update is actually available.
 
-Get a Sellable API token from:
+For CI/scripted installs, get a Sellable API token from:
 
 ```text
 https://app.sellable.dev/settings
 ```
 
-Then paste it into the installer, or pass it with `--token` / `SELLABLE_TOKEN`.
+Then pass it with `--token` / `SELLABLE_TOKEN` plus `--workspace-id` /
+`SELLABLE_WORKSPACE_ID`.
 
 Auth is stored once at:
 

package/bin/sellable-install.mjs

@@ -40,7 +40,7 @@ function getMcpVersion() {
   } catch {}
   return "latest";
 }
-const CODEX_PLUGIN_VERSION = "0.1.30";
+const CODEX_PLUGIN_VERSION = "0.1.31";
 const CODEX_PLUGIN_COMPAT_VERSIONS = [
   "0.1.8",
   "0.1.9",
@@ -508,6 +508,8 @@ function codexPluginMcp(opts) {
 
 const CREATE_CAMPAIGN_ALLOWED_TOOLS = [
   "mcp__sellable__get_auth_status",
+  "mcp__sellable__start_cli_login",
+  "mcp__sellable__wait_for_cli_login",
   "mcp__sellable__bootstrap_create_campaign",
   "mcp__sellable__get_subskill_prompt",
   "mcp__sellable__get_subskill_asset",
@@ -518,7 +520,6 @@ const CREATE_CAMPAIGN_ALLOWED_TOOLS = [
   "mcp__sellable__get_active_workspace",
   "mcp__sellable__list_senders",
   "mcp__sellable__get_sender",
-  "mcp__sellable__enrich_sender",
   "mcp__sellable__complete_sender_research",
   "mcp__sellable__fetch_linkedin_profile",
   "mcp__sellable__fetch_linkedin_posts",
@@ -556,7 +557,6 @@ const CREATE_CAMPAIGN_ALLOWED_TOOLS = [
   "mcp__sellable__load_csv_linkedin_leads",
   "mcp__sellable__load_csv_domains",
   "mcp__sellable__queue_cells",
-  "mcp__sellable__generate_messages",
   "mcp__sellable__get_campaign_messages_preview",
   "mcp__sellable__attach_sequence",
   "mcp__sellable__attach_recommended_sequence",
@@ -646,6 +646,31 @@ data, compare sources by source volume, sampled ICP fit, activity/warmth
 signals, cleanup risk, and confidence basis. If a user asks for a forecast,
 label it explicitly as not estimated from this run.
 
+Before any provider prompt, search, source scout, or signal-discovery call,
+show a short source-plan gate and ask for approval. This first approval
+authorizes scouting/search only. The gate should say:
+
+- given this campaign, the viable source options
+- the recommended first lane
+- why that lane fits the buyer, offer, and likely public activity
+- what will be tested next
+- the fallback lane if relevant posts or ICP engagement look thin
+- that approval authorizes scouting/search only, not lead import or sending
+
+Do not surface blanket source heuristics as product copy. Make the
+recommendation specific to the campaign. If Signal Discovery is recommended,
+name the exact post themes you will search. If relevant public conversations
+look unlikely, recommend the specific Sales Nav or Prospeo lane instead and say
+why. Do not call \`search_signals\`, \`search_sales_nav\`, \`search_prospeo\`,
+\`fetch_post_engagers\`, or provider-scoped subagents until the user approves this
+source plan or explicitly chooses a different source.
+
+After scouting, ask for a second approval on the concrete source action. For
+Signal Discovery, name how many selected posts will be scraped, the target
+engager/source-candidate volume, and the bounded review-batch size. For Sales
+Nav or Prospeo, name the specific approved import lane. Do not call
+\`import_leads\` or \`confirm_lead_list\` until this second approval is granted.
+
 For campaign-attached Signal Discovery sampling, promote/select the exact posts
 with \`select_promising_posts\` before \`fetch_post_engagers\` so the user can see
 which posts are being sampled in the watched app. The watch guide should say
@@ -943,15 +968,20 @@ updates.
    queue workflow cells, attach a sequence, or start until filter choice is
    resolved, rubrics are saved when filters are enabled, template/token rules
    are approved on the default Use Template path, and the approved message set
-   is synced into the campaign brief. After rubrics save, pause and say the fit
-   rules are saved; approve the message template next; after approval, queue the
-   bounded review-batch \`enrichCellId\` cells to kick off enrichment/filtering.
+   is synced into the campaign brief. When filters are approved, immediately
+   call \`mcp__sellable__update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })\`
+   so the watched app moves to Filter Rules while rubrics are drafted/saved.
+   After rubrics save, move the watched app to \`apply-icp-rubric\` / Filter
+   Leads and say the fit rules are saved; approve the message template next;
+   after approval, queue the bounded review-batch
+   \`enrichCellId\` cells to kick off enrichment/filtering.
    Product Generate Message cells must not run from the background template
    path before that template/token approval. AI Generated uses the
    product's AI-generated path and cancels or ignores the background template
    draft.
 6. The main thread owns watch navigation: use \`filter-choice\` after the 15-row
-   review batch, \`messages\` for the Use Template / AI Generated mode choice,
+   review batch, \`create-icp-rubric\` as soon as filters are approved,
+   \`apply-icp-rubric\` after rubrics save, \`messages\` for the Use Template / AI Generated mode choice,
    \`auto-execute-messaging\` for approved message work or the product's
    AI-generated path, and \`awaiting-user-greenlight\` for the final handoff.
    \`validate-sample\` is recovery/legacy only if reached.
@@ -1153,18 +1183,17 @@ show you the draft next so you can approve it or change it.
 Good opening:
 
 \`\`\`text
-I’ll help you launch this as a Sellable campaign. First I’ll confirm who we’re
-sending from and which company this is for, then I’ll turn that into a campaign
-brief before anything is created.
+I’ll help you launch this as a Sellable campaign. First I’ll resolve the
+client/company this campaign is for, then I’ll turn that into a campaign brief
+before any leads are imported or anything can send.
 \`\`\`
 
 Good identity setup:
 
 \`\`\`text
-I’ll check whether you already have a connected sender here. If I find one, I’ll
-ask whether that’s you and whether this campaign is for that company. If not,
-just paste your LinkedIn URL or company domain and I’ll look it up before we
-keep going.
+I’ll confirm the client/company this campaign is for before we pick the target,
+offer, proof, and lead source. Paste a LinkedIn profile or company website and
+I’ll resolve the campaign identity before the setup choices.
 \`\`\`
 
 Bad:
@@ -2365,7 +2394,9 @@ async function main() {
       );
       console.log(`✓ Token saved to ${authPath()}`);
       console.log(`  apiUrl: ${apiUrl}`);
-      console.log(`  Run /sellable:create-campaign in your agent to continue.`);
+      console.log(`  Continue in your agent:`);
+      console.log(`    Claude Code: /sellable:create-campaign`);
+      console.log(`    Codex: $sellable:create-campaign`);
       process.exit(0);
     }
     if (rawArgs[0] === "uninstall") {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.101",
+  "version": "0.1.103",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {
@@ -8,7 +8,7 @@
   },
   "scripts": {
     "sync-skills": "node scripts/sync-skill-templates.mjs",
-    "prepublishOnly": "node scripts/sync-skill-templates.mjs"
+    "prepublishOnly": "node scripts/sync-skill-templates.mjs && cd ../.. && npm run validate:sellable-skills"
   },
   "files": [
     "bin",

package/skill-templates/create-campaign.md

@@ -16,7 +16,6 @@ allowed-tools:
   - mcp__sellable__get_active_workspace
   - mcp__sellable__list_senders
   - mcp__sellable__get_sender
-  - mcp__sellable__enrich_sender
   - mcp__sellable__complete_sender_research
   - mcp__sellable__fetch_linkedin_profile
   - mcp__sellable__fetch_linkedin_posts
@@ -54,7 +53,6 @@ allowed-tools:
   - mcp__sellable__load_csv_linkedin_leads
   - mcp__sellable__load_csv_domains
   - mcp__sellable__queue_cells
-  - mcp__sellable__generate_messages
   - mcp__sellable__get_campaign_messages_preview
   - mcp__sellable__attach_sequence
   - mcp__sellable__attach_recommended_sequence
@@ -63,7 +61,10 @@ allowed-tools:
 
 # Sellable Create Campaign
 
-Use this as the customer-facing entrypoint for Sellable campaign creation.
+Use this as the customer-facing public wrapper for Sellable campaign creation.
+It bootstraps auth and host capabilities, then loads the internal
+`create-campaign-v2` workflow prompt and `core/flow.v2.json` through MCP. Keep
+this wrapper thin; v2 is the operational source of truth.
 
 CampaignOffer state and the watch link are the customer-facing source of truth.
 Disk artifacts are optional debug/UAT diagnostics; normal customer runs should
@@ -117,6 +118,31 @@ data, compare sources by source volume, sampled ICP fit, activity/warmth
 signals, cleanup risk, and confidence basis. If a user asks for a forecast,
 label it explicitly as not estimated from this run.
 
+Before any provider prompt, search, source scout, or signal-discovery call,
+show a short source-plan gate and ask for approval. This first approval
+authorizes scouting/search only. The gate should say:
+
+- given this campaign, the viable source options
+- the recommended first lane
+- why that lane fits the buyer, offer, and likely public activity
+- what will be tested next
+- the fallback lane if relevant posts or ICP engagement look thin
+- that approval authorizes scouting/search only, not lead import or sending
+
+Do not surface blanket source heuristics as product copy. Make the
+recommendation specific to the campaign. If Signal Discovery is recommended,
+name the exact post themes you will search. If relevant public conversations
+look unlikely, recommend the specific Sales Nav or Prospeo lane instead and say
+why. Do not call `search_signals`, `search_sales_nav`, `search_prospeo`,
+`fetch_post_engagers`, or provider-scoped subagents until the user approves this
+source plan or explicitly chooses a different source.
+
+After scouting, ask for a second approval on the concrete source action. For
+Signal Discovery, name how many selected posts will be scraped, the target
+engager/source-candidate volume, and the bounded review-batch size. For Sales
+Nav or Prospeo, name the specific approved import lane. Do not call
+`import_leads` or `confirm_lead_list` until this second approval is granted.
+
 When the user has not supplied a source and multiple source angles are viable,
 scout those angles as independent branches when the host can actually do it:
 LinkedIn Engagement / active post engagers (internal `signal-discovery`
@@ -312,7 +338,7 @@ the brief. This is only the client-prospect/bootstrap identity for
 Do not call `mcp__sellable__list_senders`, `mcp__sellable__get_sender`, or
 surface connected/missing sender state during setup, brief, source, filter, or
 message review. Sender availability belongs only to the Settings/final launch
-handoff after message approval and the 10-lead validation sample.
+handoff after message approval and the review-batch validation sample.
 
 If the invocation or user answer includes an existing `clientProspectId`, keep
 it as the preferred `create_campaign` identity input. If it includes a LinkedIn
@@ -518,9 +544,9 @@ updates.
        ```text
        You're in — {activeWorkspaceName} workspace, ready to roll.
 
-       Now — paste the LinkedIn profile URL of the person you'll be sending campaigns from. Usually that's you (the founder), or whoever's voice the messages should sound like.
+       Now — paste the LinkedIn profile or company website for the client/company this campaign is for. I’ll use that to resolve the campaign identity before we pick the target, offer, proof, and lead source.
 
-       e.g. https://www.linkedin.com/in/your-handle
+       e.g. https://example.com or https://www.linkedin.com/in/client-handle
        ```
 
      - If `isReturningUser === false`, prepend ONE line confirming the new
@@ -529,16 +555,18 @@ updates.
        ```text
        You're set up — your {activeWorkspaceName} workspace is ready.
 
-       Now — paste the LinkedIn profile URL of the person you'll be sending campaigns from. Usually that's you (the founder), or whoever's voice the messages should sound like.
+       Now — paste the LinkedIn profile or company website for the client/company this campaign is for. I’ll use that to resolve the campaign identity before we pick the target, offer, proof, and lead source.
 
-       e.g. https://www.linkedin.com/in/your-handle
+       e.g. https://example.com or https://www.linkedin.com/in/client-handle
        ```
 
      No other lines. No "all set", no "signed in", no other acknowledgement.
 
-     After the user pastes the URL, proceed with the existing identity-first
-     sender flow (Step 3 onwards in the v2 subskill prompt — sender
-     enrichment via `fetch_linkedin_profile` / `enrich_sender`).
+     After the user pastes the URL, proceed with the identity-first campaign
+     setup in the v2 subskill prompt. Resolve a LinkedIn profile with
+     `fetch_linkedin_profile`, a company website/domain with `fetch_company`
+     when possible, and mark the client/company research gate with
+     `complete_sender_research` when that protocol is required.
 
 3. If auth is not OK with `error.type === "workspace"` (token valid, no active
    workspace), stop and show the returned guidance — that's not a fresh-user
@@ -577,9 +605,13 @@ updates.
    queue workflow cells, attach a sequence, or start until the filter choice is
    resolved, rubrics are saved when filters are enabled, template/token rules
    are approved on the default Use Template path, and the approved message set
-   is synced into the campaign brief. After rubrics save, pause and say the fit
-   rules are saved; approve the message template next; after approval, queue the
-   bounded review-batch `enrichCellId` cells to kick off enrichment/filtering.
+   is synced into the campaign brief. When filters are approved, immediately
+   call `mcp__sellable__update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
+   so the watched app moves to Filter Rules while rubrics are drafted/saved.
+   After rubrics save, move the watched app to `apply-icp-rubric` / Filter
+   Leads and say the fit rules are saved; approve the message template next;
+   after approval, queue the bounded review-batch
+   `enrichCellId` cells to kick off enrichment/filtering.
    Product Generate Message cells must not run from the background template
    path before that template/token approval.
    Do not ask the user to approve the brief before shell creation unless they
@@ -588,8 +620,10 @@ updates.
    `mcp__sellable__update_campaign({ campaignId, currentStep })` before major
    visible work so the user can watch progress in the app: `create-offer` for
    the brief, `pick-provider` or the selected provider step while sourcing,
-   `filter-choice` after the 15-row review batch, `messages` for the Use
-   Template / AI Generated mode choice, `auto-execute-messaging` for approved
+   `filter-choice` after the 15-row review batch, `create-icp-rubric` as soon
+   as filters are approved, `apply-icp-rubric` after rubrics save, `messages`
+   for the Use Template / AI Generated mode
+   choice, `auto-execute-messaging` for approved
    message work or the product's AI-generated path, `awaiting-user-greenlight`
    for the final handoff, `settings` for sender selection, `sequence` after
    sender attach, and `send` once the recommended sequence is attached.