@vruum/skills 0.6.16 → 0.6.18

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.16",
+  "version": "0.6.18",
   "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.16",
+  "version": "0.6.18",
   "description": "Vruum AI skills + remote MCP server for B2B GTM teams. Skills 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/README.md

@@ -76,6 +76,7 @@ npx @vruum/skills install --target /path/to/skills/dir
 - `/engagement-triage` — Review and approve your pending LinkedIn engagement drafts and demand-gen content posts. Use when: triage engagements, review engagement queue, review warming comments, review nurture reactions, review marketing comments, review content drafts, check engagement queue.
 - `/enrich-prospect` — Deep prospect diarization — synthesize everything known about a person into a structured intelligence profile. Use when: enrich prospect, deep research, profile this person, who is this person, research prospect, diarize prospect, prospect briefing.
 - `/expansion-fill` — Source expansion-ready customers for outreach. Finds closed-won customers >60 days old with no open follow-on deal and surfaces them for an expansion play. Use when: expand customer, find upsell opportunities, NRR play, expansion opportunities, customers ripe for expansion, who can we expand to.
+- `/ingest-meetings` — Pull meeting transcripts from your connected Google Drive into Vruum. Attaches each transcript to the right person and deal as a meeting on their timeline, and turns its action items into tasks that surface in your daily briefing. You review every attach before anything is written; safe to re-run. Use when: ingest meetings, import meeting notes, pull transcripts, log my meetings, action items from meetings, Gemini notes, Read.ai transcripts, turn meetings into tasks.
 - `/outreach-triage` — Review and approve your pending outreach drafts across LinkedIn and email. Use when: triage, review queue, morning review, check messages, approve outreach, what needs review.
 - `/pipeline-fill` — Source-agnostic pipeline orchestrator. Picks a source per segment (Sales Nav / YC / CSV / discovery), runs harness deep research, applies a pre-filter gate, then saves into the segment via the backend authoritative match_score>=70 gate. Use when: fill pipeline, import prospects, daily imports, need more prospects, discover prospects from scratch, 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.

package/bin/vruum-skills-update-check

@@ -21,7 +21,9 @@ CONFIG_FILE="$STATE_DIR/config.yaml"
 REMOTE_URL="${VRUUM_REMOTE_URL:-https://registry.npmjs.org/@vruum/skills/latest}"
 
 # Force flag busts cache + snooze (used by /vruum-skills-upgrade directly)
+FORCE=0
 if [ "${1:-}" = "--force" ]; then
+  FORCE=1
   rm -f "$CACHE_FILE" "$SNOOZE_FILE"
 fi
 
@@ -75,6 +77,7 @@ if [ -f "$CACHE_FILE" ]; then
   case "$CACHED" in
     UP_TO_DATE*)        TTL=60 ;;
     UPGRADE_AVAILABLE*) TTL=720 ;;
+    CHECK_FAILED*)      TTL=30 ;;
     *)                  TTL=0 ;;
   esac
   STALE=$(find "$CACHE_FILE" -mmin +"$TTL" 2>/dev/null || true)
@@ -93,6 +96,12 @@ if [ -f "$CACHE_FILE" ]; then
           exit 0
         fi
         ;;
+      CHECK_FAILED*)
+        # Recent fetch failure cached — stay quiet and do NOT imply "up to
+        # date". Retry once the short TTL expires. A --force run never reaches
+        # here (it cleared the cache above), so it always re-fetches.
+        exit 0
+        ;;
     esac
   fi
 fi
@@ -100,13 +109,24 @@ fi
 # Step 5: slow path — fetch latest from npm registry.
 mkdir -p "$STATE_DIR"
 RESP="$(curl -fsSL --max-time 5 "$REMOTE_URL" 2>/dev/null || true)"
-# Extract "version":"X.Y.Z" without jq.
-REMOTE="$(echo "$RESP" | grep -oE '"version"[[:space:]]*:[[:space:]]*"[^"]+"' | head -1 | sed -E 's/.*"([^"]+)"$/\1/')"
+# Extract "version":"X.Y.Z" without jq. The trailing `|| true` is load-bearing
+# under `set -euo pipefail`: on a failed/empty fetch the grep matches nothing
+# and (with pipefail) the pipeline exits non-zero, which would errexit the whole
+# script mid-way — the original silent-failure path. Swallow it so REMOTE ends
+# up empty and the unreachable-registry branch below handles it deliberately.
+REMOTE="$(echo "$RESP" | grep -oE '"version"[[:space:]]*:[[:space:]]*"[^"]+"' | head -1 | sed -E 's/.*"([^"]+)"$/\1/' || true)"
 REMOTE="$(echo "$REMOTE" | tr -d '[:space:]')"
 
-# Reject anything that doesn't look like a semver number.
+# Registry unreachable or unparseable response. A failed fetch is NOT evidence
+# the local version is current — caching UP_TO_DATE here is the false-positive
+# that pinned a sandboxed client to a stale bundle: its forced check returned
+# nothing, which /vruum-skills-upgrade reads as "already on latest". Cache a
+# short-lived CHECK_FAILED marker so passive checks don't hammer the registry,
+# but never claim current. A forced check surfaces the failure so the user
+# knows it couldn't run (vs. a real up-to-date).
 if ! echo "$REMOTE" | grep -qE '^[0-9]+\.[0-9]+\.[0-9]+'; then
