@vruum/skills 0.6.5 → 0.6.6

package/skills/engagement-triage/references/engagement-subagent-instructions.md

@@ -67,20 +67,22 @@ Reactions are usually KEEP. Only edit if reaction_type is wrong for the post con
 ### 2e. Budget check
 If `budget_status` shows the sender account near daily limits, note it in REASONING (the operator may want to defer some approvals).
 
-## Step 3: Apply the uplift via manage_engagement
+## Step 3: Apply the uplift via manage_engagements
 
-When RECOMMENDATION=uplifted, write back via `manage_engagement`:
+When RECOMMENDATION=uplifted, write back via `manage_engagements`:
 
 ```
-manage_engagement(
-  engagement_ids="<id>",
+manage_engagements(
   action="edit",
-  content="<your uplifted comment>",
-  polish_provenance={
-    "source": "skill",
-    "model": "<your model — claude-opus-4-7 / claude-sonnet-4-6 / etc.>",
-    "at": "<ISO8601 timestamp>",
-    "rewrite_notes": "<one line: what changed and why>"
+  id="<id>",
+  payload={
+    "content": "<your uplifted comment>",
+    "polish_provenance": {
+      "source": "skill",
+      "model": "<your model — claude-opus-4-7 / claude-sonnet-4-6 / etc.>",
+      "at": "<ISO8601 timestamp>",
+      "rewrite_notes": "<one line: what changed and why>"
+    }
   }
 )
 ```
@@ -116,6 +118,6 @@ VALIDATOR_FAILURES_FIXED: {comma-separated codes you cleared, or "none"}
 ## Error handling
 
 - **MCP call failure**: retry once. If it still fails, set RECOMMENDATION=flag with REASONING="MCP error: <message>" and continue with the next item. Don't abort the whole batch.
-- **manage_engagement write fails (idempotency)**: report failure in REASONING; the operator can re-run. The skill keeps partial state in `/tmp/engagement-triage-$$/pending.jsonl` (parent skill responsibility).
+- **manage_engagements write fails (idempotency)**: report failure in REASONING; the operator can re-run. The skill keeps partial state in `/tmp/engagement-triage-$$/pending.jsonl` (parent skill responsibility).
 - **No polished_floor AND no first_draft AND no content**: the queue row is malformed; flag with REASONING="malformed_queue_row, no draft to uplift".
 - **Empty dossier + empty post text**: flag with REASONING="no grounding available".

package/skills/enrich-prospect/SKILL.md

@@ -16,13 +16,13 @@ This is not a database lookup. This is an analyst's brief.
 
 Call these in parallel:
 - `get_person_360` — profile, match analysis, research, activity, outreach plan, deal
-- `get_person_research` — structured research data (if exists)
-- `get_company_research` — company intelligence
+- `fetch` type=person_research — structured research data (if exists)
+- `fetch` type=company_research — company intelligence
 
 If research is thin (no person_research, or match_analysis is null):
-- `fetch_linkedin_data` — pull their recent posts and profile
+- `research` action=linkedin_fetch — pull their recent posts and profile
 - WebSearch for "[person name] [company name]" — recent news, talks, publications
-- `search_knowledge_base` — relevant sales docs
+- `search` type=kb — relevant sales docs
 
 ## Step 2: Diarize
 
@@ -69,7 +69,7 @@ No embedding search finds these gaps. No keyword filter finds them. You have to
 
 "Append this diarization as a note? It will appear on the person card timeline and be visible to the outreach agent when writing messages."
 
-If approved: call `add_person_note` with a condensed version of the diarization (the SAYS/ACTUALLY gap, key signals, and recommended approach). Each call appends a new row to the person's notes timeline — no overwrite of prior notes.
+If approved: call `manage_person` action=note (payload={body}) with a condensed version of the diarization (the SAYS/ACTUALLY gap, key signals, and recommended approach). Each call appends a new row to the person's notes timeline — no overwrite of prior notes.
 
 ## Notes
 

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

@@ -12,29 +12,29 @@ exposes.
 
 ```
 # Step 1: pull closed-won deals (results are scoped to your session's tenant)
-won = get_deals(outcome="won", limit=200)
+won = search(type="deals", filters={"outcome": "won"}, limit=200)
 
 # Step 2: keep deals whose actual_close_date is more than 60 days old
 cutoff = now() - 60 days
 won_old = [d for d in won.deals if parse(d.actual_close_date) < cutoff]
 
 # Step 3: drop people who currently have an OPEN deal (i.e., a deal with
-# outcome=None on the same person). If you can call get_deals with no outcome
-# filter, post-filter; otherwise rely on Step 3 of the skill workflow where
-# get_person_360 surfaces each person's full deal history.
-open_deals = get_deals(outcome=None, limit=500)  # NULL outcome = still open
+# outcome=None on the same person). If you can call search type=deals with no
+# outcome filter, post-filter; otherwise rely on Step 3 of the skill workflow
+# where get_person_360 surfaces each person's full deal history.
+open_deals = search(type="deals", filters={"outcome": None}, limit=500)  # NULL outcome = still open
 open_person_ids = { d.person_id for d in open_deals.deals }
 candidates = [d for d in won_old if d.person_id not in open_person_ids]
 ```
 
 If you have more than 200 won deals, paginate with the `offset` parameter on
