@vruum/skills 0.6.68 → 0.6.70

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.68",
+  "version": "0.6.70",
   "description": "Vruum AI skills + remote MCP server for B2B GTM teams. Slash commands for outreach triage, engagement triage, pipeline filling, prospect enrichment, and reply diagnosis, paired with the full Vruum MCP tool surface over OAuth 2.1.",
   "author": {
     "name": "Vruum AI",

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.68",
+  "version": "0.6.70",
   "description": "Connect your Vruum workspace to review revenue priorities, manage deals, research prospects, and prepare outreach through guided skills and authenticated MCP tools.",
   "author": {
     "name": "Vruum",

package/README.md

@@ -109,14 +109,17 @@ the public skill instead of leaving a broken link.
 - `/pipeline-fill` — Source-agnostic pipeline orchestrator. Picks a source per campaign (Sales Nav / YC / CSV / account list / discovery), runs harness deep research, applies a pre-filter gate, then saves into the campaign via the backend authoritative match_score>=70 gate. Use when: fill pipeline, import prospects, daily imports, need more prospects, discover prospects from scratch, find buyers at these companies, deep research before import.
 - `/sales-nav-deep-fill` — Sales Nav harness source for /pipeline-fill. Pre-filters Sales Nav profiles via vruum-pipeline-filter, produces a candidate list, hands off to /pipeline-fill for deep research and import. Use when: sales nav with deep research, sales nav harness mode, in-chat sales nav.
 - `/vruum-guide` — Guide to running Vruum from your own AI harness. First run: guided onboarding from empty account to first reviewed outreach draft. After: reads live account state, recommends the single next most valuable action, hands off to the right skill. Use when: get started, onboarding, how do I use vruum, what should I do next, where do I start.
-- `/vruum-skills-upgrade` — Upgrade @vruum/skills to the latest npm version and re-sync ~/.vruum/. Use when: upgrade vruum skills, update vruum, pull latest vruum skills, or when the preamble reports UPGRADE_AVAILABLE.
+- `/vruum-skills-upgrade` — Upgrade @vruum/skills to the latest npm version and re-sync ~/.vruum/. Use when the user explicitly asks: upgrade vruum skills, update vruum, or pull latest vruum skills. A passive update notice does not invoke this skill.
 - `/winback-fill` — Source winback candidates from closed-lost deals or churned customers. Surfaces people who went silent or lost a deal >90 days ago, where the loss reason wasn't 'no_fit'. Use when: winback, win back churned, reactivate, revive cold deals, 90-day silent revival, lost deal recovery, lost customer outreach.
 - `/yc-pipeline-fill` — YC harness source for /pipeline-fill. Scrapes YC's public Algolia index, extracts founder LinkedIn URLs, dedups, hands a candidate list to /pipeline-fill for deep research and import. Use when: YC pipeline fill, source from YC, fill campaign with YC founders, sales nav dried up, source YC.
 <!-- generated:skills-end -->
 
 ## Upgrade
 
-Skills auto-prompt to upgrade via the preamble. To upgrade explicitly:
+Passive update checks do not interrupt the requested task or install updates.
+After the task result, a skill may mention an available update once per
+conversation. Invoke `/vruum-skills-upgrade` when you want its upgrade flow
+(including the saved automatic-upgrade preference), or explicitly run:
 
 ```bash
 npx --yes @vruum/skills@latest install

package/install.js

@@ -52,7 +52,7 @@ _UPD=$(~/.vruum/bin/vruum-skills-update-check 2>/dev/null || true)
 [ -n "$_UPD" ] && echo "$_UPD" || true
 \`\`\`
 
-If output shows \`UPGRADE_AVAILABLE <old> <new>\`: read \`~/.vruum/skills/vruum-skills-upgrade/SKILL.md\` and follow the inline upgrade flow. If \`~/.vruum/config.yaml\` has \`auto_upgrade: true\`, run the upgrade silently; otherwise AskUserQuestion with four options — (A) upgrade now, (B) upgrade with changelog preview, (C) snooze, (D) skip this session. If user picks snooze, bump the snooze level in \`~/.vruum/update-snoozed\` (format: \`<new_version> <level> <unix_epoch>\`; level 1 = 24h, 2 = 48h, 3+ = 7d). Then continue with the skill.
+If output shows \`UPGRADE_AVAILABLE <old> <new>\`: Continue with the requested skill immediately. After delivering its result, mention the available update and \`/vruum-skills-upgrade\` in one optional line, at most once per conversation. Do not ask an upgrade question, run an installer, or invoke the upgrade skill from this passive check. Read \`~/.vruum/skills/vruum-skills-upgrade/SKILL.md\` only when the user explicitly asks to upgrade; its configuration and consent flow apply then.
 
 If output shows \`JUST_UPGRADED <from> <to>\`: tell the user "Running @vruum/skills v{to} (just updated!)" in one line, then continue.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vruum/skills",
-  "version": "0.6.68",
+  "version": "0.6.70",
   "description": "Vruum AI skills for Claude Code, Claude Desktop, Codex CLI, and any AI assistant with a skill directory. Slash commands for outreach triage, engagement triage, pipeline filling, prospect enrichment, and reply diagnosis. Pairs with the Vruum MCP server at https://api.vruum.ai/mcp.",
   "license": "MIT",
   "repository": {
@@ -42,5 +42,5 @@
     "outreach",
     "gtm"
   ],
-  "contentHash": "935d2cff928fcd38ce3918f9a9b03b10997239323f820f351224c843c3a6aa1c"
+  "contentHash": "14614746d660f2832e18dc75d8eb3d13f626a43341395f84eb5b9cdad2535f04"
 }

package/skills/vruum-skills-upgrade/SKILL.md

@@ -1,15 +1,21 @@
 ---
 name: vruum-skills-upgrade
-description: "Upgrade @vruum/skills to the latest npm version and re-sync ~/.vruum/. Use when: upgrade vruum skills, update vruum, pull latest vruum skills, or when the preamble reports UPGRADE_AVAILABLE."
+description: "Upgrade @vruum/skills to the latest npm version and re-sync ~/.vruum/. Use when the user explicitly asks: upgrade vruum skills, update vruum, or pull latest vruum skills. A passive update notice does not invoke this skill."
 ---
 
 # /vruum-skills-upgrade
 
 Upgrade the `@vruum/skills` npm package + re-sync `~/.vruum/` + relink all harness skill dirs.
 
-## Inline upgrade flow (called from preamble)
+For every explicit request, whether a slash command or natural language, start
+with the fresh check in **Standalone mode** below. Do not reuse a passive notice
+as proof that an upgrade is still available.
 
-If the calling skill's preamble reported `UPGRADE_AVAILABLE <old> <new>`, follow this flow. It runs inline — when done, the original skill continues.
+## Explicit upgrade flow
+
+Use this flow only when the user explicitly requests an upgrade. A passive
+`UPGRADE_AVAILABLE <old> <new>` notice must not interrupt another skill. If the
+user requested an upgrade while doing other work, resume that work afterward.
 
 ### Step 1: decide whether to auto-upgrade
 
@@ -29,8 +35,8 @@ Use AskUserQuestion with these four options:
   [ $NEW_LEVEL -gt 3 ] && NEW_LEVEL=3
   echo "<new> $NEW_LEVEL $(date +%s)" > ~/.vruum/update-snoozed
   ```
-  Replace `<new>` with the version the preamble reported.
-- **D) Skip this session** — do nothing, don't write snooze. Next session will re-prompt.
+  Replace `<new>` with the version the fresh check reported.
+- **D) Skip this session** — do nothing, don't write snooze. Ask again only on another explicit upgrade request.
 
 ### Step 3: run the upgrade
 
