@vruum/skills 0.5.2 → 0.6.0

package/README.md

@@ -13,7 +13,7 @@ Add to `~/.claude.json`:
 ```json
 {
   "mcpServers": {
-    "vruum-local": { "type": "http", "url": "https://api.vruum.ai/mcp" }
+    "vruum": { "type": "http", "url": "https://api.vruum.ai/mcp" }
   }
 }
 ```
@@ -22,23 +22,25 @@ Slash commands appear automatically once registered. You don't need this npm pac
 
 ### Codex CLI
 
-Add to `~/.codex/config.toml`:
+**Plugin (recommended)** — bundles the skills + Vruum MCP in one step:
 
-```toml
-[mcp_servers.vruum-local]
-url = "https://api.vruum.ai/mcp"
+```bash
+codex plugin marketplace add vruum-gtm/skills
+codex plugin add vruum@vruum-gtm
+codex mcp login vruum
 ```
 
-Then run this installer to bring the skill bundle into your Codex skills directory:
+**Manual / other harnesses** — register the MCP, then install the skills into the agent-standard skills dir:
 
-```bash
-npx @vruum/skills install
+```toml
+# ~/.codex/config.toml
+[mcp_servers.vruum]
+url = "https://api.vruum.ai/mcp"
 ```
 
-Detects `~/.codex/skills/` automatically. For other harnesses without a known path:
-
 ```bash
-npx @vruum/skills install --target /path/to/skills/dir
+npx @vruum/skills install                                # detects ~/.agents/skills/
+npx @vruum/skills install --target /path/to/skills/dir   # any other harness
 ```
 
 ### Cursor / VS Code Copilot / Cline

package/install.js