-`get_deals`. Cap the candidate list to the most recently won 50 (sort by
+`search`. Cap the candidate list to the most recently won 50 (sort by
 `actual_close_date DESC`) before per-account enrichment.
 
 Why this works without a DB query:
 
-- `get_deals` is tenant-scoped server-side; you don't (and can't) choose the
-  tenant.
+- `search` type=deals is tenant-scoped server-side; you don't (and can't)
+  choose the tenant.
 - Account-to-person mapping (the old `company_people` JOIN) is resolved by
   `get_person_360` in Step 3 of the skill workflow — call it per surfaced
   person and read `current_positions[0].company_id`.
@@ -42,8 +42,8 @@ Why this works without a DB query:
 ## Optional refinement: account stage is tagged
 
 If your team has been tagging account lifecycle stages on the Vruum
-dashboard, call `get_account_state(company_id=<id>)` for each candidate in
-the skill's Step 3 enrichment and:
+dashboard, call `fetch(type="account_state", id=<company_id>)` for each
+candidate in the skill's Step 3 enrichment and:
 
 - Up-rank rows where `account_stage` is `adopting` or `expansion_ready`.
 - Down-rank or skip rows where `account_stage` is `dormant` or `churned` —
@@ -57,20 +57,21 @@ Vruum dashboard by whoever owns the account lifecycle.
 ## Scoring inputs (consumed by skill Step 4)
 
 Per-account features the skill computes from `get_person_360` +
-`get_company_research`:
+`fetch` type=company_research:
 
-- `accounts.renewal_at` (from `get_account_state`) — proximity weight
+- `accounts.renewal_at` (from `fetch` type=account_state) — proximity weight
   (60-180d sweet spot)
 - `accounts.health_score` — gate (>70 only)
 - `accounts.account_stage` — boost (`adopting`, `expansion_ready`) or skip
   (`dormant`, `churned`)
 - Most recent `practice='adoption'` activity in last 60d — engagement signal
 - Recent touch sent + reply received → champion present
-- New hire signals on company LinkedIn (via `fetch_linkedin_data`) — fresh
-  stakeholder = hook
-- New dept created (via `fetch_linkedin_data`) — multi-team expansion play
-- Recent product/news events (via `fetch_company_website` or research) —
-  timing hook
+- New hire signals on company LinkedIn (via `research` action=linkedin_fetch)
+  — fresh stakeholder = hook
+- New dept created (via `research` action=linkedin_fetch) — multi-team
+  expansion play
+- Recent product/news events (via `research` action=enrich_company or saved
+  research) — timing hook
 
 ## Hook generation
 

package/skills/expansion-fill/SKILL.md

@@ -16,31 +16,31 @@ The post-sale side (Onboarding → Adoption → Expansion → Win-back) is where
 
 ## Where heavy logic lives
 
-[`COHORT-QUERIES.md`](./COHORT-QUERIES.md) — the cohort recipes (Vruum-MCP harness flow + scoring rationale). Read it before running the workflow if you need to understand or tweak the cohort definition. All recipes use `get_deals` + post-filter; tenant scope is automatic from your session.
+[`COHORT-QUERIES.md`](./COHORT-QUERIES.md) — the cohort recipes (Vruum-MCP harness flow + scoring rationale). Read it before running the workflow if you need to understand or tweak the cohort definition. All recipes use `search` type=deals + post-filter; tenant scope is automatic from your session.
 
 ## Workflow
 
 Step 1 — Read the impact scoreboard.
 ```
-get_account_impact_scoreboard(window_days=90)
+fetch(type="scoreboard", subtype="impact", filters={"window_days": 90})
 ```
 - If `state == "no_events_yet"`: no impact data yet — fall through to the cohort SQL below to use the day-1 heuristic. Mention that the scoreboard is empty so you understand why this is running off deal data not impact events.
 - Otherwise: surface the practice rollups so you see current state.
 
 Step 2 — Build the cohort.
 Follow the **primary cohort** recipe in `COHORT-QUERIES.md`. The recipe runs
-`get_deals(outcome="won")` and post-filters in-memory; tenant scope is
-automatic from your authenticated session. Cohort criteria:
+`search(type="deals", filters={"outcome": "won"})` and post-filters in-memory;
+tenant scope is automatic from your authenticated session. Cohort criteria:
 - A deal closed `won` more than 60 days ago AND
 - No open deal exists on the same person now (post-filter against
-  `get_deals(outcome=None)`) AND
+  `search` type=deals filters={outcome: None}) AND
 - The person is still surfaceable via `get_person_360` (Step 3 enrichment).
 
 Limit 50. Order by `actual_close_date DESC` (most recently won first — freshest relationship).
 
 Step 3 — Per-account enrichment. For each surfaced (person, company):
 - `get_person_360(person_id=<id>)` — pulls current title, recent activity, last touch, deal history
