@sellable/install 0.1.83 → 0.1.85

package/package.json

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

package/skill-templates/create-campaign.md

@@ -155,7 +155,8 @@ for them. The link is for deeper inspection; never use it as a substitute for
 showing the content in chat.
 
 Never mention MCP namespaces, prompt chunking, plugin cache paths, missing
-linked skill versions, runbooks, or local skill files in normal customer-facing
+linked skill versions, runbooks, npm/package details, repo-local files, VPS or
+browser automation limitations, or local skill files in normal customer-facing
 copy.
 
 ## Codex Watch Browser Handoff
@@ -173,16 +174,17 @@ In Codex Desktop, when in-app browser control is available, open the returned wa
 I’ll open the campaign view and keep it in sync as I build.
 ```
 
-If browser control is unavailable, say so briefly and provide the watch link.
-In VPS or other off-desktop Codex runs, this fallback is the expected handoff for
-the local headed watch observer: make the signed link easy to copy/open, then
-continue with explicit chat progress and `get_campaign_navigation_state`
-orientation checks.
+If browser control is unavailable, provide the watch link without discussing the
+runtime limitation. In off-desktop Codex runs, make the signed link easy to
+copy/open, then continue with explicit customer-facing campaign progress and
+`get_campaign_navigation_state` orientation checks.
 Use this fallback shape:
 
 ```text
-I can’t inspect the campaign browser from this Codex session, so I’ll keep the
-chat steps explicit here. Watch link: {watchUrl}
+Watch link: {watchUrl}
+
+I’ll keep the campaign brief, lead source, and message-review steps explicit
+here as I build.
 ```
 
 If opening the watch link lands on an auth, 404, permission, blank, or visible
@@ -341,6 +343,25 @@ lookup if it has not already run, then ask the campaign setup questions. The
 setup questions should use the confirmed company context so they do not feel
 generic.
 
+### Sufficient Intake Bypass
+
+When the user's invocation or first answer already supplies the campaign
+identity plus enough strategy context to draft the campaign, do not turn that
+into an interview. Treat setup as complete when the request contains:
+
+- identity or client/company context;
+- target prospects or buyer segment;
+- offer / CTA;
+- proof or claims to use / avoid;
+- lead-source preference, supplied list, or permission to find people.
+
+In that case, do one lightweight identity/company lookup, summarize the inferred
+direction in one or two lines, and immediately draft the campaign brief. Do not
+ask the buyer, offer, proof, or lead-source setup questions again unless a
+required field is missing, the supplied inputs conflict, or the campaign focus is
+genuinely ambiguous. It is fine to include an explicit assumption line in the
+brief; the approval gate lets the user revise it.
+
 Before the identity gate, use this customer-facing shape:
 
 ```text