@vruum/skills 0.6.4 → 0.6.6

package/skills/pipeline-fill/SKILL.md

@@ -29,7 +29,7 @@ When you reach Step 3, **stop and read** `RESEARCH-ENGINE.md`. That doc is the c
 
 This skill uses two subagents (defined in `.claude/agents/`):
 - `vruum-company-deep-researcher` — Phase A, one per unique company in the batch (max 10 in parallel)
-- `vruum-prospect-deep-researcher` — Phase B, one per person (max 5 in parallel — Phase B is rate-limited because it calls `fetch_linkedin_data`)
+- `vruum-prospect-deep-researcher` — Phase B, one per person (max 5 in parallel — Phase B is rate-limited because it calls `research` action=linkedin_fetch)
 
 ### MCP access requirements (load-bearing)
 
@@ -39,7 +39,7 @@ Subagents need access to the Vruum MCP server. Register it once in your AI assis
 - **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.
+The orchestrator's MCP precheck at the top of Step 3 (the `fetch` type=research_playbook call) catches misconfiguration upfront. Don't skip it.
 
 ### Dispatch methods (in order of preference)
 
@@ -56,7 +56,7 @@ The orchestrator's MCP precheck at the top of Step 3 (`get_research_playbook` ca
 
 ## Workflow — Step 1: Show pipeline status & pick segments
 
-Call `manage_sales_nav_searches(action="list")` + `get_outreach_stats` for queue depth + `get_campaigns` for non-Sales-Nav segments. Present a numbered table with **per-segment ETA**:
+Call `import_prospects(action="sales_nav_searches", payload={action: "list"})` + `fetch(type="stats", subtype="outreach")` for queue depth + `search(type="campaigns")` for non-Sales-Nav segments. Present a numbered table with **per-segment ETA**:
 
 ```
 Pipeline status:
@@ -100,8 +100,8 @@ The conditional rendering happens at package-build time, not at skill-runtime
 
 Per source pick, dispatch:
 
-- `sales-nav-platform` → invoke `/sales-nav-platform-fill` (calls `import_from_sales_nav`; backend handles everything; **skip Steps 3-8 of this skill entirely** — backend agents own the rest).
-- `csv-platform` → invoke `/csv-platform-fill` (calls `start_csv_import`; backend handles everything; same — skip Steps 3-8).
+- `sales-nav-platform` → invoke `/sales-nav-platform-fill` (calls `import_prospects` action=sales_nav_import; backend handles everything; **skip Steps 3-8 of this skill entirely** — backend agents own the rest).
+- `csv-platform` → invoke `/csv-platform-fill` (calls `import_prospects` action=csv_start; backend handles everything; same — skip Steps 3-8).
 - `sales-nav-deep` → invoke `/sales-nav-deep-fill` to produce a candidate list, then continue to Step 3 with it.
 - `yc` → invoke `/yc-pipeline-fill` to produce a candidate list, then continue to Step 3 with it.
 - `csv` → invoke `/csv-pipeline-fill` to produce a candidate list, then continue to Step 3 with it.
@@ -116,7 +116,7 @@ Discovery mode covers two paths off the same prompt:
 **Path A — operator pastes candidates** (you already know who you want)
 Tolerant line parser, candidates produced directly:
 
-- **Line is a LinkedIn URL** (matches `^https?://(www\.)?linkedin\.com/in/[^/?]+/?(\?.*)?$`) → set `linkedin_url`, leave `name` and `company` null. Phase B will fill them via `fetch_linkedin_data`.
+- **Line is a LinkedIn URL** (matches `^https?://(www\.)?linkedin\.com/in/[^/?]+/?(\?.*)?$`) → set `linkedin_url`, leave `name` and `company` null. Phase B will fill them via the linkedin_fetch research call.
 - **Line has comma(s)** → split as `name, company[, linkedin_url][, email]`. If 4 fields, last is email. If 3 fields, last is linkedin_url IF it matches the LinkedIn URL pattern, else interpret as email if it has `@`, else treat as a 2-field line + extra junk.
 - **Line is just text** → treat as `full_name`, prompt operator: "what company for {full_name}?". If the operator gets prompted for >3 lines, ask once "set company={X} for all unspecified?" to batch.
 
@@ -127,13 +127,13 @@ Drop blank lines and lines starting with `#` (treat as comments).
 **Path B — operator describes an ICP** (you want the harness to discover candidates)
 Operator gives a brief like "Series A-C SaaS founders, US, 50-500 ppl" or "directors of operations at MSPs in DFW, recently posted about hiring". Harness sources candidates from scratch:
 