-- `get_company_research(company_id=<id>)` — pulls firmographics, recent news/triggers
+- `fetch(type="company_research", id=<company domain>)` — pulls firmographics, recent news/triggers
 
 Step 4 — Score and rank. Within the cohort, rank by:
 - (a) **Renewal pressure** — `accounts.renewal_at` within 60-180 days → up-rank
@@ -60,24 +60,27 @@ Step 5 — Surface a ranked table:
 | 1    | Acme    | Tyler T  | adopt  | 85     | 47d     | 3 new dept LinkedIns past 30d |
 ```
 
-For each row, include a one-line "hook" — a specific recent observation from `get_person_360` or `get_company_research` (new hire, new dept, news event, product usage signal) that frames the expansion conversation. **Never push expansion without a hook** — generic "checking in" outreach kills relationships.
+For each row, include a one-line "hook" — a specific recent observation from `get_person_360` or `fetch` type=company_research (new hire, new dept, news event, product usage signal) that frames the expansion conversation. **Never push expansion without a hook** — generic "checking in" outreach kills relationships.
 
 Step 6 — Hand off to outreach. Two options:
 - **Option A (recommended)**: Approve the ranked list, then for each account: run `/pipeline-fill` with that prospect_list — same Sales Nav harness flow, just sourced from the expansion cohort instead of cold. Tag the resulting `outreach_plans.tag` with `bowtie_pilot:expansion` so success-tracking finds them.
-- **Option B**: Direct `start_outreach` with an expansion-flavored segment (pre-create an `expansion_<your-tenant>` segment with the right tone — formal, ROI-focused, no opener-hooks since the customer already knows you).
+- **Option B**: Direct `manage_outreach` action=start with an expansion-flavored segment (pre-create an `expansion_<your-tenant>` segment with the right tone — formal, ROI-focused, no opener-hooks since the customer already knows you).
 
-Step 7 — Success tracking (auto). When a calendar webhook fires a `meeting_booked` event on an outreach plan tagged `bowtie_pilot:expansion`, the webhook handler in `backend/app/domains/calendar/` auto-fires:
+Step 7 — Success tracking (auto). When a calendar webhook fires a `meeting_booked` event on an outreach plan tagged `bowtie_pilot:expansion`, the webhook handler in `backend/app/domains/calendar/` auto-records the impact event, equivalent to:
 ```
