@sellable/install 0.1.92 → 0.1.94

package/README.md

@@ -6,6 +6,16 @@ Installs Sellable MCP for Claude Code and Codex.
 npx -y @sellable/install@latest --host all
 ```
 
+After install, `sellable create` is a terminal helper that prints the correct
+agent command for launching a campaign:
+
+```bash
+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.
 
 The installer uses package stdio MCP by default:

package/agents/source-scout-linkedin-engagement.md

@@ -26,15 +26,38 @@ Use the inherited Sellable MCP tools when available:
 Process:
 
 1. Read the campaign brief, kickoff doc, or lane prompt supplied by the parent.
-2. Search 3-5 keyword/topic lanes, favoring fresh posts from the last 7-14 days.
-3. Select 3-5 promising posts when available. If a `campaignOfferId` was
-   supplied, call `select_promising_posts({ campaignOfferId, selectionMode:
-"replace", selections, headlineICPCriteria, currentStep:
-"signal-discovery" })` before sampling so the watched Signal Discovery table
-   shows the promoted posts.
-4. Fetch or sample engagers for promoted posts and score rough ICP fit from visible headline/display-name cues only. Do not enrich people during viability estimation.
-5. Estimate usable prospects per selected post from sampled pass rate. If the sample is good but volume is low, say how many more similar posts should be added or scraped.
-6. Return false positives and dead ends explicitly.
+2. Generate 3-5 intersection keyword/topic lanes, favoring fresh posts from the
+   last 7-14 days. Each lane should combine the campaign anchor with the buyer
+   pain, use case, or ICP role so fit is high before sampling. For example, for
+   a Claude + GTM/outbound campaign, prefer `Claude outbound`, `Claude Code
+LinkedIn outreach`, `AI SDR Claude`, `GTM automation Claude`, and `founder-led
+sales Claude`; do not treat broad anchor-only lanes like `Claude Code`, `MCP`,
+   `AI agents`, or `agentic coding` as selectable unless they also include the
+   GTM/outbound wedge or the narrower lanes fail.
+3. Inspect finalist posts by content type before final selection. Prefer posts
+   where the topic matches the campaign wedge, not generic high-engagement news.
+4. If Round 1 produced broad anchor-only inventory, retarget immediately around
+   the wedge before sampling. Do not promote or sample broad posts when there are
+   narrower posts about the actual campaign pain/use case.
+5. Promote the first narrow sample set when campaign-attached. If a
+   `campaignOfferId` was supplied, call `select_promising_posts({
+campaignOfferId, selectionMode: "replace", selections, headlineICPCriteria,
+currentStep: "signal-discovery" })` before sampling so the watched Signal
+   Discovery table shows the promoted posts and the exact posts being tested.
+6. Fetch or sample engagers for promoted posts and score rough ICP fit from
+   visible headline/display-name cues only. Do not enrich people during
+   viability estimation.
+7. Compute capacity before recommending the source: source target good-fit
+   leads (default 300 unless the parent supplies a target), reachable engagers,
+   sampled ICP-fit rate as `n/N` plus an easy percentage/range, expected usable
+   leads per 100 engagers before and after a conservative dedupe/cleanup
+   factor, required engagers to scrape (`source target / fit rate`), average
+   reachable engagers per right-content post, expected usable leads per
+   right-content post after dedupe/cleanup, and posts needed to hit the target.
+8. Select/promote enough right-content posts to plausibly hit the target. If the
+   warm Signals pool is useful but too small, return the expected warm range and
+   recommend Sales Nav/Prospeo for scale instead of padding with noisy posts.
+9. Return false positives and dead ends explicitly.
 
 Return a concise structured result with:
 
@@ -43,8 +66,14 @@ Return a concise structured result with:
 - `keyword_lanes` with timeframe, raw posts found, finalist posts reviewed
 - `selected_posts` with URL/title, author/topic, age, engager count, sampled engagers, good fits as n/N, estimated usable prospects per post, use/discard
 - `sample_leads`, if any
+- `approval_math` with eligible posts, source target good-fit leads, sampled
+  engagers, ICP-fit rate as `n/N` plus percentage/range, good-fit prospects per
+  100 engagers, required engagers to scrape, average reachable engagers per
+  post, expected usable prospects per post after cleanup, posts needed for
+  target, selected post count, review-batch import limit, expected usable lead
+  range, and scale fallback
 - `estimated_good_fit_range`
-- `expected_reply_rate_range`, directional if inferred
+- `message_context_strength`, directional and source-specific
 - `false_positive_patterns`
 - `recommendation`
 - `confidence`
@@ -53,5 +82,16 @@ Evidence standards:
 
 - Do not trust raw post volume without inspecting finalist post quality.
 - Prefer sample-based pass rates over intuition.
+- Prefer narrow intersection topics over broad audience topics. A post about
+  the anchor technology alone is not enough; the post should also express the
+  GTM/outbound/buyer pain, workflow, or role context that makes the campaign
+  relevant.
+- Do not make the user infer capacity. Say, plainly, how many eligible posts
+  exist, how many sampled engagers looked in-ICP, how many good-fit prospects
+  that implies per 100 engagers, how many usable prospects one right-content
+  post should yield after cleanup, how many engagers must be scraped for the
+  300-good-fit source target, how many posts are needed for that source target,
+  and which posts you would use. Also say the first campaign import remains the
+  bounded 15-row review batch.
 - If `fetch_post_engagers` is unavailable or fails, report that explicitly and mark the estimate lower-confidence.
 - Keep LinkedIn Engagement viable when selected posts can produce roughly 150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable.