-1. **Anchor on segment ICP** — read the segment's existing ICP/company profile (via `get_campaign` and `get_company_profile`) and merge with the operator's brief. Show a one-line synthesis ("OK so: Series A-C SaaS, US, 50-500 ppl, founder/CEO/CTO titles") and confirm before sourcing.
+1. **Anchor on segment ICP** — read the segment's existing ICP/company profile (via `fetch` type=campaign and `fetch` type=settings subtype=profile) and merge with the operator's brief. Show a one-line synthesis ("OK so: Series A-C SaaS, US, 50-500 ppl, founder/CEO/CTO titles") and confirm before sourcing.
 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__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.
+   - `mcp__vruum__import_prospects` with action=sales_nav_search (payload={keywords, title, limit}) 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__search` with type=companies and filters={domain, seniority} (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` with type=people and a name/company keyword query 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

@@ -10,7 +10,7 @@ description: >-
 
 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.
 
-**This is the harness counterpart to `/sales-nav-platform-fill`.** The platform skill calls `import_from_sales_nav` and lets backend agents do everything (Vruum's compute). This skill stops at producing a candidate list — Phase A and Phase B run in your chat session (your harness compute), and `save_discovered_person` is called only after the harness pre-filter gate passes. Pick this when you want visibility into the deep research as it happens.
+**This is the harness counterpart to `/sales-nav-platform-fill`.** The platform skill calls `import_prospects` with action=sales_nav_import and lets backend agents do everything (Vruum's compute). This skill stops at producing a candidate list — Phase A and Phase B run in your chat session (your harness compute), and `manage_person` with action=save_discovered is called only after the harness pre-filter gate passes. Pick this when you want visibility into the deep research as it happens.
 
 ## Inputs
 
@@ -21,7 +21,7 @@ You are the Sales Nav harness-mode source for `/pipeline-fill`. You produce a ca
 
 ### Step 1: Preview Sales Nav profiles
 
-Call `preview_sales_nav_search(segment=..., count=...)`. Returns profile data + segment ICP context (target_titles, target_industries, value_proposition, positioning_angle, differentiators).
+Call `import_prospects(action="sales_nav_preview", payload={segment: ..., count: ...})`. Returns profile data + segment ICP context (target_titles, target_industries, value_proposition, positioning_angle, differentiators).
 
 ### Step 2: Dispatch `vruum-pipeline-filter` for ICP pre-filter
 
@@ -57,6 +57,6 @@ Continue automatically? (y/n)
 
 ## Notes
 
-- **For the operator:** pick this when you want to see the deep research happen, want to interrupt mid-stream, or want zero platform compute cost on the front-half (sourcing + research). The back-half (`save_discovered_person`'s `analyze_person_match` + `match_score >= 70` gate) still runs on Vruum, intentionally — it's the canonical gate.
-- **Don't call `import_from_sales_nav` directly from this skill.** That triggers the backend research pipeline, which is exactly what we're avoiding by being in harness mode. If you need the backend path, use `/sales-nav-platform-fill` instead.
+- **For the operator:** pick this when you want to see the deep research happen, want to interrupt mid-stream, or want zero platform compute cost on the front-half (sourcing + research). The back-half (`manage_person` action=save_discovered, which runs `analyze_person_match` + the `match_score >= 70` gate) still runs on Vruum, intentionally — it's the canonical gate.
+- **Don't call `import_prospects` with action=sales_nav_import directly from this skill.** That triggers the backend research pipeline, which is exactly what we're avoiding by being in harness mode. If you need the backend path, use `/sales-nav-platform-fill` instead.
 - **vruum-pipeline-filter pre-filter is FREE** for the operator (cheap title/company match). The expensive Phase B research only fires on prospects that survive that filter.

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

@@ -9,7 +9,7 @@ tenant bind to choose.
 
 ```
 # Step 1: pull closed-lost deals (scoped to your session's tenant)
-lost = get_deals(outcome="lost", limit=200)
+lost = search(type="deals", filters={"outcome": "lost"}, limit=200)
 
 # Step 2: keep deals lost between 90 days and 18 months ago
 ninety_days_ago = now() - 90 days
@@ -26,7 +26,7 @@ revivable = [
 ]
 
 # Step 4: drop people who currently have an OPEN deal (NULL outcome)
-open_deals = get_deals(outcome=None, limit=500)
+open_deals = search(type="deals", filters={"outcome": None}, limit=500)
 open_person_ids = { d.person_id for d in open_deals.deals }
 candidates = [d for d in revivable if d.person_id not in open_person_ids]
 ```
@@ -40,7 +40,7 @@ thanks" buyer from being re-pitched while the rejection is still fresh.
 
 Why this works without a DB query:
 
-- `get_deals` is tenant-scoped server-side.
+- `search` type=deals is tenant-scoped server-side.
 - The old `company_people` JOIN (to resolve account from person) is replaced
   by `get_person_360` in the skill's Step 3 enrichment — call it per
   surfaced person; `current_positions[0].company_id` is the account.
@@ -52,8 +52,8 @@ The "warmest cold-outreach possible" play.
 
 ```
 # Step 1: pull historic deals (lost OR won, since won-then-churned applies)
-historic_lost = get_deals(outcome="lost", limit=200).deals
-historic_won  = get_deals(outcome="won",  limit=200).deals
+historic_lost = search(type="deals", filters={"outcome": "lost"}, limit=200).deals
+historic_won  = search(type="deals", filters={"outcome": "won"},  limit=200).deals
 former_buyer_person_ids = {
     d.person_id for d in (historic_lost + historic_won)
     if parse(d.stage_changed_at or d.actual_close_date) < (now() - 60 days)
@@ -80,12 +80,12 @@ funding, press, layoff at a competitor) and use the trigger as the revival
 hook.
 
 ```
-# Per surfaced account (from Variant 1), call get_company_research to see
+# Per surfaced account (from Variant 1), fetch type=company_research to see
 # if any recent news/event was captured in the last 14 days. The harness
 # does not currently expose a direct "list firing triggers" tool in the
 # public MCP — read recent triggers off the company_research payload.
 for d in variant_1_candidates:
-    research = get_company_research(company_id=d.account_company_id)
+    research = fetch(type="company_research", id=d.account_company_id)
     fresh_triggers = [
         t for t in (research.recent_signals or [])
         if (now() - parse(t.fired_at)) < 14 days
@@ -95,13 +95,13 @@ for d in variant_1_candidates:
         ...
 ```
 
-If `get_company_research` returns no recent signals, this variant degrades
+If the company_research fetch returns no recent signals, this variant degrades
 to Variant 1 silently — no harm done.
 
 ## Why these recipes are safe
 
 All three variants:
-- Run through `get_deals` / `get_person_360` / `get_company_research`, all of
+- Run through `search` type=deals / `get_person_360` / `fetch` type=company_research, all of
   which derive `user_company_id` from your authenticated session. You CANNOT
   choose a different tenant.
 - Exclude terminal loss reasons (`no_fit`, `no_budget_permanent`) in

package/skills/winback-fill/SKILL.md

@@ -24,10 +24,10 @@ The impact scoreboard and the `account_stage='churned'`/`'dormant'` tagging let
 ## Where heavy logic lives
 
 [`COHORT-QUERIES.md`](./COHORT-QUERIES.md) — three Vruum-MCP cohort recipes
-(all `get_deals` + post-filter; tenant scope is automatic from your session):
+(all `search` type=deals + post-filter; tenant scope is automatic from your session):
 1. **90-day silent-deal revival** (default): lost deals >90d old, person still at company, loss reason not terminal
 2. **Champion-follows-you**: former champion moved to a new company (re-targeted at new co via `get_person_360.current_positions`)
-3. **Trigger-driven winback**: surfaced via fresh signals on `get_company_research` (new exec, funding, press)
+3. **Trigger-driven winback**: surfaced via fresh signals on `fetch` type=company_research (new exec, funding, press)
 
 Start with cohort 1 unless you specify otherwise.
 
@@ -35,13 +35,13 @@ Start with cohort 1 unless you specify otherwise.
 
 Step 1 — Read scoreboard.
 ```
-get_account_impact_scoreboard(window_days=90)
+fetch(type="scoreboard", subtype="impact", filters={"window_days": 90})
 ```
 Surface practice rollups. Empty state → fall through to day-1 heuristic.
 
 Step 2 — Build the cohort using the recipes in `COHORT-QUERIES.md`. All
-recipes use `get_deals` + post-filter via the Vruum MCP; tenant scope is
-automatic from your authenticated session. Pick a variant per your intent
+recipes use `search` type=deals + post-filter via the Vruum MCP; tenant scope
+is automatic from your authenticated session. Pick a variant per your intent
 (default: variant 1).
 
 For variant 1 (silent-deal revival), the cohort criteria:
@@ -50,13 +50,13 @@ For variant 1 (silent-deal revival), the cohort criteria:
 - `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
-  `get_deals(outcome=None)`)
+  `search` type=deals filters={outcome: None})
 
 Limit 50. Order by `stage_changed_at DESC` (most-recent loss first — freshest memory of the conversation).
 
 Step 3 — Per-account enrichment.
 - `get_person_360` — what was the original conversation? `analysis` JSONB on the old deal often captures objection patterns.
-- `get_company_research` — has anything changed at the company? New exec? Funding? Recent news?
+- `fetch` type=company_research — has anything changed at the company? New exec? Funding? Recent news?
 - `accounts.account_stage` — if `churned`, the account has been flagged as dead. Skip or down-rank unless variant 2/3 applies.
 
 Step 4 — Score and rank.
@@ -84,18 +84,21 @@ If no hook can be generated → defer the row. Warm via marketing/content first,
 
 Step 6 — Hand off. Two options:
 - **Option A (recommended)**: Approve the list; run `/pipeline-fill` with the prospect_list for harness deep research + outreach. Plans get `outreach_plans.tag = bowtie_pilot:winback`.
-- **Option B**: Direct `start_outreach` with a winback-flavored segment (pre-create a `winback_<your-tenant>` segment — tone: empathetic, no apology, lead with what changed since last conversation).
+- **Option B**: Direct `manage_outreach` action=start with a winback-flavored segment (pre-create a `winback_<your-tenant>` segment — tone: empathetic, no apology, lead with what changed since last conversation).
 
-Step 7 — Success tracking (auto). The calendar webhook fires:
+Step 7 — Success tracking (auto). The calendar webhook records the impact event, equivalent to:
 ```
-record_impact_event(
-  practice='winback',
-  event_type='winback_meeting_booked',
-  value_delivered_numeric=deal.estimated_value,
-  ...
+manage_account(
+  action="record_impact",
+  payload={
+    practice: 'winback',
+    event_type: 'winback_meeting_booked',
+    value_delivered_numeric: deal.estimated_value,
+    ...
+  }
 )
 ```
-when a meeting is booked on a plan tagged `bowtie_pilot:winback`. You do NOT manually fire for tagged plans. After 30 days, `get_account_impact_scoreboard` should show winback `event_count` > 0.
+when a meeting is booked on a plan tagged `bowtie_pilot:winback`. You do NOT manually fire for tagged plans. After 30 days, `fetch` type=scoreboard subtype=impact should show winback `event_count` > 0.
 
 ## When NOT to use this skill
 
@@ -111,4 +114,4 @@ See `docs/ACCOUNT-LIFECYCLE-VOCABULARY.md` for the 8 canonical account-lifecycle
 
 ## Backend authoritative gate
 
-Same pattern as `/expansion-fill`: harness-mode uplift; the backend's `record_impact_event` is the authoritative write surface with dedupe.
+Same pattern as `/expansion-fill`: harness-mode uplift; the backend's impact-event write (`manage_account` action=record_impact) is the authoritative surface with dedupe.

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

@@ -29,11 +29,11 @@ If the operator runs the skill without filters, prompt: "YC has 5K+ companies
 
 ### Step 1: Load segment ICP
 
-Call `get_research_playbook(segment_id=<id>)` to load ICP context. The downstream subagents need it for classification; capture it now to pass forward.
+Call `fetch` type=research_playbook id=<segment_id> to load ICP context. The downstream subagents need it for classification; capture it now to pass forward.
 
 ### Step 2: Algolia connectivity precheck
 
-Issue a one-shot Algolia query against the index with `hitsPerPage: 1` to confirm extraction works. **Do NOT use `manage_sales_nav_searches(action="accounts")`** as a precheck — that endpoint checks LinkedIn account state and has nothing to do with YC. False-fails operators who don't have Sales Nav configured (eng review §1B).
+Issue a one-shot Algolia query against the index with `hitsPerPage: 1` to confirm extraction works. **Do NOT use `import_prospects` action=sales_nav_searches payload={action: "accounts"}** as a precheck — that endpoint checks LinkedIn account state and has nothing to do with YC. False-fails operators who don't have Sales Nav configured (eng review §1B).
 
 The precheck happens implicitly in Step 3 (the first real Algolia call); if it fails there, abort with a clear error.
 
@@ -101,7 +101,7 @@ After decoding, regex out:
 **Pick primary founder:**
 1. First founder where `title` matches `/CEO|Chief Exec|Co-?founder & CEO/i` (case-insensitive)
 2. Else first founder where `linkedin_url` is non-empty
-3. Else **drop the company entirely.** Do not call `find_person_linkedin` to guess — produces low-confidence matches and noise.
+3. Else **drop the company entirely.** Do not call `research` action=find_linkedin to guess — produces low-confidence matches and noise.
 
 **HTML revision detection:** If >30% of candidates yield zero founders (regex didn't match), abort the run with: "YC company page structure changed — scrape regex needs updating." Don't silently degrade. Single-company misses are tolerable.
 
@@ -161,7 +161,7 @@ Continue automatically? (y/n)
 
 - **Algolia key extraction fails** (no candidates work): abort, single-line error pointing at the homepage structure.
 - **>30% scrape failure**: abort, point at the company-page structure.
-- **No founder LinkedIn for a company**: drop the company; never guess via `find_person_linkedin`.
+- **No founder LinkedIn for a company**: drop the company; never guess via the find_linkedin research action.
 - **Pool exhaustion**: flag in candidate list metadata so the orchestrator's report surfaces it.
 - **Operator gives no filters**: prompt for at least one. No silent defaults.
 - **Operator gives `count` of 200+**: still works; expect ~30+ minute wall-clock for the full pipeline-fill flow.