-record_impact_event(
-  practice='expansion',
-  event_type='expansion_meeting_booked',
-  value_delivered_numeric=deal.estimated_value,
-  ...
+manage_account(
+  action="record_impact",
+  payload={
+    practice: 'expansion',
+    event_type: 'expansion_meeting_booked',
+    value_delivered_numeric: deal.estimated_value,
+    ...
+  }
 )
 ```
-You do NOT manually invoke `record_impact_event` for tagged plans. If a meeting is booked outside Vruum (manual scheduling, calendar tool not connected), manually invoke `record_impact_event` from the person 360 Activity tab.
+You do NOT manually record the impact event for tagged plans. If a meeting is booked outside Vruum (manual scheduling, calendar tool not connected), record it manually via `manage_account` action=record_impact from the person 360 Activity tab.
 
-After 30 days, run `get_account_impact_scoreboard` to measure cohort uplift: expansion `event_count` should be > 0 with `impact_sum` matching booked deal values.
+After 30 days, run `fetch` type=scoreboard subtype=impact to measure cohort uplift: expansion `event_count` should be > 0 with `impact_sum` matching booked deal values.
 
 ## When NOT to use this skill
 
@@ -92,4 +95,4 @@ See `docs/ACCOUNT-LIFECYCLE-VOCABULARY.md` for the 8 canonical account-lifecycle
 
 ## Backend authoritative gate
 
-This skill is harness-mode: the harness picks the cohort, scores, and ranks. The backend's authoritative gate is `record_impact_event` itself — the dedupe key `(user_company_id, company_id, activity_type, source_type, source_id)` prevents double-write. The harness is uplift, not the SLA floor.
+This skill is harness-mode: the harness picks the cohort, scores, and ranks. The backend's authoritative gate is the impact-event write itself (`manage_account` action=record_impact) — the dedupe key `(user_company_id, company_id, activity_type, source_type, source_id)` prevents double-write. The harness is uplift, not the SLA floor.

package/skills/outreach-triage/SKILL.md

@@ -16,7 +16,7 @@ Reviewing outreach messages is context-expensive. Each message with full context
 ## Subagent architecture
 
 This skill uses the custom agent `vruum-outreach-reviewer` (bundled at `agents/vruum-outreach-reviewer.md`). That agent has:
-- Full Vruum MCP access (can call get_outreach_review, edit_message, search_knowledge_base, etc.)
+- Full Vruum MCP access (can call get_outreach_review, manage_messages, search, etc.)
 - Web search for prospect research
 - Complete review instructions baked into its system prompt
 
@@ -28,7 +28,7 @@ For small queues (5 or fewer) or when subagents can't access MCP, review directl
 
 ### Step 1: Get the lay of the land
 
-Call `get_outreach_stats` to see the pending queue shape. Present a quick summary:
+Call `fetch` with type=stats and subtype=outreach to see the pending queue shape. Present a quick summary:
 
 "You have X reply responses, Y pending T1s, Z T2+ follow-ups. [Any critical alerts.] Want me to run full triage or focus on a specific category?"
 
@@ -36,7 +36,7 @@ Keep it short. The user knows their queue — they just need the numbers to deci
 
 ### Step 2: Build the dispatch list and categorize
 
-Once the user says go (or picks a focus area), pull the lightweight message queue via `get_message_queue` with `status=draft` and `limit=100`. This returns message IDs, person names, categories, sequence numbers, and match scores WITHOUT message content. Very cheap on tokens.
+Once the user says go (or picks a focus area), pull the lightweight message queue via `search` with type=messages, a status=draft filter, and limit=100. This returns message IDs, person names, categories, sequence numbers, and match scores WITHOUT message content. Very cheap on tokens.
 
 Categorize into three processing groups:
 
@@ -96,7 +96,7 @@ For each message:
 4. Rate personalization depth (surface/basic/deep)
 5. Check strategic fit (CTA matches stage, moves conversation forward)
 
-If a message needs fixes, edit it via edit_message. If personalization is weak, use search_knowledge_base to find better hooks.
+If a message needs fixes, edit it via manage_messages with action=edit. If personalization is weak, use search with type=kb to find better hooks.
 
 Return a structured summary per message:
 MESSAGE: {id} | PERSON: {name} | MATCH_SCORE: {n} | CATEGORY: T{n} | RECOMMENDATION: {approve|edited|flag|reject} | CONFIDENCE: {high|medium|low} | REASONING: {1-2 sentences} | EDITED: {yes/no} | ISSUES_FOUND: {list or "none"}
@@ -115,10 +115,10 @@ Message type: T{sequence_number} follow-up
 
 Steps:
 1. Call get_outreach_review with message_ids="{message_id}" and content_length="full" to get the current message, thread context, segment instructions, and match analysis.
-2. Call get_person_research and get_person_360 for this person to get everything we know.
-3. Call get_company_research to understand the company's product, positioning, and what problems it solves.
+2. Call fetch with type=person_research plus get_person_360 for this person to get everything we know.
+3. Call fetch with type=company_research to understand the company's product, positioning, and what problems it solves.
 4. Search the web for this prospect and their company to understand what they actually do, what challenges they face, what they post about.
-5. Call search_knowledge_base for any relevant intel.
+5. Call search with type=kb for any relevant intel.
 
 Review the message against what you learned:
 - Does the message accurately reflect what this prospect's company does?
@@ -126,7 +126,7 @@ Review the message against what you learned:
 - Is the personalization based on real, verified information?
 - Are there AI tells, cross-touch duplication, or structural issues?
 
-If the message is good as-is, approve it. If there is clear opportunity to improve (weak personalization when rich signals exist, fabricated references, wrong framing), edit it via edit_message. Do NOT rewrite messages that are already solid just because you can.
+If the message is good as-is, approve it. If there is clear opportunity to improve (weak personalization when rich signals exist, fabricated references, wrong framing), edit it via manage_messages with action=edit. Do NOT rewrite messages that are already solid just because you can.
 
 Return a structured summary:
 MESSAGE: {id} | PERSON: {name} | MATCH_SCORE: {n} | CATEGORY: T{n} | RECOMMENDATION: {approve|edited|flag|reject} | CONFIDENCE: {high|medium|low} | REASONING: {1-2 sentences} | EDITED: {yes/no} | ISSUES_FOUND: {list or "none"} | RESEARCH_SUMMARY: {2-3 sentences on what you found} | PROBLEM_IDENTIFIED: {yes/no/speculative} | REWRITE_REASON: {why you edited, or "n/a"}
@@ -175,7 +175,7 @@ After outreach messages are processed, ask if the user wants to review the engag
 
 - **Small queue (5 or fewer total):** skip subagent dispatch, pull `get_outreach_review` directly and review inline.
 - **Small queue of follow-ups (5 or fewer T2+) with many T1s:** still use subagents for T1 structural review, review follow-ups inline.
-- **User wants to review a specific person:** pull that person's conversation with `get_conversation` and review directly. No batch workflow.
+- **User wants to review a specific person:** pull that person's conversation with `fetch` (type=conversation) and review directly. No batch workflow.
 - **Subagent can't reach MCP tools:** fall back to inline review.
-- **Homogeneous T1 pattern:** if the first T1 batch all had the identical issue, fix the remaining in bulk with `bulk_manage_messages`. Confirm first.
+- **Homogeneous T1 pattern:** if the first T1 batch all had the identical issue, fix the remaining in bulk with a single `manage_messages` call passing an id array (same action applied to every id, max 50 per call). Confirm first.
 

package/skills/outreach-triage/references/subagent-instructions.md

@@ -74,11 +74,11 @@ If personalization is surface level or basic, and you have the tools to go deepe
 
 If a message needs better personalization or you need to verify something, you have access to:
 
-- **Knowledge base** (`search_knowledge_base`): Search the company's uploaded sales docs — positioning, case studies, battlecards, objection handling, process docs. Browse without filters first to see what's available, then narrow with `doc_type` or `query`. Use `document_id` or `include_content: true` to read full content. This is your FIRST stop for company-specific messaging guidance, proof points, and competitive positioning.
+- **Knowledge base** (`search` with type=kb): Search the company's uploaded sales docs — positioning, case studies, battlecards, objection handling, process docs. Browse with no extra filters first to see what's available, then narrow with the `doc_type` or `query` filters. Use the `document_id` or `include_content: true` filters to read full content. This is your FIRST stop for company-specific messaging guidance, proof points, and competitive positioning.
 - **Web search**: Search for recent news about the prospect's company, their recent activity, industry trends relevant to them
-- **LinkedIn data** (`fetch_linkedin_data`): Pull the prospect's recent posts if not already in the review data
+- **LinkedIn data** (`research` with action=linkedin_fetch): Pull the prospect's recent posts if not already in the review data
 - **Obsidian vault** (Read/Grep on `/sessions/amazing-lucid-shannon/mnt/Jon's Neural Net/`): Search for notes on this vertical, company, or prospect. The vault contains pricing frameworks, competitive intel, and vertical playbooks.
-- **Company research** (`get_company_research`, `fetch_company_website`): Get deeper company context if the match analysis feels thin
+- **Company research** (`fetch` with type=company_research; `research` with action=enrich_company): Get deeper company context if the match analysis feels thin
 
 Use these tools when:
 - The draft's personalization is surface-level and you can find something better
@@ -91,7 +91,7 @@ Do NOT use these tools for every message. Only when the draft needs improvement
 
 ## Step 4: Edit if needed
 
-If the message needs changes, rewrite it and apply the edit using `edit_message` with the message_id and new content.
+If the message needs changes, rewrite it and apply the edit using `manage_messages` with action=edit, the message id, and the new content in the payload.
 
 When rewriting:
 - Keep the same strategic intent (don't change a T2 into a T4)
@@ -156,7 +156,7 @@ RESEARCH_DONE: {list of extra research you did, or "none"}
 
 **EDITED** when:
 - Message had fixable issues (AI tells, weak personalization, minor repetition, wrong CTA format)
-- You've applied the fix via edit_message
+- You've applied the fix via manage_messages (action=edit)
 - The rewritten version passes all checks
 
 **FLAG** when:

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

@@ -30,14 +30,14 @@ All harness source skills produce candidate lists matching this shape exactly. T
 
 **Rules:**
 - At minimum, each candidate needs **either** `linkedin_url` **or** (`name`-fields + `company`). Candidates with neither are skipped at Step 3.
-- `full_name` is a convenience for sources that don't pre-split. Engine's Step 7 splits via last-space heuristic (`Jane van der Merwe` → first=`Jane`, last=`van der Merwe`). Multi-token surnames like `Maria Del Carmen Garcia` may split imperfectly — Phase B's `fetch_linkedin_data` returns canonical first/last when `linkedin_url` is present and overrides the heuristic.
+- `full_name` is a convenience for sources that don't pre-split. Engine's Step 7 splits via last-space heuristic (`Jane van der Merwe` → first=`Jane`, last=`van der Merwe`). Multi-token surnames like `Maria Del Carmen Garcia` may split imperfectly — Phase B's linkedin_fetch call (`research` action=linkedin_fetch) returns canonical first/last when `linkedin_url` is present and overrides the heuristic.
 - Field additions are additive only. Removing a field is a breaking change for source skills.
 
 ---
 
 ## MCP-availability precheck (load-bearing — runs before Step 3)
 
-Before any other Step 3 work, call `get_research_playbook(segment_id=<id>)`. If this fails with "tool not found" / 404 / connection error, abort the run with this exact message:
+Before any other Step 3 work, call `fetch(type="research_playbook", id=<segment_id>)`. If this fails with "tool not found" / 404 / connection error, abort the run with this exact message:
 
 > Vruum MCP not configured as a user-scoped server. Run:
 >
@@ -47,7 +47,7 @@ Before any other Step 3 work, call `get_research_playbook(segment_id=<id>)`. If
 
 This catches the common silent-failure mode: deep-research subagents dispatch, all return `STATUS: failed` because they can't reach MCP, and the operator gets a confusing "0 enrolled, no errors" report. One MCP call upfront vs an hour of debugging.
 
-The `get_research_playbook` call also doubles as the ICP load — capture target_titles, target_industries, value_proposition, positioning_angle, ACV floor, signals_to_watch, exclusions for use in subagent dispatch prompts.
+The research_playbook fetch also doubles as the ICP load — capture target_titles, target_industries, value_proposition, positioning_angle, ACV floor, signals_to_watch, exclusions for use in subagent dispatch prompts.
 
 ---
 
@@ -56,8 +56,8 @@ The `get_research_playbook` call also doubles as the ICP load — capture target
 Per segment's candidate list:
 
 1. **MCP precheck + ICP load** (above) — abort run on failure.
-2. **Batch dedup against existing pipeline.** Call `batch_search_existing_people(queries=[{name, company, linkedin_url} for each candidate])`. Returns one match record per candidate (in input order). Drop candidates with non-null `match` — they're already in pipeline.
-3. **Batch company-cache check.** Collect unique company domains from surviving candidates. Call `batch_get_company_research(domains=[...])`. Returns `[{domain, cached_research, age_days}]`.
+2. **Batch dedup against existing pipeline.** Call `search(type="people", query=[{name, company, linkedin_url} for each candidate])`. Returns one match record per candidate (in input order). Drop candidates with non-null `match` — they're already in pipeline.
+3. **Batch company-cache check.** Collect unique company domains from surviving candidates. Call `fetch(type="company_research", id=[the domains])`. Returns `[{domain, cached_research, age_days}]`.
    - Cache hit (`cached_research != null` AND `age_days <= 90`) → company skips Phase A; the cached research carries forward.
    - Cache miss or stale (`age_days > 90`) → company joins the Phase A research queue.
 4. **Operator confirmation gate (CSV / large lists only).** If the original candidate list was >200 (CSV) or >100 (manual list), confirm count to process before continuing.
@@ -68,7 +68,7 @@ Per segment's candidate list:
 
 ## Step 4 — Phase A: company research
 
-**Concurrency cap: 10 parallel.** Phase A subagents don't call `fetch_linkedin_data` — they hit `get_company_research`, `fetch_company_website`, `WebFetch`, `WebSearch`. No Unipile rate-limit pressure.
+**Concurrency cap: 10 parallel.** Phase A subagents don't call `research` with action=linkedin_fetch — they hit `fetch` (type=company_research), `research` (action=enrich_company), `WebFetch`, `WebSearch`. No Unipile rate-limit pressure.
 
 Dispatch one `vruum-company-deep-researcher` per unique uncached company. Subagent file at `.claude/agents/vruum-company-deep-researcher.md` defines the workflow + tools.
 
@@ -79,7 +79,7 @@ You are vruum-company-deep-researcher. Research this company against segment "{s
 
 company_name: {name}
 domain: {domain}
-segment_icp_summary: {one paragraph from get_research_playbook}
+segment_icp_summary: {one paragraph from the research_playbook fetch}
 acv_floor: {dollars or default $10K}
 
 Run your workflow (a–i) and return the structured output block.
@@ -89,7 +89,7 @@ Each subagent returns: `company_id`, `funding_data`, `growth_metrics`, `current_
 
 **Wait for the wave to complete before Phase B.** Phase B inputs depend on Phase A's signals (or null if failed).
 
-**Subagent timeout cascade (load-bearing):** when STATUS=failed for a company, the orchestrator does NOT skip the prospects from that company. Phase B still runs for them with `null` company signals. The harness pre-filter gate then tags them `harness_gate_status: gate_inconclusive` (a fourth status alongside pass/warming/low_priority/dismiss). `save_discovered_person` is still called — the backend's `MatchAnalysisAgent` may have cached company research from earlier runs and gates them appropriately. Surface gate-inconclusive prospects in the final report so the operator can re-run the failed companies later.
+**Subagent timeout cascade (load-bearing):** when STATUS=failed for a company, the orchestrator does NOT skip the prospects from that company. Phase B still runs for them with `null` company signals. The harness pre-filter gate then tags them `harness_gate_status: gate_inconclusive` (a fourth status alongside pass/warming/low_priority/dismiss). `manage_person` action=save_discovered is still called — the backend's `MatchAnalysisAgent` may have cached company research from earlier runs and gates them appropriately. Surface gate-inconclusive prospects in the final report so the operator can re-run the failed companies later.
 
 **Inter-wave progress line.** After each wave (5–10 subagents):
 ```
@@ -101,7 +101,7 @@ Helps operators distinguish "still working" from "stuck."
 
 ## Step 5 — Phase B: prospect research
 
-**Concurrency cap: 5 parallel** (lowered from Phase A's 10 because Phase B subagents call `fetch_linkedin_data` and the Unipile rate limiter throws over cap — see `backend/app/domains/channels/services/unipile/rate_limiter.py:36`. Lower concurrency keeps us under the per-account window.)
+**Concurrency cap: 5 parallel** (lowered from Phase A's 10 because Phase B subagents call `research` action=linkedin_fetch and the Unipile rate limiter throws over cap — see `backend/app/domains/channels/services/unipile/rate_limiter.py:36`. Lower concurrency keeps us under the per-account window.)
 
 Dispatch one `vruum-prospect-deep-researcher` per surviving candidate. Subagent file at `.claude/agents/vruum-prospect-deep-researcher.md`.
 
@@ -122,10 +122,10 @@ phase_a_signals:
   outbound_motion_score: {0|1|2 or null}
   triggers: [list or null]
 
-segment_icp_summary: {one paragraph from get_research_playbook}
+segment_icp_summary: {one paragraph from the research_playbook fetch}
 acv_floor: {dollars}
 
-Run your workflow (a–k) and return the structured output block. Note: do NOT call save_discovered_person or start_outreach — those are orchestrator-only and not in your tools list.
+Run your workflow (a–k) and return the structured output block. Note: do NOT call manage_person action=save_discovered or manage_outreach action=start — those are orchestrator-only and not in your tools list.
 ```
 
 Each subagent returns: `topics_of_interest`, `recent_posts`, `opening_hooks[]` (2–3, with source URLs), `decision_maker_level` (junior/mid/senior), `email_status` (found/pending), `role_start_date`, per-prospect `triggers[]`, `STATUS`. Note: `person_id` is NOT returned here — identity resolution happens in Step 7.
@@ -139,17 +139,17 @@ Each subagent returns: `topics_of_interest`, `recent_posts`, `opening_hooks[]` (
 
 ## Step 6 — Harness pre-filter gate (orchestrator-side, pre-save)
 
-This is a **coarse pre-filter** — its job is to avoid wasted backend `save_discovered_person` calls on obvious dismisses. The **authoritative** gate is server-side `MatchAnalysisAgent.match_score >= 70` and runs inside `save_discovered_person`. The harness gate cannot override the backend gate; it can only dismiss before reaching it.
+This is a **coarse pre-filter** — its job is to avoid wasted backend save calls (`manage_person` action=save_discovered) on obvious dismisses. The **authoritative** gate is server-side `MatchAnalysisAgent.match_score >= 70` and runs inside that save call. The harness gate cannot override the backend gate; it can only dismiss before reaching it.
 
 Per surviving prospect, evaluate four criteria using the segment's playbook ICP and the Phase A + Phase B signals:
 
 ### 1. ACV class meets segment threshold?
 - `acv_class >= acv_floor_class` → pass this criterion (smb=$5K, mid=$5–50K, ent=$50K+; segment's `acv_floor` from playbook maps to a class)
-- If no → dismiss `acv_too_low`. Don't call `save_discovered_person`.
+- If no → dismiss `acv_too_low`. Don't call `manage_person` action=save_discovered.
 
 ### 2. Outbound motion or hiring signal?
 - `outbound_motion_score > 0` OR explicit hiring trigger present → pass
-- If no → flag `warming_candidate` (still call `save_discovered_person` — operator may want to warm-track them; backend match analysis tells us if the segment fit is real)
+- If no → flag `warming_candidate` (still call `manage_person` action=save_discovered — operator may want to warm-track them; backend match analysis tells us if the segment fit is real)
 
 ### 3. Decision-maker level senior?
 - `decision_maker_level == senior` → pass
@@ -158,7 +158,7 @@ Per surviving prospect, evaluate four criteria using the segment's playbook ICP
 
 ### 4. Trigger event in last 90d?
 - 1+ trigger from Phase A (`funding`, `exec_hire`, `launch`, `m_and_a`, `partnership`) OR Phase B (`new_role`, `topical_post`, `press_mention`, `promotion`) → pass
-- If no → flag `low_priority` (still call `save_discovered_person`)
+- If no → flag `low_priority` (still call `manage_person` action=save_discovered)
 
 ### Tag each prospect:
 - `harness_gate_status: pass` — all four criteria passed
@@ -178,43 +178,46 @@ For non-dismiss outcomes, also set `dismiss_reason` to null and `flag` to the re
 Per surviving prospect:
 
 ### a. Save company research (once per company)
-If the prospect's company isn't already cached and Phase A produced fresh research, call `save_company_research(company_name=..., domain=..., funding_data=..., growth_metrics=..., current_priorities=...)`. Skip if `CACHE_HIT: true` for that company.
+If the prospect's company isn't already cached and Phase A produced fresh research, call `research(action="save_company", payload={company_name, domain, funding_data, growth_metrics, current_priorities})`. Skip if `CACHE_HIT: true` for that company.
 
 ### b. Identity resolution + person research (load-bearing — corrects Codex Finding #6)
 
-`save_person_research` requires `first_name` + `last_name`, NOT `name`. `save_discovered_person` requires `person_id` from a prior save step. So Step 7 is a 2-step backend dance:
+`research` action=save_person requires `first_name` + `last_name` in the payload, NOT `name`. `manage_person` action=save_discovered requires `person_id` from a prior save step. So Step 7 is a 2-step backend dance:
 
 1. **Split full_name** if `first_name`/`last_name` aren't already set:
    - Last-space heuristic: split on the last space. `Jane Smith` → first=`Jane`, last=`Smith`. `Jane van der Merwe` → first=`Jane`, last=`van der Merwe`.
-   - **Override with Phase B canonical names** if `fetch_linkedin_data` returned them. LinkedIn's `first_name`/`last_name` fields are authoritative; the heuristic is a fallback for candidates without `linkedin_url`.
+   - **Override with Phase B canonical names** if the linkedin_fetch research call returned them. LinkedIn's `first_name`/`last_name` fields are authoritative; the heuristic is a fallback for candidates without `linkedin_url`.
 
-2. **Call `save_person_research(...)`.** The backend now requires you to identify the company unambiguously — pick ONE of these two paths:
+2. **Call `research` with action=save_person.** The backend now requires you to identify the company unambiguously — pick ONE of these two paths:
 
-   **Path A (preferred): pass `company_id`.** Run `save_company_research(...)` first, capture the returned `company_id`, then pass it here.
+   **Path A (preferred): pass `company_id`.** Run the save_company call (`research` action=save_company) first, capture the returned `company_id`, then pass it in the payload here.
 
-   **Path B (when Path A isn't done yet): pass `company_name` + at least one anchor.** Required anchors are any of `company_domain`, `company_website`, or `company_linkedin_url`. The data is in the LinkedIn payload you already fetched. The prospect's CURRENT employer is the entry in `work_experience[]` with `end_date: null` — that entry has `company_linkedin_url` (e.g. `https://linkedin.com/company/microsoft`). If you ran `fetch_linkedin_data(include_company=true)`, the separate company response carries `website` and `industry`. Domain can be derived from website (e.g. `microsoft.com` from `https://microsoft.com`) or from the prospect's verified work email.
+   **Path B (when Path A isn't done yet): pass `company_name` + at least one anchor.** Required anchors are any of `company_domain`, `company_website`, or `company_linkedin_url`. The data is in the LinkedIn payload you already fetched. The prospect's CURRENT employer is the entry in `work_experience[]` with `end_date: null` — that entry has `company_linkedin_url` (e.g. `https://linkedin.com/company/microsoft`). If you ran linkedin_fetch with `include_company: true` in the payload, the separate company response carries `website` and `industry`. Domain can be derived from website (e.g. `microsoft.com` from `https://microsoft.com`) or from the prospect's verified work email.
 
    **Anchor-less name-only saves are rejected with HTTP 422.** This was hardened to stop orphan stub creation in the companies table — name-only saves were silently producing duplicate rows for common names like Microsoft.
 
    Example call:
    ```
-   save_person_research(
-     first_name=..., last_name=...,
-     email=..., linkedin_url=...,
-     # ONE of:
-     company_id=<from save_company_research>
-     # OR:
-     company_name=..., company_linkedin_url=...,  # at least one anchor
-     # ...rest of research fields
+   research(
+     action="save_person",
+     payload={
+       first_name=..., last_name=...,
+       email=..., linkedin_url=...,
+       # ONE of:
+       company_id=<from the save_company call>
+       # OR:
+       company_name=..., company_linkedin_url=...,  # at least one anchor
+       # ...rest of research fields
+     }
    )
    ```
 
-   - If the prospect already had `person_id` set on the candidate (e.g. operator pasted a Vruum person UUID), pass it explicitly: `save_person_research(person_id=..., ...)` — backend updates rather than creating a new record.
+   - If the prospect already had `person_id` set on the candidate (e.g. operator pasted a Vruum person UUID), pass it explicitly in the payload: `research(action="save_person", payload={person_id: ..., ...})` — backend updates rather than creating a new record.
    - The response includes the `person_id`. Capture it for step c.
 
 ### c. Save discovered person (the backend authoritative gate runs here)
 
-Call `save_discovered_person(person_id=<from b>, segment_id=...)`. This:
+Call `manage_person(action="save_discovered", payload={person_id: <from b>, segment_id: ...})`. This:
 - Runs server-side `analyze_person_match` + signal eval
 - Returns `match_score` (0–100) and `quality_gate_pass` (bool, true iff `match_score >= 70`)
 - Writes the `company_people` row that puts the prospect into the segment
@@ -225,7 +228,7 @@ Call `save_discovered_person(person_id=<from b>, segment_id=...)`. This:
 
 ### d. Bulk enrollment (only after all prospects saved)
 
-Collect all `person_id`s where `harness_gate_status == pass` AND backend `quality_gate_pass == true` AND `mode == save-and-enroll`. Then call `bulk_start_outreach(person_ids=[...], segment_id=...)` ONCE at the end of Step 7.
+Collect all `person_id`s where `harness_gate_status == pass` AND backend `quality_gate_pass == true` AND `mode == save-and-enroll`. Then call `manage_outreach(action="start", id=[those person_ids], payload={segment_id: ...})` ONCE at the end of Step 7.
 
 - Per-prospect outcomes are returned (enrolled | skipped | failed). Surface per-prospect failures in the report.
 - If `harness_gate_status` is `warming` or `low_priority`, exclude from the bulk enroll list. Operator decides on review.
@@ -285,7 +288,7 @@ For multi-segment runs, group the report by segment and include a totals summary
 - **Manual-list cap** — if >100 lines pasted, orchestrator asks "{N} prospects pasted — process all, or first M? (a/N)".
 - **CSV >200 rows** — same prompt at Step 5 of csv-pipeline-fill.
 - **LinkedIn rate-limit (Unipile 429)** — Phase B subagent dismisses with `linkedin_data_unavailable`; orchestrator surfaces in report; operator reruns later.
-- **Unicode multi-token surnames** — `Maria Del Carmen Garcia`: heuristic splits to first=`Maria Del Carmen`, last=`Garcia` (last space wins). When `linkedin_url` is present, `fetch_linkedin_data` overrides with canonical names. Imperfect for candidates without LinkedIn URL — operator can edit via `update_person_contact` post-import.
+- **Unicode multi-token surnames** — `Maria Del Carmen Garcia`: heuristic splits to first=`Maria Del Carmen`, last=`Garcia` (last space wins). When `linkedin_url` is present, the linkedin_fetch research call overrides with canonical names. Imperfect for candidates without LinkedIn URL — operator can edit via `manage_person` action=update_contact post-import.
 
 ---
 

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.