@@ -78,9 +78,13 @@ function injectPrelude(skillDir) {
 
 // Known harness skill directories. Add a target here when a new harness
 // lands on a stable skill-dir convention.
+// `detect` = the harness's config dir (its presence means the harness is
+// installed); `dir` = where that harness actually reads skills from. Claude
+// Code reads ~/.claude/skills; Codex CLI (and other agents on the
+// agentskills.io standard) read ~/.agents/skills.
 const KNOWN_TARGETS = [
-  { name: 'Claude Code', dir: path.join(os.homedir(), '.claude', 'skills') },
-  { name: 'Codex CLI',   dir: path.join(os.homedir(), '.codex',  'skills') },
+  { name: 'Claude Code', detect: path.join(os.homedir(), '.claude'), dir: path.join(os.homedir(), '.claude', 'skills') },
+  { name: 'Codex CLI',   detect: path.join(os.homedir(), '.codex'),  dir: path.join(os.homedir(), '.agents', 'skills') },
 ];
 
 function parseArgs(argv) {
@@ -125,7 +129,7 @@ slash commands.
 
 Supported auto-detection:
   - Claude Code  ~/.claude/skills/
-  - Codex CLI    ~/.codex/skills/
+  - Codex CLI    ~/.agents/skills/
 
 Any other harness: pass --target <its skills directory>.
 
@@ -231,9 +235,11 @@ function linkSkill({ name, srcAbs, target, dryRun }) {
 
 function detectTargets(extraTargets) {
   const targets = [];
-  // Auto-detect only when the skills directory itself already exists.
+  // Auto-detect only when the harness's config dir exists (the skills dir may
+  // not exist yet — e.g. ~/.agents/skills for a fresh Codex user — and gets
+  // created at link time).
   for (const known of KNOWN_TARGETS) {
-    if (fs.existsSync(known.dir)) {
+    if (fs.existsSync(known.detect)) {
       targets.push({ ...known, autoDetected: true });
     }
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vruum/skills",
-  "version": "0.5.2",
+  "version": "0.6.0",
   "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": {
@@ -36,5 +36,5 @@
     "outreach",
     "gtm"
   ],
-  "contentHash": "e0050f63b3a0e2e8dfd104839324afe1d385046dc74fe0a2347ba37906ddd7b4"
+  "contentHash": "5f98cbfea97d8be6ad68c50e12dca22533d20dcae067a0d5558d06e173ac1c72"
 }

package/skills/create-content/SKILL.md

@@ -6,7 +6,6 @@ description: >-
   publish. Use when: write a post, draft LinkedIn content, create content, post
   about, content co-production, help me write a post.
 ---
-
 # /create-content
 
 You co-produce a LinkedIn post in the seller's own voice. This is a conversation, not a one-shot generator: you pull the seller's real signal (their calls, posts, notes, knowledge), surface what's there, let them steer the angle, draft on-voice, and then save it the way they want — draft, scheduled, or (only on explicit confirmation) published.
@@ -21,19 +20,36 @@ Open with a single question if the seller hasn't already said what they want to
 
 Keep it light. You're not locking a brief yet — you just need a seed string to retrieve relevant signal. Do not call any tool until you have at least a rough topic.
 
-## Step 2: Pull the seller's signal
+## Step 2: Resolve the author (whose LinkedIn account)
+
+A client can have **multiple people**, each with their own connected LinkedIn account. The post must be drafted from the right person's signal and authored from their account. Before pulling any signal, find out who you're authoring as.
+
+Call `get_channel_status` and read `channels.linkedin_accounts` — a list of accounts, each with `account_id`, `account_name`, `user_id`, `user_name`, `user_email`, `status`, `connected`, `has_sales_nav`, and `quota`.
+
+Then pick the author **`user_id`** to use:
+
+- **`linkedin_accounts` is missing, empty, or the `get_channel_status` call fails** → fall back to the legacy default: omit `author_user_id` entirely on the calls below and proceed. Never block content creation on this lookup.
+- **Exactly one usable account** (one entry with a non-null `user_id`) → silently auto-select that account's `user_id`. Do **not** prompt. **Still pass it explicitly** in Step 3 and Step 5 — do not rely on omitting the param. Omitting it grounds the signal on *you* (the caller) and stores *no* author on the draft, and that single account may belong to a teammate, not you.
+- **More than one usable account** → ask the operator **which person to author as**, presenting each option by `user_name` and `user_email`. The selectable unit is the **person (`user_id`)**, because `author_user_id` is the only selector the signal/draft tools accept — if one person has multiple LinkedIn accounts, this skill can't target them individually (say so if asked). Map the chosen person to their `user_id`.
+- **Skip any account whose `user_id` is null/missing** when counting and presenting options (it isn't addressable as an author).
+
+Hold the resolved `user_id` (or the decision to omit it) and use it consistently for both the signal pull and the draft.
+
+## Step 3: Pull the seller's signal
 
-Call `get_seller_signal_bundle` with the seller's rough topic as the `draft_brief` argument. The brief drives a semantic re-rank, so the more concrete the topic, the more relevant the returned evidence.
+Call `get_seller_signal_bundle` with the rough topic as the `draft_brief` argument. **If you resolved an author `user_id` in Step 2, pass it as the `author_user_id` query param** so the signal is *that person's*, not the caller's. (Omit `author_user_id` only in the legacy-fallback case from Step 2.) The brief drives a semantic re-rank, so the more concrete the topic, the more relevant the returned evidence.
+
+**Trust boundary — handle 403 honestly.** Authoring as another person is permission-guarded server-side (a non-owner can't author as a teammate). If this call (or the draft call in Step 5) returns **403**, STOP: tell the operator plainly that they aren't entitled to author as that person, and ask them to pick a permitted author or have an owner do it. Do **not** retry with `author_user_id` omitted — that would silently fall back to caller/company-scoped generation under a different identity than was asked for.
 
 **Ground on `formatted_evidence`.** It is the EVIDENCE-wrapped rendering prepared for drafting — the surface you should read, quote, and reason over. The backend scrubs prospect names, emails, phone numbers, and URLs out of *everything* it returns (both `formatted_evidence` and the raw `bundle` text), so you don't have to police that yourself — there is no un-redacted surface on the response. Still prefer `formatted_evidence`: it is the prepared, sectioned grounding surface, where `bundle` is just the structured raw material behind it.
 
 `formatted_evidence` can be `null`. Null-check it before using it:
-- If `formatted_evidence` is present → use it as the grounding evidence in Step 3.
+- If `formatted_evidence` is present → use it as the grounding evidence in Step 4.
 - If `formatted_evidence` is `null` (a `formatted_evidence_skipped_reason` of `bundle_empty` means there was no signal to draw on yet; any other reason means the evidence was withheld and the `bundle` text is redacted to empty too) → say so plainly and fall back to a **profile-only draft**: write from the company voice profile and the seller's stated topic alone, with no evidence grounding.
 
-## Step 2.5: Check the calendar (optional)
+## Step 3.5: Check the calendar (optional)
 
-This step is **optional** and **must never gate the loop**. It exists only to make the brief a little smarter, not to add a precondition before drafting. If you skip it, or it returns nothing, or it errors — proceed to Step 3 silently and draft anyway.
+This step is **optional** and **must never gate the loop**. It exists only to make the brief a little smarter, not to add a precondition before drafting. If you skip it, or it returns nothing, or it errors — proceed to Step 4 silently and draft anyway.
 
 If a quick read of what's already on the content calendar would help shape the angle, call `get_content_calendar` **once** (the default `days` window is fine — don't loop or page). Treat the returned `posts` (each with `topic_tags`, `status`, and `scheduled_at`/`published_at`) and the `summary` as planning context only, to:
 
@@ -43,7 +59,7 @@ If a quick read of what's already on the content calendar would help shape the a
 
 Surface anything useful to the seller as a light suggestion ("you posted on this theme last week — want a different angle, or a follow-up?"), never as a blocker. If `posts` is empty, the tool is unavailable, or it errors, say nothing about the calendar and just continue. Do not retry it.
 
-## Step 3: Surface the evidence and settle the brief
+## Step 4: Surface the evidence and settle the brief
 
 If you have `formatted_evidence`, show the seller the relevant points you found, in plain language:
 
@@ -56,19 +72,23 @@ Which of these do you want to anchor the post on? And what's the angle — a les
 
 Let the seller refine. Iterate in conversation until the brief is **settled** — you and the seller agree on the angle, the anchor evidence, and the tone. Do not generate a draft while the brief is still moving.
 
-## Step 4: Draft on-voice — once
+## Step 5: Draft on-voice — once
+
+**Only once the brief is settled**, call `generate_linkedin_post`, passing the settled brief as the `topic` argument. **If you resolved an author `user_id` in Step 2, pass the same value as `author_user_id`** so the draft is written from that person's voice/signal and the draft row is stamped with their `author_user_id` (this is what later carries the author through schedule/publish). Pass the *same* `user_id` you used for the signal pull — don't let signal and draft disagree. Omit `author_user_id` only in the legacy-fallback case. The same **403** trust-boundary rule from Step 3 applies here: on 403, STOP and ask for a permitted author — never retry with the param omitted.
 
-**Only once the brief is settled**, call `generate_linkedin_post`, passing the settled brief as the `topic` argument. The backend writes the draft in the seller's voice and grounds it on their seller signal internally — you do not pass the evidence yourself.
+The backend writes the draft in the seller's voice and grounds it on their seller signal internally — you do not pass the evidence yourself.
 
 `generate_linkedin_post` creates a new draft row every time it runs. Call it **once** per post. Show the seller the returned draft.
 
-## Step 5: Iterate by editing — never regenerate
+## Step 6: Iterate by editing — never regenerate
 
 When the seller wants changes (tighten the hook, change the CTA, fix a line), revise the **existing** draft with `manage_content_post` using `action="edit"`, passing the updated `content`. 
 
 Never call `generate_linkedin_post` again for a revision — that spawns a duplicate draft row and loses the thread. One post = one draft row, edited in place.
 
-## Step 6: Save — draft, schedule, or publish
+`manage_content_post` operates on the existing draft row, which already carries the `author_user_id` you stamped at generation. You do **not** re-pass the author here — schedule/publish inherit it from the row.
+
+## Step 7: Save — draft, schedule, or publish
 
 When the seller is happy with the draft, ask how they want to land it. **Default to keeping it as a draft or scheduling it.**
 
@@ -79,6 +99,15 @@ When the seller is happy with the draft, ask how they want to land it. **Default
   - Only call `manage_content_post` with `action="publish"` **after** the seller has explicitly confirmed "publish now."
   - Always offer save-as-draft or schedule as the safer fallback when proposing publish.
 
+**Author-scoped publish — the backend refuses to fall back to another identity.** Schedule/publish read the author from the draft row. For an author-scoped post (one you authored as a specific person in Step 2, so the draft carries their `author_user_id`), the backend resolves *that person's* LinkedIn account **strictly**: if their account is missing, disconnected, or its `quota` is exhausted at publish time, the publish **fails hard with an `Author account unavailable` error** instead of posting from another connected company account. So an author-scoped post can never silently go out under a *different person's identity* than the one you chose — the server enforces this, including for scheduled posts that publish later at worker execution time (long after this conversation). A legacy / no-author post (you omitted `author_user_id` in Step 2) keeps the old company-wide fallback — there's no specific identity to protect.
+
+Because that hard failure lands at publish time — which for a scheduled post can be minutes or hours after you draft it — surface it **early** rather than letting the operator discover a dead, `failed` post later. So before you schedule or publish a post you authored as a specific person, **call `get_channel_status` again — fresh, right now, immediately before the schedule/publish call.** Do **not** trust the Step 2 snapshot: an account can disconnect, change `status`, or exhaust its `quota` during drafting and refinement. Re-read `channels.linkedin_accounts` from this *new* response and find the author's account by the `user_id` you stamped on the draft, then:
+
+- If their account is present, `connected`, `status` is healthy, and `quota` is not exhausted **in the fresh response** → proceed with schedule/publish as normal (still behind the explicit "publish now" confirmation above).
+- If their account is **missing, not `connected`, shows a bad `status`, or has an exhausted `quota` in the fresh response** (or the fresh `get_channel_status` call fails / omits `linkedin_accounts`, so you can't confirm the author's account is healthy) → **STOP. Do not schedule or publish.** The backend would reject this author-scoped publish as `Author account unavailable` anyway; tell the operator plainly so they don't end up with a `failed` post. Offer the safe paths: keep it as a draft, reschedule for after that person's account is reconnected / their quota resets, or pick a different permitted author and regenerate. There is no "publish under a different identity" escape hatch for an author-scoped post — the server will not do it; to post from another account the operator must deliberately regenerate the draft under that author (or with no author).
+
+For a legacy / no-author post (you omitted `author_user_id` in Step 2) there is no specific author identity to protect, so the standard publish confirmation above is sufficient.
+
 If the seller asks to reschedule a post that is **already scheduled**, be aware that rescheduling an already-scheduled post is not currently supported and may return a "not in draft status" error. Tell the seller this plainly rather than retrying blindly, and offer to keep the existing schedule.
 
 ## Notes

package/skills/csv-pipeline-fill/SKILL.md

@@ -6,16 +6,6 @@ description: >-
   when: import CSV, paste a CSV, csv import, prospect list from CSV, csv harness
   mode.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check` (path relative to this repo). Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention the available upgrade in one line and offer `/vruum-upgrade`. Then continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, then continue.
-- Empty → proceed silently.
-
-Never block skill execution on this check.
-
 # CSV Pipeline Fill (harness source)
 
 You are the CSV harness-mode source for `/pipeline-fill`. You read a CSV the operator provides (Apollo export, ZoomInfo, hand-built spreadsheet, LinkedIn export — anything), normalize columns to the canonical candidate-list shape, and hand off to the orchestrator.

package/skills/deal-triage/SKILL.md

@@ -6,16 +6,6 @@ description: >-
   review deals, triage deals, check pipeline, deal review, morning deals,
   pipeline review, deal health, at-risk deals.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check` (path relative to this repo). Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention the available upgrade in one line and offer `/vruum-upgrade`. Then continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, then continue.
-- Empty → proceed silently.
-
-Never block skill execution on this check.
-
 # Deal Triage
 
 You are a deal pipeline orchestrator. Your job is to efficiently review the seller's active deals by dispatching subagents that do deep deal analysis (timeline, stakeholders, MEDDIC qualification), then presenting structured results back to the seller for decisions.

package/skills/diagnose-reply/SKILL.md

@@ -5,16 +5,6 @@ description: >-
   triggered it. Use when: why did they reply, what worked, diagnose reply, reply
   diagnosis, analyze this reply, what caused this reply, reply analysis.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check` (path relative to this repo). Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention the available upgrade in one line and offer `/vruum-upgrade`. Then continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, then continue.
-- Empty → proceed silently.
-
-Never block skill execution on this check.
-
 # /diagnose-reply
 
 You diagnose individual replies to understand what worked (or didn't) in the outreach that preceded them. This turns every reply into a learning event.

package/skills/engagement-triage/SKILL.md

@@ -6,16 +6,6 @@ description: >-
   warming comments, review nurture reactions, review marketing comments, review
   content drafts, check engagement queue.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check` (path relative to this repo). Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention the available upgrade in one line and offer `/vruum-upgrade`. Then continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, then continue.
-- Empty → proceed silently.
-
-Never block skill execution on this check.
-
 ## MCP smoke test (run early)
 
 Before triaging, confirm Vruum MCP is reachable. Call `get_marketing_overview` as a lightweight liveness check. On failure, surface this error and stop:

package/skills/enrich-prospect/SKILL.md

@@ -6,16 +6,6 @@ description: >-
   profile this person, who is this person, research prospect, diarize prospect,
   prospect briefing.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check` (path relative to this repo). Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention the available upgrade in one line and offer `/vruum-upgrade`. Then continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, then continue.
-- Empty → proceed silently.
-
-Never block skill execution on this check.
-
 # /enrich-prospect
 
 You diarize a prospect. Read everything available — LinkedIn, company research, match analysis, conversation history, knowledge base — and synthesize a one-page structured profile that reveals the gap between what the data says and what's actually going on.

package/skills/expansion-fill/SKILL.md

@@ -6,14 +6,6 @@ description: >-
   Use when: expand customer, find upsell opportunities, NRR play, expansion
   opportunities, customers ripe for expansion, who can we expand to.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check`. Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention upgrade in one line, offer `/vruum-upgrade`, continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, continue.
-- Empty → proceed silently.
-
 # Expansion Fill
 
 You are an expansion-side pipeline filler. While `/pipeline-fill` sources cold prospects, this skill surfaces *existing customers* who are due for an expansion conversation — new product, larger seat count, multi-team rollout, renewal-with-uplift, etc.

package/skills/outreach-triage/SKILL.md

@@ -5,16 +5,6 @@ description: >-
   when: triage, review queue, morning review, check messages, approve outreach,
   what needs review.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check` (path relative to this repo). Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention the available upgrade in one line and offer `/vruum-upgrade`. Then continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, then continue.
-- Empty → proceed silently.
-
-Never block skill execution on this check.
-
 # Outreach Triage
 
 You are an outreach queue orchestrator. Your job is to efficiently process pending outreach messages by dispatching subagents who do review, research, and editing, then presenting results for approval.

package/skills/pipeline-fill/RESEARCH-ENGINE.md

@@ -41,7 +41,7 @@ Before any other Step 3 work, call `get_research_playbook(segment_id=<id>)`. If
 
 > Vruum MCP not configured as a user-scoped server. Run:
 >
-> Register the Vruum MCP server in your assistant once: Claude Code → `~/.claude.json` `mcpServers.vruum-local = {"type":"http","url":"https://api.vruum.ai/mcp"}`; Codex CLI → `~/.codex/config.toml` `[mcp_servers.vruum-local]` with `url = "https://api.vruum.ai/mcp"`; other assistants → connect to `https://api.vruum.ai/mcp` (HTTP, OAuth via standard MCP flow).
+> Register the Vruum MCP server in your assistant once: Claude Code → `~/.claude.json` `mcpServers.vruum = {"type":"http","url":"https://api.vruum.ai/mcp"}`; Codex CLI → `~/.codex/config.toml` `[mcp_servers.vruum]` with `url = "https://api.vruum.ai/mcp"`; other assistants → connect to `https://api.vruum.ai/mcp` (HTTP, OAuth via standard MCP flow).
 >
 > and retry. (The cloud `claude.ai Vruum` connector doesn't propagate to subagents — they need `vruum` configured at the user scope in `~/.claude.json`.)
 

package/skills/pipeline-fill/SKILL.md

@@ -7,16 +7,6 @@ description: >-
   gate. Use when: fill pipeline, import prospects, daily imports, need more
   prospects, discover prospects from scratch, deep research before import.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check` (path relative to this repo). Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention the available upgrade in one line and offer `/vruum-upgrade`. Then continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, then continue.
-- Empty → proceed silently.
-
-Never block skill execution on this check.
-
 # Pipeline Fill
 
 You are a source-agnostic pipeline filler. You pick segments to fill, pick a source per segment (Sales Nav / YC / CSV / discovery), and orchestrate harness deep research that gates against the segment ICP before saving prospects into the backend pipeline.
@@ -45,8 +35,8 @@ This skill uses two subagents (defined in `.claude/agents/`):
 
 Subagents need access to the Vruum MCP server. Register it once in your AI assistant:
 
-- **Claude Code**: `~/.claude.json` → `mcpServers.vruum-local` = `{"type": "http", "url": "https://api.vruum.ai/mcp"}`
-- **Codex CLI**: `~/.codex/config.toml` → `[mcp_servers.vruum-local]` with `url = "https://api.vruum.ai/mcp"`
+- **Claude Code**: `~/.claude.json` → `mcpServers.vruum` = `{"type": "http", "url": "https://api.vruum.ai/mcp"}`
+- **Codex CLI**: `~/.codex/config.toml` → `[mcp_servers.vruum]` with `url = "https://api.vruum.ai/mcp"`
 - **Other**: connect to `https://api.vruum.ai/mcp` (HTTP, OAuth via standard MCP flow)
 
 The orchestrator's MCP precheck at the top of Step 3 (`get_research_playbook` call) catches misconfiguration upfront. Don't skip it.
@@ -141,9 +131,9 @@ Operator gives a brief like "Series A-C SaaS founders, US, 50-500 ppl" or "direc
 2. **Source companies first** — use harness tools to find candidate companies matching the brief:
    - `WebSearch` for funding announcements, news, lists ("Series A SaaS 2026", "TechCrunch Series B SaaS announcements")
    - `WebFetch` on Crunchbase / PitchBook / company directories
-   - `mcp__vruum-local__search_linkedin_people` for company-fitting roles when the brief is people-shaped (e.g. "VPs of Eng at Series A SaaS")
-3. **Source people from each company** — for each candidate company, use `mcp__vruum-local__find_people_at_company` (Unipile-backed; respects LinkedIn rate limits) to find titles matching the segment ICP. Cap at ~5 people per company to spread the discovery surface.
-4. **Dedup against existing pipeline** — for each discovered person, check `mcp__vruum-local__search_existing_people` so you don't research someone the segment already has.
+   - `mcp__vruum__search_linkedin_people` for company-fitting roles when the brief is people-shaped (e.g. "VPs of Eng at Series A SaaS")
+3. **Source people from each company** — for each candidate company, use `mcp__vruum__find_people_at_company` (Unipile-backed; respects LinkedIn rate limits) to find titles matching the segment ICP. Cap at ~5 people per company to spread the discovery surface.
+4. **Dedup against existing pipeline** — for each discovered person, check `mcp__vruum__search_existing_people` so you don't research someone the segment already has.
 5. **Show the discovered list to the operator** before handoff. Format: `Name (title) — Company [linkedin]`. Cap the surface at 2x daily_target so we don't over-source. Get a "go" / "drop X" before continuing.
 
 Discovery-path candidates produced in either path use the canonical shape in `RESEARCH-ENGINE.md` and feed into Step 3 the same way.

package/skills/sales-nav-deep-fill/SKILL.md

@@ -6,16 +6,6 @@ description: >-
   /pipeline-fill for deep research and import. Use when: sales nav with deep
   research, sales nav harness mode, in-chat sales nav.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check` (path relative to this repo). Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention the available upgrade in one line and offer `/vruum-upgrade`. Then continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, then continue.
-- Empty → proceed silently.
-
-Never block skill execution on this check.
-
 # Sales Nav Deep Fill (harness source)
 
 You are the Sales Nav harness-mode source for `/pipeline-fill`. You produce a candidate list from a Sales Nav saved search and hand off to the orchestrator for deep research, harness gate, and save chain.

package/skills/segment-doctor/SKILL.md

@@ -5,16 +5,6 @@ description: >-
   diagnose segment, why is my segment not working, segment health, low reply
   rate, check segments, which segments need help.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check` (path relative to this repo). Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention the available upgrade in one line and offer `/vruum-upgrade`. Then continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, then continue.
-- Empty → proceed silently.
-
-Never block skill execution on this check.
-
 # Segment Doctor
 
 You are a segment diagnostics and optimization agent. Your job is to identify struggling segments, diagnose root causes, and recommend (or apply) fixes.

package/skills/winback-fill/SKILL.md

@@ -7,14 +7,6 @@ description: >-
   revive cold deals, 90-day silent revival, lost deal recovery, lost customer
   outreach.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check`. Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention upgrade in one line, offer `/vruum-upgrade`, continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, continue.
-- Empty → proceed silently.
-
 # Winback Fill
 
 You are a winback-side pipeline filler. While `/expansion-fill` targets won-and-quiet customers, this skill surfaces *lost or churned* relationships where re-engagement is still plausible.

package/skills/yc-pipeline-fill/SKILL.md

@@ -6,16 +6,6 @@ description: >-
   /pipeline-fill for deep research and import. Use when: YC pipeline fill,
   source from YC, fill segment with YC founders, sales nav dried up, source YC.
 ---
-
-## Auto-update check
-
-Before starting, run `~/.vruum/bin/vruum-skills-update-check` (path relative to this repo). Interpret output:
-- `UPGRADE_AVAILABLE <old> <new>` → mention the available upgrade in one line and offer `/vruum-upgrade`. Then continue.
-- `JUST_UPGRADED <old> <new>` → acknowledge in one line, then continue.
-- Empty → proceed silently.
-
-Never block skill execution on this check.
-
 # YC Pipeline Fill (harness source)
 
 You are the YCombinator harness-mode source for `/pipeline-fill`. You scrape YC's public directory, extract founder LinkedIn URLs, dedup, and hand a candidate list to the orchestrator. No deep research, no harness gate, no save chain in this skill — that's all in `pipeline-fill/RESEARCH-ENGINE.md`.