package/agents/source-scout-sales-nav.md

@@ -26,8 +26,16 @@ Process:
 2. Preserve target role names with `CURRENT_TITLE` lookups; do not rely on seniority alone when the brief names concrete roles.
 3. When `lookup_sales_nav_filter` returns multiple title options, choose the closest semantic title match instead of the first result.
 4. Build a broad-but-reasonable baseline from role/title, geography, company size, industry/account context, and recent LinkedIn activity when relevant.
-5. Run the baseline plus 1-2 refinements if the first pass is noisy or under-scaled.
-6. Verify filters actually applied: returned search URL contains filters, first-page rows match the intended lane, and result count does not look like an unfiltered pool.
+5. Check scale against the source target good-fit lead count (default 300
+   unless the parent supplies a target). If raw preview volume or projected usable volume
+   is below target, do not present the tiny result as the scale fallback yet.
+   Loosen nonessential filters in order: remove recent-activity first, widen
+   adjacent title variants, widen geography/company-size constraints, and only
+   keep hard ICP requirements from the brief.
+6. Run the baseline plus 1-2 refinements or loosening passes if the first pass
+   is noisy or under-scaled. Label the final pool as constrained if it still
+   cannot plausibly reach the target after loosening.
+7. Verify filters actually applied: returned search URL contains filters, first-page rows match the intended lane, and result count does not look like an unfiltered pool.
 
 Return a concise structured result with:
 
@@ -36,6 +44,11 @@ Return a concise structured result with:
 - `exact_filter_recipe`
 - `lookup_ids_used`
 - `raw_result_count`
+- `scale_check` with source target good-fit lead count, preview/raw volume, sampled
+  good fits as n/N, projected usable count, and whether the pool can reach the
+  target
+- `loosening_attempts` with what was removed or widened when the pool was too
+  tight
 - `sampled_people` and good fits as n/N
 - `estimated_good_fit_range_after_cleanup`
 - `expected_acceptance_rate_range`, directional if inferred
@@ -49,5 +62,9 @@ Evidence standards:
 
 - Optimize for a useful prospect pool, not max volume at any cost.
 - Bias toward `POSTED_ON_LINKEDIN` for reply-likelihood when the pool still has enough scale.
+- Do not over-tighten fallback filters into a pool that cannot be meaningfully
+  larger than the warm-post path. If Sales Nav is offered for scale, it should
+  either project to the target good-fit count or clearly say it is too tight and
+  name the next broadening/Prospeo option.
 - Do not hand-wave missing filter IDs.
 - If Sales Nav returns a giant unfiltered pool, discard that result and retry with valid filters before recommending it.

package/bin/sellable-install.mjs

@@ -129,9 +129,15 @@ function usage() {
   return `Sellable agent installer
 
 Usage:
+  sellable create
   sellable-install [options]
   npx -y @sellable/install@latest -- [options]
 
+Commands:
+  create                   Show how to launch the create-campaign workflow.
+  auth set <token>         Save a Sellable API token for first-run auth.
+  uninstall                Remove Sellable host config and installed artifacts.
+
 Options:
   --host <host>             claude, codex, or all. Default: all
   --server <mode>           package, local, or hosted. Default: package
@@ -158,6 +164,34 @@ Auth:
 `;
 }
 
+function printCreateCommandHint() {
+  printBanner();
+  console.log(
+    `  ${C.bold}Create campaigns from Claude Code or Codex.${C.reset}`
+  );
+  console.log("");
+  console.log(
+    `  ${C.grey}The terminal command installs and verifies Sellable. Campaign creation runs inside your agent session so the workflow can use MCP tools, live state, and approval gates.${C.reset}`
+  );
+  console.log("");
+  console.log(`   ${"═".repeat(63)}`);
+  console.log(`    ${C.bold}Start a Sellable campaign:${C.reset}`);
+  console.log(`   ${"═".repeat(63)}`);
+  console.log("");
+  console.log("");
+  printAgentBox("Using Claude Code?", "claude", "/sellable:create-campaign");
+  console.log("");
+  console.log("");
+  printAgentBox("Using Codex?", "codex", "$sellable:create-campaign");
+  console.log("");
+  console.log(`   ${"─".repeat(63)}`);
+  console.log(`    ${C.grey}If those commands are missing, run:${C.reset}`);
+  console.log("");
+  console.log(`      ${C.cyan}sellable --host all${C.reset}`);
+  console.log(`      ${C.cyan}sellable --verify-only --host all${C.reset}`);
+  console.log("");
+}
+
 function parseArgs(argv) {
   const opts = {
     host: process.env.SELLABLE_INSTALL_HOST || "all",
@@ -2245,6 +2279,10 @@ async function main() {
       runUninstall();
       process.exit(0);
     }
+    if (rawArgs[0] === "create") {
+      printCreateCommandHint();
+      process.exit(0);
+    }
     const opts = parseArgs(process.argv.slice(2));
     if (opts.help) {
       console.log(usage());

package/package.json

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