@@ -59,7 +65,7 @@ rm -f ~/.vruum/last-update-check ~/.vruum/update-snoozed
 
 One line: `upgraded @vruum/skills $OLD → $NEW`. Then continue with the original skill.
 
-## Standalone mode (user invoked `/vruum-skills-upgrade` directly)
+## Standalone mode (slash command or natural-language upgrade request)
 
 Force a fresh check first, then run the flow above starting from Step 1 so the automatic-upgrade setting is honored:
 

package/skills/winback-fill/COHORT-QUERIES.md

@@ -11,12 +11,12 @@ tenant bind to choose.
 # Step 1: pull closed-lost deals (scoped to your session's tenant)
 lost = search(type="deals", filters={"outcome": "lost"}, limit=200)
 
-# Step 2: keep deals lost between 90 days and 18 months ago
+# Step 2: keep deals lost between 90 days and 365 days ago
 ninety_days_ago = now() - 90 days
-eighteen_months_ago = now() - 18 months
+oldest_eligible = now() - 365 days
 revival_window = [
     d for d in lost.deals
-    if eighteen_months_ago < parse(d.stage_changed_at) < ninety_days_ago
+    if oldest_eligible < parse(d.stage_changed_at) < ninety_days_ago
 ]
 
 # Step 3: drop terminal loss reasons — these are NOT revivable
@@ -34,7 +34,7 @@ candidates = [d for d in revivable if d.person_id not in open_person_ids]
 Cap the candidate list to the 50 most-recently-lost (sort by
 `stage_changed_at DESC`) before per-account enrichment.
 
-The 18-month upper bound prevents revival of ancient conversations the
+The 365-day upper bound prevents revival of ancient conversations the
 buyer has forgotten. The 90-day lower bound prevents the "thanks but no
 thanks" buyer from being re-pitched while the rejection is still fresh.
 

package/skills/winback-fill/SKILL.md

@@ -13,7 +13,7 @@ You are a winback-side pipeline filler. While `/expansion-fill` targets won-and-
 
 ## Why this skill exists
 
-A closed-lost deal is not a closed door. Most "lost" deals had a real conversation, a fit signal, and a circumstantial blocker — wrong timing, wrong champion, wrong budget cycle. Within 6-18 months, those circumstances change. The data points worth revisiting:
+A closed-lost deal is not a closed door. Most "lost" deals had a real conversation, a fit signal, and a circumstantial blocker — wrong timing, wrong champion, wrong budget cycle. Within 3-12 months, those circumstances change. The data points worth revisiting:
 - The person is still at the same company (relationship intact)
 - The original loss_reason was NOT `no_fit` or `no_budget_permanent` (the deal was lose-able, not unwinnable)
 - Their company has had a recent trigger (new exec, funding, news event)
@@ -46,7 +46,7 @@ is automatic from your authenticated session. Pick a variant per your intent
 
 For variant 1 (silent-deal revival), the cohort criteria:
 - `outcome == 'lost'`
-- `stage_changed_at` between 90 days ago and 18 months ago
+- `stage_changed_at` between 90 days ago and 365 days ago
 - `loss_reason NOT IN ('no_fit', 'no_budget_permanent')` (these are terminal — don't re-pitch)
 - Person is still surfaceable via `get_person_360` (still at company)
 - No open deal currently exists on that person (post-filter against