@sellable/install 0.1.146 → 0.1.148

package/bin/sellable-install.mjs

@@ -701,9 +701,10 @@ label it explicitly as not estimated from this run.
 Before any provider prompt, search, source scout, or signal-discovery call, show
 one source-plan gate and ask for approval. Write this like a fifth grader could
 understand it: short sentences, no internal labels, and no GTM shorthand. The
-plan must be visible before the question, and this first approval only
-authorizes finding the best places to look for buyers. It does not add anyone
-to the campaign yet. The gate should say:
+order is strict: first show the plan in chat, then open the approval question.
+Do not open a generic approval first and reuse it after the plan. This first
+approval only authorizes finding the best places to look for buyers. It does
+not add anyone to the campaign yet. The gate should say:
 
 - the buyer groups or places we could check
 - the best place to start
@@ -752,9 +753,11 @@ instead and explain it in plain words once. Do not call \`search_signals\`,
 \`fetch_post_engagers\`, or provider-scoped subagents until the user approves this
 source plan or explicitly chooses a different source.
 
-If the user already answered a provider approval such as "Approve Prospeo plan",
-that answer satisfies the source-plan gate. Persist the approved provider and
-run the scouting/search next; do not ask a second source-plan approval question.
+If the user answers a provider approval such as "Approve Prospeo plan" after
+seeing the source plan, that answer satisfies the source-plan gate. Persist the
+approved provider and run the scouting/search next; do not ask a second
+source-plan approval question. A brief approval, generic "approve plan", or
+provider state from before the visible source plan does not satisfy this gate.
 
 For hiring-led campaigns, do not default to Sales Nav just because the target is
 a role search. Prospeo is the primary lane when the brief asks for companies
@@ -811,14 +814,18 @@ copy.
 ## Codex Watch Link Handoff
 
 When a campaign tool returns \`watchUrl\`, treat it as a user-opened app link, not
-as permission to drive the browser. A valid handoff link must be a direct
-\`/campaign-builder/{campaignId}?mode=claude|codex\` URL with the auth token and
-workspace routing needed for auto-login. \`create_campaign.watchUrl\`,
+as permission to drive the browser. A valid first handoff link must be the exact
+\`create_campaign.watchUrl\` value: a direct
+\`/campaign-builder/{campaignId}?mode=claude|codex\` URL with \`workspaceId\` and
+\`token\` query parameters for auto-login. \`create_campaign.watchUrl\`,
 \`create_campaign({ campaignId }).watchUrl\`, and \`get_campaign.watchUrl\` are all
-acceptable only when they return that direct campaign-builder shape.
+acceptable only when they return that direct campaign-builder shape. Never
+derive, shorten, reconstruct, or print a bare \`/campaign-builder/{campaignId}\`
+URL.
 
 Never call browser-opening tools, shell \`open\`, Computer Use, or in-app browser
-automation just because a watch link exists. Print the link in this shape:
+automation just because a watch link exists. Print the first watch link exactly
+once, directly before the brief approval question, in this shape:
 
 \`\`\`text
 Campaign shell is ready. We'll keep building the campaign in this chat.
@@ -835,6 +842,9 @@ the link lands on auth, 404, permission, blank, or a visible error state, recove
 a fresh watch link once with \`create_campaign({ campaignId })\` or \`get_campaign\`
 and print that link. Do not claim the browser was opened, inspected, or
 synchronized.
+Do not print another \`Watch link:\` line during source/provider selection or
+normal approval turns unless the user explicitly asks for the link or you are
+recovering a missing/broken URL.
 
 After every \`update_campaign({ campaignId, currentStep })\`, use
 \`get_campaign_navigation_state\` when available as a compact orientation check:
@@ -1011,13 +1021,15 @@ recommendation; you can replace it with your current offer."
 Before the identity gate, use this customer-facing shape:
 
 \`\`\`text
-I’m ready to build the campaign in {workspace}.
+You're in {workspace}.
 
-First I’ll research the person/company this campaign is for. I’ll use that
-context to recommend a target, offer, proof, and lead source, then you can
-correct anything stale before I build from it.
+Excited to help you launch your LinkedIn outbound campaign.
 
-Then I’ll turn that into a campaign brief for you to approve before anything is created.
+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, review
+messages, and wait for final launch approval.
+
+What's your LinkedIn profile URL or handle?
 \`\`\`
 
 Do not silently ask Codex intake or approval questions as plain chat when

package/package.json

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

package/skill-templates/create-campaign.md

@@ -132,9 +132,10 @@ label it explicitly as not estimated from this run.
 Before any provider prompt, search, source scout, or signal-discovery call, show
 one source-plan gate and ask for approval. Write this like a fifth grader could
 understand it: short sentences, no internal labels, and no GTM shorthand. The
-plan must be visible before the question, and this first approval only
-authorizes finding the best places to look for buyers. It does not add anyone
-to the campaign yet. The gate should say:
+order is strict: first show the plan in chat, then open the approval question.
+Do not open a generic approval first and reuse it after the plan. This first
+approval only authorizes finding the best places to look for buyers. It does
+not add anyone to the campaign yet. The gate should say:
 
 - the buyer groups or places we could check
 - the best place to start
@@ -183,9 +184,11 @@ instead and explain it in plain words once. Do not call `search_signals`,
 `fetch_post_engagers`, or provider-scoped subagents until the user approves this
 source plan or explicitly chooses a different source.
 
-If the user already answered a provider approval such as "Approve Prospeo plan",
-that answer satisfies the source-plan gate. Persist the approved provider and
-run the scouting/search next; do not ask a second source-plan approval question.
+If the user answers a provider approval such as "Approve Prospeo plan" after
+seeing the source plan, that answer satisfies the source-plan gate. Persist the
+approved provider and run the scouting/search next; do not ask a second
+source-plan approval question. A brief approval, generic "approve plan", or
+provider state from before the visible source plan does not satisfy this gate.
 
 For hiring-led campaigns, do not default to Sales Nav just because the target is
 a role search. Prospeo is the primary lane when the brief asks for companies
@@ -306,14 +309,18 @@ copy.
 ## Codex Watch Link Handoff
 
 When a campaign tool returns `watchUrl`, treat it as a user-opened app link, not
-as permission to drive the browser. A valid handoff link must be a direct
-`/campaign-builder/{campaignId}?mode=claude|codex` URL with the auth token and
-workspace routing needed for auto-login. `create_campaign.watchUrl`,
+as permission to drive the browser. A valid first handoff link must be the exact
+`create_campaign.watchUrl` value: a direct
+`/campaign-builder/{campaignId}?mode=claude|codex` URL with `workspaceId` and
+`token` query parameters for auto-login. `create_campaign.watchUrl`,
 `create_campaign({ campaignId }).watchUrl`, and `get_campaign.watchUrl` are all
-acceptable only when they return that direct campaign-builder shape.
+acceptable only when they return that direct campaign-builder shape. Never
+derive, shorten, reconstruct, or print a bare `/campaign-builder/{campaignId}`
+URL.
 
 Never call browser-opening tools, shell `open`, Computer Use, or in-app browser
-automation just because a watch link exists. Print the link in this shape:
+automation just because a watch link exists. Print the first watch link exactly
+once, directly before the brief approval question, in this shape:
 
 ```text
 Campaign shell is ready. We'll keep building the campaign in this chat.
