@vruum/skills 0.6.19 → 0.6.21

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.19",
+  "version": "0.6.21",
   "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.19",
+  "version": "0.6.21",
   "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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vruum/skills",
-  "version": "0.6.19",
+  "version": "0.6.21",
   "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": "48902855367f5e1eb50d347122377cd1b7126a77607576b708ab18dd1d3d011d"
+  "contentHash": "e410c9d89bfbc32777e45d0fcfb39383d2497f7c7f9e57d8867159e73591b6ac"
 }

package/skills/ingest-meetings/SKILL.md

@@ -20,18 +20,25 @@ This is an analyst's job, not a batch import. The attribution step (which person
 - **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
+### Step 1 — Establish the recency window, then find NEW transcripts
 
-Search the knowledge base for meeting-shaped documents:
+**This skill is incremental and go-forward.** It ingests only meetings newer than the last one already logged, and never re-ingests the historical archive (a connected Drive can hold years of old transcripts — those stay KB-searchable but are not turned into CRM activity/tasks).
 
-- `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).
+1. **Get the watermark.** Call `get_daily_briefing` and read `latest_logged_meeting_at` — the date of the most recent meeting already logged for this tenant.
+   - **Set** → the window is everything *after* that date.
+   - **`null`** (no meeting logged yet — first run) → **ask the operator for a seed date** ("Ingest meetings since when? (default: last 30 days)"). Never silently default to the whole archive.
 
-> 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.
+2. **Find candidates.** `search` type=kb with `filters={query: "meeting notes transcript live notes", include_content: false}`. Connector results carry `source_kind='connector'`, the meeting date in `modified_at`, a Drive `url`, and predictable filename shapes:
+   - **Gemini:** `… - Notes by Gemini`, `… - Transcript`, `… - Live Notes`
+   - **Read.ai:** `… - Read Meeting Report`, `… Smart Notes`
+
+3. **Apply the window — drop everything at/before the watermark** (or the seed date). The Drive's historical archive is intentionally left KB-searchable-only, NOT re-ingested into the CRM. Logging an old meeting (and minting "follow up next week" tasks from a meeting that happened a year ago) is noise.
+
+4. Present the surviving candidates as a short list: `name · meeting date · one-line summary`. **If none are newer than the watermark, say so and stop** — there are no new meetings to ingest.
+
+> **One meeting, one record.** Gemini + Read.ai often produce 3-4 artifacts per meeting (`- Transcript`, `- Live Notes`, `Read Meeting Report`, `- Chat`). Pick the single richest one (usually `- Transcript` or `Notes by Gemini`) and ingest that — don't log the same meeting multiple times.
+
+> Alternative source: if you have a Google Drive MCP on the same Drive and a meeting hasn't synced into the KB yet, read it directly (`search_files` → `read_file_content` / `download_file_content`) 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
 
@@ -64,7 +71,7 @@ Per transcript, show the user the complete proposal before writing anything:
 - **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).
+**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>]`. If it's there, this transcript was already ingested → skip it (don't re-log, don't re-create tasks). The marker must lead the summary (see Step 6) because `get_person_360` truncates each activity description to ~200 chars — a marker buried at the end is cut off and the scan misses it.
 
 The user **approves / edits / drops individual tasks / drops the whole transcript**. Only what they approve gets written.
 
@@ -80,12 +87,12 @@ For each approved transcript:
    - `deal_id` = the resolved deal (omit if none)
    - `summary` =
      ```
-     <1–2 sentence recap>
+     [vruum-meeting:<doc_id>] <1–2 sentence recap>
 
      Attendees: <names / emails>
-     Source: <transcript filename> — Google Drive  [vruum-meeting:<doc_id>]
+     Source: <transcript filename> (Google Drive)
      ```
-     The `[vruum-meeting:<doc_id>]` marker is what makes re-runs idempotent (Step 5 scans for it). Keep it verbatim in the summary.
+     The `[vruum-meeting:<doc_id>]` marker is what makes re-runs idempotent (Step 5 scans for it). It **must be the very first thing in the summary** — `get_person_360` truncates the activity description to ~200 chars, so a marker placed at the end is cut off and the dedup scan silently fails (re-runs would create duplicate meetings). Keep it verbatim, at the front.
 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)