-  echo "UP_TO_DATE $LOCAL" > "$CACHE_FILE"
+  echo "CHECK_FAILED $LOCAL $(date +%s)" > "$CACHE_FILE"
+  if [ "$FORCE" = 1 ]; then echo "CHECK_FAILED $LOCAL"; fi
   exit 0
 fi
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vruum/skills",
-  "version": "0.6.16",
+  "version": "0.6.18",
   "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": "b8c87fc8fa92db1b14f993e7797fe6d7bd69ec24fec5fafa3256d346f7d0a0f9"
+  "contentHash": "c8ff45027670bb35cdb93bdb0301d9ce9faacb739eefcbe7efdf0bc699942051"
 }

package/skills/ingest-meetings/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: ingest-meetings
+description: >-
+  Pull meeting transcripts from your connected Google Drive into Vruum. Attaches
+  each transcript to the right person and deal as a meeting on their timeline,
+  and turns its action items into tasks that surface in your daily briefing. You
+  review every attach before anything is written; safe to re-run. Use when:
+  ingest meetings, import meeting notes, pull transcripts, log my meetings,
+  action items from meetings, Gemini notes, Read.ai transcripts, turn meetings
+  into tasks.
+---
+# /ingest-meetings
+
+Your meeting transcripts (Gemini Meet auto-notes, Read.ai reports) land in Google Drive. With Drive connected to Vruum, those transcripts sync into your knowledge base — but on their own they're just searchable text. This skill turns them into CRM activity: each transcript gets **attached to the right person and deal as a meeting** on their timeline, and its **action items become Vruum tasks** that show up in your daily briefing.
+
+This is an analyst's job, not a batch import. The attribution step (which person? which deal?) is where a wrong guess does real damage — a meeting logged on the wrong account misleads whoever reads it next. So **you confirm every attach before anything is written**, the skill never auto-attaches an ambiguous match, and it's **safe to re-run** (already-logged meetings and tasks are skipped, not duplicated).
+
+## What this needs
+
+- **Drive connected to Vruum.** The transcripts must be syncing into the knowledge base via the connector. If KB search turns up none of your recent meetings, the connection may be down or PDFs may not be admitted — say so and stop; this skill reads what's synced, it doesn't fix the connector.
+- **Vruum MCP** for: `search` (kb + people reads), `get_person_360`, `manage_person` (to log the meeting as a `meeting`-kind interaction), `manage_tasks`, `get_tasks`.
+
+### Step 1 — Find the transcripts
+
+Search the knowledge base for meeting-shaped documents:
+
+- `search` type=kb with `filters={query: "meeting notes transcript", include_content: false}` for a compact catalog (id, name, summary, date).
+- Identify transcripts by their **filename shape**, not just the query — these tools name files predictably:
+  - **Gemini:** `… - Notes by Gemini`, `Notes by Gemini for …`, `… - Transcript`, `… - Live Notes`
+  - **Read.ai:** `… - Read Meeting Report`, `Read AI …`, `… Smart Notes`
+- Default to a **recent window** (e.g. the last 2 weeks) unless the user asks for more.
+- Present the candidates as a short list: `name · meeting date · one-line summary`. Ask which to process (default: **all that aren't already logged** — Step 5 detects those).
+
+> Alternative source: if you have a Google Drive MCP pointed at the same Drive and a transcript hasn't synced into the KB yet, you can read it directly (`search_files` → `read_file_content` for Docs, `download_file_content` for Read.ai PDFs) and feed the text into Step 3. Lead with the KB — it's tenant-scoped and is what the connector already pulled.
+
+### Step 2 — Read each chosen transcript in full
+
+`search` type=kb with `filters={document_id: "<doc_id>", include_content: true}` returns the full document text. You need the whole transcript (attendees + the discussion), not a search snippet.
+
+### Step 3 — Resolve the entity (the careful step)
+
+For each transcript, work out **which person** it's with and **which deal** it belongs to. Mis-attribution is worse than no attribution — when in doubt, ask.
+
+1. **Pull the attendees** from the transcript text (Gemini and Read.ai both list participants, usually with emails).
+2. **Drop the internal side:** ignore attendees on your own company's email domain (that's you / your team, not the prospect). Ignore bare free-provider addresses (gmail.com, outlook.com, …) unless that's the only handle you have and the name clearly matches.
+3. For each remaining external attendee, resolve against the pipeline:
+   - `search` type=people with `query=<attendee email>` (exact email is the strongest key).
+   - If email finds nothing, try `query=<full name>` and disambiguate by company.
+4. **Exactly one confident match** → that's the person. Then `get_person_360` on them and pick the **open / most-recent deal** (ignore closed-won/closed-lost). If there's no deal, that's fine — attach to the person only.
+5. **Zero matches, more than one, or low confidence** → **ask the user**: pick from the candidates, create the person (`manage_person` action=create with the attendee's name/email/company), or skip this transcript. **Never auto-attach a guess.**
+
+### Step 4 — Extract the recap and action items (your judgment)
+
+From the transcript text, produce:
+
+- A **1–2 sentence recap** of what the meeting was about and where it landed.
+- **Action items** — only concrete commitments or follow-ups that were actually stated ("send the pricing doc", "intro them to security", "follow up after their board meeting"). Do **not** turn every discussion topic into a task. For each: a short imperative `title`, the `owner` if one was named, a `due` hint if a date/timeframe was said, and a `priority` (low/medium/high). Cap at ~10 to keep signal high. If the meeting had no real follow-ups, that's fine — log the meeting with no tasks.
+
+### Step 5 — Review (the approval gate)
+
+Per transcript, show the user the complete proposal before writing anything:
+
+- **Resolved entity:** person (+ company) and the deal it'll attach to.
+- **Meeting:** the recap + meeting date.
+- **Tasks:** the action-item list.
+
+**Idempotency check (do this before writing):** confirm the transcript isn't already logged — in `get_person_360` for the resolved person, scan recent **meeting** activity for the marker `[vruum-meeting:<doc_id>]` in the summary. If it's there, this transcript was already ingested → skip it (don't re-log, don't re-create tasks).
+
+The user **approves / edits / drops individual tasks / drops the whole transcript**. Only what they approve gets written.
+
+### Step 6 — Write (only the approved items)
+
+For each approved transcript:
+
+1. **Log the meeting** — call `manage_person` with the action that records a manual interaction/touch (its `interaction_kind: call|email|linkedin|meeting|other` action), with:
+   - `person_id` = the resolved person
+   - `interaction_kind` = `"meeting"`
+   - `direction` = `"outbound"` (or `"inbound"` if the prospect convened it)
+   - `occurred_at` = the meeting date as ISO-8601 (from the transcript title/text; fall back to the KB doc's date)
+   - `deal_id` = the resolved deal (omit if none)
+   - `summary` =
+     ```
+     <1–2 sentence recap>
+
+     Attendees: <names / emails>
+     Source: <transcript filename> — Google Drive  [vruum-meeting:<doc_id>]
+     ```
+     The `[vruum-meeting:<doc_id>]` marker is what makes re-runs idempotent (Step 5 scans for it). Keep it verbatim in the summary.
+2. **Create each approved task** — `manage_tasks` action=create with:
+   - `title` (the action item), `person_id` (+ `deal_id` if there is one)
+   - `priority`, and `due_at` as ISO-8601 **only if** a date was actually parseable (omit otherwise)
+   - `assigned_to` = the rep running this (leave to self; only assign a teammate if you know their Vruum user id)
+   - `external_id` = `transcript:<doc_id>:task:<n>` — the backend dedups on this, so re-running never duplicates a task.
+
+### Step 7 — Confirm
+
+Report concisely: **N meetings logged, M tasks created**, and anything **skipped** (already-logged, or unresolved). Note that the tasks will now surface in `get_daily_briefing` (tasks due) and on each person's timeline (`get_person_360`). For any **unresolved** transcripts, list them so the user can create the people and re-run.
+
+## Guardrails
+
+- **Never attach on an ambiguous or missing match** — ask. Mis-attribution is worse than no attribution.
+- **Never invent action items** — only commitments actually stated in the meeting.
+- **You approve every write.** Nothing is committed without the Step 5 sign-off.
+- **Safe to re-run.** Tasks dedup on `external_id`; meetings dedup on the `[vruum-meeting:<doc_id>]` summary marker. Running this twice on the same Drive is a no-op for already-ingested meetings.

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

@@ -67,10 +67,13 @@ Force a fresh check first, then run the flow above starting from Step 2:
 ~/.vruum/bin/vruum-skills-update-check --force
 ```
 
-If the forced check returns nothing, report `already on latest (v$(cat ~/.vruum/VERSION))` and exit.
+Interpret the forced check's output:
+- Returns nothing → genuinely up to date. Report `already on latest (v$(cat ~/.vruum/VERSION))` and exit.
+- `CHECK_FAILED <local>` → the registry could NOT be reached (network/sandbox), so we do **not** know if you're current. Report `upgrade check failed — couldn't reach the npm registry (network/sandbox); not necessarily on latest. Try again later or from an unsandboxed shell.` Do NOT claim "already on latest." (A forced check emits this whenever the fetch fails; a sandbox that blocks the registry is the common cause.)
+- `UPGRADE_AVAILABLE <old> <new>` → run the upgrade flow from Step 2.
 
 ## When something goes wrong
 
 - `npm install` fails with permissions → tell the user to re-run with `sudo` or fix their npm prefix. Don't auto-sudo.
 - `vruum-skills install` reports skipped skills → surface the conflict message verbatim; user needs to remove conflicting files.
-- Network failure on registry lookup → report `upgrade check failed, try again later` and continue with the original skill (don't block work on a transient fetch error).
+- Network failure on registry lookup → the forced check now emits `CHECK_FAILED <local>` (it no longer silently looks up to date). Report `upgrade check failed, try again later` and continue with the original skill (don't block work on a transient fetch error).