@@ -335,6 +342,9 @@ Never print a placeholder watch link such as "Open campaign" or "link will
 update once the shell is created." If the shell is not created yet, call
 `create_campaign` first. If `create_campaign` does not return `watchUrl`, stop
 and surface the missing watch-link error before lead sourcing.
+Do not print another `Watch link:` line during source/provider selection or
+normal approval turns unless the user explicitly asks for the link or you are
+recovering a missing/broken URL.
 
 After every `update_campaign({ campaignId, currentStep })`, use
 `get_campaign_navigation_state` when available as a compact orientation check:
@@ -556,14 +566,15 @@ the run. Treat YOLO as `interactionMode: "autonomous"` plus an intake policy:
 Before the identity gate, use this customer-facing shape:
 
 ```text
-I’m ready to build the campaign in {workspace}.
+You're in {workspace}.
 
-First I’ll research the person/company this campaign is for. I’ll use that
-context to recommend a target, offer, proof, and lead source, then you can
-correct anything stale before I build from it.
+Excited to help you launch your LinkedIn outbound campaign.
 
-Then I’ll turn that into a campaign brief for you to approve before any leads
-are sourced.
+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, review
+messages, and wait for final launch approval.
+
+What's your LinkedIn profile URL or handle?
 ```
 
 Do not silently ask Codex intake or approval questions as plain chat when
@@ -688,26 +699,27 @@ updates.
      been written. Your IMMEDIATE next visible message branches on
      `isReturningUser` from the tool result:
 
-     - If `isReturningUser === true`, prepend ONE line acknowledging the
-       reused workspace, then the locked Step 3 narration verbatim
-       (substituting `activeWorkspaceName` exactly):
+     - If `isReturningUser === true`, use `activeWorkspaceName` when present,
+       otherwise `activeWorkspaceId`, as `{workspaceLabel}`:
 
        ```text
-       You're in — {activeWorkspaceName} workspace, ready to roll.
-       ```
+       You're in {workspaceLabel}.
 
-     What is your LinkedIn profile URL or handle?
+       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, review messages, and wait for final launch approval.
 
-     ````
+       What's your LinkedIn profile URL or handle?
+       ```
 
-     - If `isReturningUser === false`, prepend ONE line confirming the new
-     workspace, then the locked Step 3 narration verbatim:
+     - If `isReturningUser === false`, use `activeWorkspaceName` when present,
+       otherwise `activeWorkspaceId`, as `{workspaceLabel}`:
 
-     ```text
-     You're set up — your {activeWorkspaceName} workspace is ready.
+       ```text
+       You're set up in {workspaceLabel}.
+
+       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, review messages, and wait for final launch approval.
 
-     What is your LinkedIn profile URL or handle?
-     ````
+       What's your LinkedIn profile URL or handle?
+       ```
 
      No other lines. No "all set", no "signed in", no other acknowledgement.