@vruum/skills 0.6.5 → 0.6.7

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.5",
+  "version": "0.6.7",
   "description": "Vruum AI skills + remote MCP server for B2B GTM teams. Slash commands for outreach triage, engagement triage, pipeline filling, prospect enrichment, and reply diagnosis, paired with the full Vruum MCP tool surface over OAuth 2.1.",
   "author": {
     "name": "Vruum AI",

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.5",
+  "version": "0.6.7",
   "description": "Vruum AI skills + remote MCP server for B2B GTM teams. Skills for outreach triage, engagement triage, pipeline filling, prospect enrichment, and reply diagnosis, paired with the full Vruum MCP tool surface over OAuth 2.1.",
   "author": {
     "name": "Vruum AI",

package/README.md

@@ -2,7 +2,7 @@
 
 Vruum AI skills for Claude Code, Codex CLI, and any AI assistant with a skill directory.
 
-Pairs with the Vruum MCP server at [https://api.vruum.ai/mcp](https://api.vruum.ai/mcp). The MCP server exposes the `invoke_skill` tool (alongside `list_skills` / `get_skill` / `publish_skill`) so any connected client can run these skills. Skills themselves are distributed via the Claude Code plugin / marketplace; this npm package installs them into the agent-standard skills directory for harnesses without plugin support (Codex CLI, ChatGPT, Windsurf).
+Pairs with the Vruum MCP server at [https://api.vruum.ai/mcp](https://api.vruum.ai/mcp). The MCP server exposes the `skill` tool (action=invoke to run a skill, action=publish to publish one), with `search` type=skills and `fetch` type=skill for discovery, so any connected client can run these skills. Skills themselves are distributed via the Claude Code plugin / marketplace; this npm package installs them into the agent-standard skills directory for harnesses without plugin support (Codex CLI, ChatGPT, Windsurf).
 
 ## Install
 
@@ -18,7 +18,7 @@ Add to `~/.claude.json`:
 }
 ```
 
-Install the skills via the Claude Code plugin / marketplace (below); the MCP server provides the `invoke_skill` tool. You don't need this npm package for Claude Code.
+Install the skills via the Claude Code plugin / marketplace (below); the MCP server provides the `skill` tool (action=invoke). You don't need this npm package for Claude Code.
 
 ### Codex CLI
 
@@ -45,7 +45,7 @@ npx @vruum/skills install --target /path/to/skills/dir   # any other harness
 
 ### Cursor / VS Code Copilot / Cline
 
-Register the MCP server via your editor's MCP setup (each one has its own UI / config path). Connect to `https://api.vruum.ai/mcp` (HTTP, OAuth via standard MCP flow). The `invoke_skill` tool becomes available — to also install the skill files locally, use this npm package's `install --target` below.
+Register the MCP server via your editor's MCP setup (each one has its own UI / config path). Connect to `https://api.vruum.ai/mcp` (HTTP, OAuth via standard MCP flow). The `skill` tool (action=invoke) becomes available; to also install the skill files locally, use this npm package's `install --target` below.
 
 ### Claude Desktop / Claude.ai (Cowork)
 
@@ -64,6 +64,10 @@ npx @vruum/skills install --target /path/to/skills/dir
 ## Skills
 
 <!-- generated:skills-begin -->
+- `/campaign-builder` — Build and launch an outreach campaign from criteria in about five prompts: filter contacts by size, industry, persona, region, or list; preview the cohort; create the campaign (optionally cloning messaging from an existing one); assign people; review and launch. Use when: create a campaign, build a campaign, new campaign from criteria, campaign from my list.
+- `/campaign-doctor` — Diagnose and fix struggling outreach campaigns. Use when: fix a campaign, diagnose campaign, why is my campaign not working, campaign health, low reply rate, check campaigns, which campaigns need help.
+- `/create-content` — Co-produce an on-voice LinkedIn content post — pull your own signal, steer the angle conversationally, draft in your voice, then save as draft, schedule, or publish. Use when: write a post, draft LinkedIn content, create content, post about, content co-production, help me write a post.
+- `/csv-pipeline-fill` — CSV harness source for /pipeline-fill. Reads a CSV, auto-detects headers, maps columns, hands off to /pipeline-fill for harness deep research and import. Use when: import CSV, paste a CSV, csv import, prospect list from CSV, csv harness mode.
 - `/deal-triage` — Triage your active deal pipeline. Flags at-risk deals, surfaces stalled-deal alerts, runs MEDDIC qualification, and recommends next actions. Use when: review deals, triage deals, check pipeline, deal review, morning deals, pipeline review, deal health, at-risk deals.
 - `/diagnose-reply` — Diagnose why a reply happened — what worked or didn't in the outreach that triggered it. Use when: why did they reply, what worked, diagnose reply, reply diagnosis, analyze this reply, what caused this reply, reply analysis.
 - `/engagement-triage` — Review and approve your pending LinkedIn engagement drafts and demand-gen content posts. Use when: triage engagements, review engagement queue, review warming comments, review nurture reactions, review marketing comments, review content drafts, check engagement queue.
@@ -72,12 +76,9 @@ npx @vruum/skills install --target /path/to/skills/dir
 - `/outreach-triage` — Review and approve your pending outreach drafts across LinkedIn and email. Use when: triage, review queue, morning review, check messages, approve outreach, what needs review.
 - `/pipeline-fill` — Source-agnostic pipeline orchestrator. Picks a source per segment (Sales Nav / YC / CSV / discovery), runs harness deep research, applies a pre-filter gate, then saves into the segment via the backend authoritative match_score>=70 gate. Use when: fill pipeline, import prospects, daily imports, need more prospects, discover prospects from scratch, deep research before import.
 - `/sales-nav-deep-fill` — Sales Nav harness source for /pipeline-fill. Pre-filters Sales Nav profiles via vruum-pipeline-filter, produces a candidate list, hands off to /pipeline-fill for deep research and import. Use when: sales nav with deep research, sales nav harness mode, in-chat sales nav.
-- `/yc-pipeline-fill` — YC harness source for /pipeline-fill. Scrapes YC's public Algolia index, extracts founder LinkedIn URLs, dedups, hands a candidate list to /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.
-- `/csv-pipeline-fill` — CSV harness source for /pipeline-fill. Reads a CSV, auto-detects headers, maps columns, hands off to /pipeline-fill for harness deep research and import. Use when: import CSV, paste a CSV, csv import, prospect list from CSV, csv harness mode.
-- `/create-content` — Co-produce an on-voice LinkedIn content post — pull your own signal, steer the angle conversationally, draft in your voice, then save as draft, schedule, or publish. Use when: write a post, draft LinkedIn content, create content, post about, content co-production, help me write a post.
-- `/campaign-doctor` — Diagnose and fix struggling outreach campaigns. Use when: fix a campaign, diagnose campaign, why is my campaign not working, campaign health, low reply rate, check campaigns, which campaigns need help.
 - `/vruum-skills-upgrade` — Upgrade @vruum/skills to the latest npm version and re-sync ~/.vruum/. Use when: upgrade vruum skills, update vruum, pull latest vruum skills, or when the preamble reports UPGRADE_AVAILABLE.
 - `/winback-fill` — Source winback candidates from closed-lost deals or churned customers. Surfaces people who went silent or lost a deal >90 days ago, where the loss reason wasn't 'no_fit'. Use when: winback, win back churned, reactivate, revive cold deals, 90-day silent revival, lost deal recovery, lost customer outreach.
+- `/yc-pipeline-fill` — YC harness source for /pipeline-fill. Scrapes YC's public Algolia index, extracts founder LinkedIn URLs, dedups, hands a candidate list to /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.
 <!-- generated:skills-end -->
 
 ## Upgrade

package/agents/vruum-deal-reviewer.md

@@ -4,14 +4,11 @@ description: Read-only deal reviewer. Analyzes a single deal — risk, qualifica
 mcpServers:
   - vruum
 tools:
-  - mcp__vruum__get_deal
-  - mcp__vruum__get_deals
+  - mcp__vruum__fetch
+  - mcp__vruum__search
   - mcp__vruum__get_deal_360
-  - mcp__vruum__get_deal_alerts
   - mcp__vruum__inspect_pipeline
   - mcp__vruum__get_person_360
-  - mcp__vruum__get_company_research
-  - mcp__vruum__get_account_state
   - WebSearch
   - WebFetch
 ---
@@ -26,13 +23,13 @@ You are **read-only by tool surface** — your tool list contains no write tools
 
 For each deal you're assigned:
 
-1. **Get full deal context**: Call `get_deal_360` with the `deal_id`. This returns deal info, stakeholders (read-only view), MEDDIC qualification state (whatever's already on the deal), and recent activity timeline — all in one call. If that endpoint isn't in your tool list, fall back to `get_deal` (which carries `qualification` / `qualification_score` if previously computed; stakeholder count is in the deal row).
+1. **Get full deal context**: Call `get_deal_360` with the `deal_id`. This returns deal info, stakeholders (read-only view), MEDDIC qualification state (whatever's already on the deal), and recent activity timeline — all in one call. If that endpoint isn't in your tool list, fall back to `fetch` with type=deal (which carries `qualification` / `qualification_score` if previously computed; stakeholder count is in the deal row).
 
-2. **Read qualification state — do NOT run qualification.** Inspect `qualification` / `qualification_score` from `get_deal_360`'s response. If `qualification` is null OR `qualification_score < 40` OR the last qualification is older than 30 days, surface this as a `re_qualify` recommendation in your output. Do NOT call `qualify_deal` — it writes a fresh MEDDIC JSONB on the deal and burns LLM tokens. The orchestrator runs it only after the seller approves.
+2. **Read qualification state — do NOT run qualification.** Inspect `qualification` / `qualification_score` from `get_deal_360`'s response. If `qualification` is null OR `qualification_score < 40` OR the last qualification is older than 30 days, surface this as a `re_qualify` recommendation in your output. Do NOT run qualification yourself (`manage_deal` action=qualify) — it writes a fresh MEDDIC JSONB on the deal and burns LLM tokens. The orchestrator runs it only after the seller approves.
 
 3. **Research primary stakeholder**: Call `get_person_360` for the primary champion (or first stakeholder). Note match score, research highlights, and recent activity.
 
-4. **Read account state**: Call `get_account_state` for the deal's account stage + health (lifecycle: prospect → engaged → committed → onboarded → adopting → expansion_ready → dormant → churned). If 404 (no row yet), default to `prospect` / null health.
+4. **Read account state**: Call `fetch` with type=account_state for the deal's account stage + health (lifecycle: prospect → engaged → committed → onboarded → adopting → expansion_ready → dormant → churned). If 404 (no row yet), default to `prospect` / null health.
 
 5. **Optional external context**: Use `WebSearch` / `WebFetch` for recent company news that might affect the deal (funding, layoffs, acquisitions). Only when it materially affects the recommendation — don't routinely web-search every deal.
 

package/agents/vruum-engagement-reviewer.md

@@ -5,9 +5,9 @@ mcpServers:
   - vruum
 tools:
   - mcp__vruum__get_engagement_review
-  - mcp__vruum__manage_engagement
+  - mcp__vruum__manage_engagements
   - mcp__vruum__get_content_review
-  - mcp__vruum__manage_content_post
+  - mcp__vruum__manage_content
   - mcp__vruum__get_person_360
   - WebSearch
   - WebFetch
@@ -20,7 +20,7 @@ You are an engagement uplift + review agent with access to 5 Vruum MCP tools. Yo
 
 The orchestrator will tell you which type and provide IDs.
 
-If your dispatch prompt includes an instruction block about scoping MCP calls to a specific company, follow those instructions exactly. Before any `manage_engagement` write, verify the returned item's `user_company_id` matches the scope the orchestrator gave you (if any).
+If your dispatch prompt includes an instruction block about scoping MCP calls to a specific company, follow those instructions exactly. Before any `manage_engagements` write, verify the returned item's `user_company_id` matches the scope the orchestrator gave you (if any).
 
 ---
 
@@ -54,7 +54,7 @@ Skip commenting and recommend a reaction when:
 - Commenting would require the sender to pretend they have expertise they don't have
 - The post is personal/religious/emotional and a comment from a stranger feels performative
 
-Use `manage_engagement` with action="edit" to change the engagement_type to a reaction, or recommend SKIP_TO_REACTION in your summary so the orchestrator can convert it.
+Use `manage_engagements` with action="edit" to change the engagement_type to a reaction, or recommend SKIP_TO_REACTION in your summary so the orchestrator can convert it.
 
 A real person likes 20 posts for every 1 they comment on. The bar for commenting should be HIGH.
 
@@ -105,20 +105,22 @@ Flag if the reaction type seems wrong for the post context.
 ### 2h. Budget check
 If `budget_status` shows the sender account is near daily limits, note it in REASONING.
 
-## Step 3: Apply the uplift via manage_engagement
+## Step 3: Apply the uplift via manage_engagements
 
-When you decide to UPLIFT, write back via `manage_engagement` with **action="edit"** AND **polish_provenance** so the two-stage edit diff is captured:
+When you decide to UPLIFT, write back via `manage_engagements` with **action="edit"** AND **polish_provenance** in the payload so the two-stage edit diff is captured:
 
 ```
-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>"
+    }
   }
 )
 ```
@@ -198,7 +200,7 @@ If the post makes specific claims (statistics, market sizes), flag as "unverifie
 
 ## Step 3: Edit if needed
 
-For structural issues (no line breaks, weak hook), use `manage_content_post` with action="edit". For brand voice and factual issues, FLAG rather than edit.
+For structural issues (no line breaks, weak hook), use `manage_content` with action="edit". For brand voice and factual issues, FLAG rather than edit.
 
 ## Step 4: Return structured summary
 

package/agents/vruum-outreach-reviewer.md

@@ -5,18 +5,16 @@ mcpServers:
   - vruum
 tools:
   - mcp__vruum__get_outreach_review
-  - mcp__vruum__edit_message
-  - mcp__vruum__search_knowledge_base
-  - mcp__vruum__get_person_research
+  - mcp__vruum__manage_messages
+  - mcp__vruum__search
+  - mcp__vruum__fetch
   - mcp__vruum__get_person_360
-  - mcp__vruum__get_company_research
-  - mcp__vruum__fetch_company_website
-  - mcp__vruum__fetch_linkedin_data
+  - mcp__vruum__research
   - WebSearch
   - WebFetch
 ---
 
-You are an outreach review agent with access to 8 Vruum MCP tools for message review. Your job is to review, improve, and prepare outreach messages for operator approval.
+You are an outreach review agent with access to 6 Vruum MCP tools for message review. Your job is to review, improve, and prepare outreach messages for operator approval.
 
 You do NOT approve or send messages. You review, edit if needed, and return a structured summary.
 
@@ -90,10 +88,10 @@ 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. Browse without filters first to see what's available, then narrow with `doc_type` or `query`.
+- **Knowledge base** (`search` with `type="kb"`): Search the company's uploaded sales docs. Browse without filters first to see what's available, then narrow with `doc_type` or `query`.
 - **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
-- **Company research** (`get_company_research`, `fetch_company_website`): Get deeper company context if the match analysis feels thin
+- **LinkedIn data** (`research` with `action="linkedin_fetch"`): Pull the prospect's recent posts if not already in the review data
+- **Company research** (`fetch` with `type="company_research"`, or `research` with `action="enrich_company"` for a fresh website pull): 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
@@ -103,7 +101,7 @@ Use these tools when:
 
 ### MANDATORY web search for follow-ups (T2+)
 
-For ANY follow-up message (sequence_number >= 2), web search is REQUIRED before making a decision. Cached `get_person_research` and `get_company_research` payloads are often weeks or months old and miss recent signals (acquisitions, role changes, new posts, new reqs, funding, layoffs). You MUST run at least one WebSearch query on the prospect + company before approving or editing a T2+ message.
+For ANY follow-up message (sequence_number >= 2), web search is REQUIRED before making a decision. Cached person/company research payloads (`fetch` type=person_research / type=company_research) are often weeks or months old and miss recent signals (acquisitions, role changes, new posts, new reqs, funding, layoffs). You MUST run at least one WebSearch query on the prospect + company before approving or editing a T2+ message.
 
 What to search for:
 - "{Person Name} {Company}" — surfaces recent LinkedIn posts, interviews, podcast appearances
@@ -118,7 +116,7 @@ For T1 structural reviews and other cases, the existing "use when needed" rule a
 
 ## 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 payload={subject?, content}.
 
 When rewriting:
 - Keep the same strategic intent (don't change a T2 into a T4)
@@ -176,6 +174,6 @@ RESEARCH_DONE: {list of extra research you did, or "none"}
 ## Decision Framework
 
 **APPROVE**: passes all checks, personalization at least basic, reads like a human wrote it
-**EDITED**: had fixable issues, you've applied the fix via edit_message, rewritten version passes
+**EDITED**: had fixable issues, you've applied the fix via manage_messages action=edit, rewritten version passes
 **FLAG**: reply_response to complex conversation, high-value prospect (90+), needs operator judgment
 **REJECT**: fundamentally violates touch sequence, severe repetition, fabricated personalization

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vruum/skills",
-  "version": "0.6.5",
+  "version": "0.6.7",
   "description": "Vruum AI skills for Claude Code, Claude Desktop, Codex CLI, and any AI assistant with a skill directory. Slash commands for outreach triage, engagement triage, pipeline filling, prospect enrichment, and reply diagnosis. Pairs with the Vruum MCP server at https://api.vruum.ai/mcp.",
   "license": "MIT",
   "repository": {
@@ -42,5 +42,5 @@
     "outreach",
     "gtm"
   ],
-  "contentHash": "e63027e852c80ac642ff78aa10fc43c4efe9ec020ee4feeaa6270d4ba76fbe40"
+  "contentHash": "36f9f0e247644f718520e35d1b1b9100d3a3b2300949f6e98adf6d20ffe71b80"
 }

package/skills/campaign-builder/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: campaign-builder
+description: >-
+  Build and launch an outreach campaign from criteria in about five prompts:
+  filter contacts by size, industry, persona, region, or list; preview the
+  cohort; create the campaign (optionally cloning messaging from an existing
+  one); assign people; review and launch. Use when: create a campaign, build a
+  campaign, new campaign from criteria, campaign from my list.
+---
+# Campaign Builder
+
+You guide the seller from "I want to reach this kind of person" to a launched campaign in about five exchanges. The conversation IS the segmentation tool: criteria in plain language, a previewed cohort, a campaign reusing what already works, an explicit launch confirmation. Never launch anything without the confirmation step.
+
+## Step 1: Capture the criteria
+
+Ask what cohort they want to reach if they haven't said. Criteria can combine:
+
+- **List**: a named list (e.g. mirrored from a CRM export) — `filters={list: "<name or id>"}`
+- **Custom attributes** from their import (e.g. sorted company size / industry / region) — `filters={custom: {"sorted_company_size": "small", "sorted_industry": "staffing & recruiting"}}`
+- **Persona** (buying role): influencer | decision_maker | economic_buyer — `filters={persona: "economic_buyer"}`
+- Standard filters: stage, score range, enrollment, relationship type
+
+If they reference attributes you haven't seen, call `search` with `type="people"` and `limit=1` first and inspect a row's `custom_fields` keys so you offer real attribute names, not guesses.
+
+If personas matter to their criteria and contacts are unclassified (`filters={persona: "unclassified"}` returns many), offer to run `research` with action=classify_personas first (payload `{}` classifies every unclassified contact; large runs return a job id — poll with `fetch` type=job until completed, then continue).
+
+## Step 2: Preview the cohort
+
+Call `search` with `type="people"` and the criteria (include `filters={research_status: "all"}` so stub imports are visible). Show:
+- The total count
+- A 5-row sample: name, title, company, persona, the custom attributes that matched
+
+Iterate with the seller until the cohort is right ("too broad — only the US ones" → add the region attribute). This is the step to get right; everything after is mechanical.
+
+## Step 3: Create the campaign
+
+Two paths — ask which:
+
+- **Reuse messaging that works** (default when they name an existing campaign): `manage_campaign` action=clone id=<existing campaign uuid> payload={name: "<new name>"}. Cloning carries the messaging structure, tone, and CTA configuration. Find the source campaign with `search` type="campaigns" if you only have its name.
+- **Fresh**: `manage_campaign` action=create payload={name, ...} — then offer to set tone/cadence via action=update once created.
+
+## Step 4: Assign the cohort
+
+Collect the person ids from the Step 2 preview (re-run the same `search` with a higher `limit` to get the full cohort if needed — paginate with `offset` for big cohorts) and call `manage_campaign` action=members id=<campaign uuid> payload={action: "add", person_ids: [...]}.
+
+For large cohorts, add in batches of a few hundred and report progress.
+
+## Step 5: Review and launch — CONFIRMATION REQUIRED
+
+Show the seller a launch summary before anything sends:
+- Campaign name, source of messaging (cloned from X / fresh)
+- Cohort size and criteria
+- Channels and cadence (from the campaign config)
+
+Then ask explicitly: "Launch outreach to these N people?" Only after a clear yes, call `manage_outreach` action=start id=[person uuids] (native bulk; payload optional {max_touches, allowed_channels, start_immediately}).
+
+If the seller wants a dry run, stop after Step 4 — the campaign exists with members and nothing sends until plans start.
+
+## Notes
+
+- Junk-safe personalization: contacts with garbage first names (single letters, org names) automatically get the no-name greeting variant — you don't need to filter them out of the cohort for that reason.
+- A person can be in many lists but holds ONE campaign assignment; adding to a campaign moves them. Say so if the cohort overlaps an active campaign — surface counts before Step 4.
+- Never call `manage_outreach` action=start without the Step 5 confirmation, and never auto-approve drafts; the outreach queue review (`/outreach-triage`) stays the quality gate.

package/skills/campaign-doctor/SKILL.md

@@ -13,21 +13,21 @@ You are a campaign diagnostics and optimization agent. Your job is to identify s
 
 ### Step 1: Triage — health + trends
 
-Call `get_campaigns` to list all campaigns. For each campaign, dispatch three calls in parallel:
-- `diagnose_campaign(campaign_id=X)` — returns `health_score` (0–100), reply-rate vs company average, and ranked root causes (targeting, messaging, channel, saturation, cadence, timing).
+Call `search` with type=campaigns to list all campaigns. For each campaign, dispatch three calls in parallel:
+- `manage_campaign` with action=diagnose and id=<campaign uuid> — returns `health_score` (0–100), reply-rate vs company average, and ranked root causes (targeting, messaging, channel, saturation, cadence, timing).
 - `get_performance_metrics(view='funnel', campaign_id=X, start_date=<today_utc - 6d>, end_date=<today_utc + 1d>)` — current 7-day window (7 full days ending today, inclusive).
 - `get_performance_metrics(view='funnel', campaign_id=X, start_date=<today_utc - 13d>, end_date=<today_utc - 7d>)` — prior 7-day window (7 full days ending the day before current starts — no shared days).
 
 Use **UTC** dates in `YYYY-MM-DD` format. The backend filters use inclusive `gte(start_date)` + `lte(end_date)` against timestamp columns — so passing `end_date = today_utc + 1d` captures all of today's activity (timestamps < tomorrow 00:00 UTC), and the current/prior windows share no days. Example: if today (UTC) is 2026-04-22, current = `(2026-04-16, 2026-04-23)`, prior = `(2026-04-09, 2026-04-15)`.
 
-If `get_campaigns` returns no campaigns, tell the user "No campaigns yet — create one in the Vruum app before running diagnosis" and stop.
+If the campaign `search` returns no campaigns, tell the user "No campaigns yet — create one in the Vruum app before running diagnosis" and stop.
 
-Classify each campaign by reply rate (from `diagnose_campaign` output). Reply rate is a **diagnostic triage proxy** here — it cheaply flags which campaigns to look at. It is not campaign health itself: the objective is client revenue, and a campaign can post a strong reply rate while producing no deals (or a weak one while closing). Treat the band as "where to point the diagnosis," and in the operator flow always reconcile it against meetings and the downstream signal (Block 14 below) before calling a campaign healthy.
+Classify each campaign by reply rate (from the diagnose output). Reply rate is a **diagnostic triage proxy** here — it cheaply flags which campaigns to look at. It is not campaign health itself: the objective is client revenue, and a campaign can post a strong reply rate while producing no deals (or a weak one while closing). Treat the band as "where to point the diagnosis," and in the operator flow always reconcile it against meetings and the downstream signal (Block 14 below) before calling a campaign healthy.
 
 - **CRITICAL** — 30-day reply rate < 5% with ≥20 sent
 - **WARNING** — 30-day reply rate 5–10% with ≥20 sent
 - **HEALTHY** — 30-day reply rate ≥ 10% (reply-rate-healthy — confirm it also produces meetings/deals before treating it as truly healthy)
-- **INSUFFICIENT DATA** — `diagnose_campaign` returned `insufficient_data: true` (fewer than 20 sent in 30d)
+- **INSUFFICIENT DATA** — the diagnose call returned `insufficient_data: true` (fewer than 20 sent in 30d)
 
 For WoW delta, compute `(current_reply_rate - prior_reply_rate) / prior_reply_rate`. Guards:
 - **Brand-new campaign** (prior window sent = 0): show "new campaign, WoW N/A".
@@ -57,11 +57,11 @@ Want me to diagnose the critical and warning campaigns?"
 Key behaviors:
 - Never auto-diagnose `insufficient_data` campaigns. They need more volume first.
 - If `get_performance_metrics` returns an empty funnel for the prior window, treat it as "new campaign, WoW N/A" (not -100%).
-- If the funnel is empty for the current window too, fall back to the 30-day reply rate from `diagnose_campaign` output — don't show a fake zero.
+- If the funnel is empty for the current window too, fall back to the 30-day reply rate from the diagnose output — don't show a fake zero.
 
 ### Step 2: Diagnose root causes
 
-For each campaign the user wants to diagnose, you already have the `diagnose_campaign` output from Step 1's parallel calls. Present the findings:
+For each campaign the user wants to diagnose, you already have the diagnose output from Step 1's parallel calls. Present the findings:
 
 "**'IT Directors'** — Health score: 25/100
 
@@ -81,18 +81,18 @@ Root causes (ranked):
 Want me to apply any of these fixes?"
 
 Key behaviors:
-- If `diagnose_campaign` returned `insufficient_data`, surface the tool's own `message` field verbatim. Don't re-derive the threshold logic.
+- If the diagnose call returned `insufficient_data`, surface the tool's own `message` field verbatim. Don't re-derive the threshold logic.
 - When multiple campaigns share the same root cause dimension (e.g., all have messaging issues), recommend a cross-campaign fix first.
 
 ### Step 3: Apply fixes (with approval)
 
 For each recommended fix the user approves:
 
-- **Targeting fix**: Suggest specific ICP field changes and call `update_campaign` with new `target_titles`, `target_industries`, or `positioning_angle`.
+- **Targeting fix**: Suggest specific ICP field changes and call `manage_campaign` with action=update, the campaign id, and a payload of new `target_titles`, `target_industries`, or `positioning_angle`.
 
-- **Messaging fix**: Suggest revised `ai_tone_instructions` or `ai_selling_strategy` and call `update_campaign`.
+- **Messaging fix**: Suggest revised `ai_tone_instructions` or `ai_selling_strategy` and apply them via `manage_campaign` action=update.
 
-- **Channel fix**: Call `update_campaign` with adjusted `allowed_channels`.
+- **Channel fix**: Call `manage_campaign` with action=update and a payload of adjusted `allowed_channels`.
 
 - **Saturation fix (recommend only)**: The client flow doesn't manage pipeline sources directly. Instead:
   1. Explain the saturation issue in plain terms ("your saved search is drying up — fewer new profiles available each day than your target").
@@ -114,8 +114,8 @@ Monitor results over the next 7 days. Run /campaign-doctor again next week to ch
 
 ## Notes
 
-- `diagnose_campaign` requires 20+ sent touches in 30 days for meaningful analysis. For newer campaigns, wait — do not attempt diagnosis.
-- Reply-rate thresholds for health bands match `diagnose_campaign.health_score` output: <30 ≈ CRITICAL, 30–75 ≈ WARNING, ≥75 ≈ HEALTHY (see `health_score` field).
+- Campaign diagnosis (`manage_campaign` action=diagnose) requires 20+ sent touches in 30 days for meaningful analysis. For newer campaigns, wait — do not attempt diagnosis.
+- Reply-rate thresholds for health bands match the diagnose output's `health_score`: <30 ≈ CRITICAL, 30–75 ≈ WARNING, ≥75 ≈ HEALTHY (see `health_score` field).
 - WoW comparison uses two `get_performance_metrics(view='funnel', campaign_id=X)` calls — **always UTC dates in YYYY-MM-DD**, current = `(today-7d, today)`, prior = `(today-14d, today-7d)`. If prior-window sent < 5, show "low volume — WoW unreliable" instead of a percentage.
 - Root causes are ranked by severity. Focus on the highest-severity issues first.
 - Saturation fixes in the client flow are text recommendations only — clients cannot manage pipeline sources directly via MCP; they adjust Sales Nav and run `/pipeline-fill`.

package/skills/create-content/SKILL.md

@@ -24,22 +24,22 @@ Keep it light. You're not locking a brief yet — you just need a seed string to
 
 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`.
+Call `fetch` with `type="settings"` and `subtype="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.
+- **`linkedin_accounts` is missing, empty, or the channel-status `fetch` 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`.
+- **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 the 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 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.
+Call `fetch` with `type="seller_signals"`, passing the rough topic as `draft_brief` in `filters`. **If you resolved an author `user_id` in Step 2, pass it as the `id` argument** so the signal is *that person's*, not the caller's. (Omit `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.
+**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 the author param 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.
 
@@ -51,7 +51,7 @@ Call `get_seller_signal_bundle` with the rough topic as the `draft_brief` argume
 
 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:
+If a quick read of what's already on the content calendar would help shape the angle, call `search` with `type="content"` **once** (the default `days` filter 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:
 
 - **Avoid theme clustering** — if a recent or upcoming post already covers this `topic_tags` theme, nudge the angle somewhere fresher rather than posting two near-duplicates close together.
 - **Notice cadence gaps** — if the calendar looks thin lately, that's a soft reason to keep this one moving. This is best-effort only: the tool returns posts by recency (it lists what was created recently, not a precise scheduled-window view), so don't promise exact cadence math or specific dates — read it as a rough sense of "busy" vs "quiet," not a schedule.
@@ -74,37 +74,37 @@ Let the seller refine. Iterate in conversation until the brief is **settled**
 
 ## 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 `manage_content` with `action="draft_post"`, passing the settled brief as `topic` in the payload. **If you resolved an author `user_id` in Step 2, pass the same value as `author_user_id` in the payload** 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.
 
 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.
+The `draft_post` action creates a new draft row every time it runs. Call it **once** per post. Show the seller the returned draft.
 
 ## 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`. 
+When the seller wants changes (tighten the hook, change the CTA, fix a line), revise the **existing** draft with `manage_content` 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.
+Never call `manage_content` with `action="draft_post"` again for a revision — that spawns a duplicate draft row and loses the thread. One post = one draft row, edited in place.
 
-`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.
+`manage_content` 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.**
 
 - **Keep as draft** — do nothing further; the draft already exists and is visible at `/marketing/content`.
-- **Schedule** — call `manage_content_post` with `action="schedule"` and a `scheduled_at` ISO-8601 timestamp. It auto-publishes when due.
+- **Schedule** — call `manage_content` with `action="schedule"` and a `scheduled_at` ISO-8601 timestamp. It auto-publishes when due.
 - **Publish now** — this is destructive and irreversible, and it will fail (marking the draft unusable) if no LinkedIn account is connected. So treat it as a deliberate, confirmed action:
   - Never call publish as a probe or a default.
-  - Only call `manage_content_post` with `action="publish"` **after** the seller has explicitly confirmed "publish now."
+  - Only call `manage_content` 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:
+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 the channel-status `fetch` (type=settings, subtype=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).
+- If their account is **missing, not `connected`, shows a bad `status`, or has an exhausted `quota` in the fresh response** (or the fresh channel-status `fetch` 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.
 

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

@@ -10,7 +10,7 @@ description: >-
 
 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.
 
-**This is the harness counterpart to `/csv-platform-fill`.** The platform skill calls `start_csv_import` and lets backend agents do everything. 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.
+**This is the harness counterpart to `/csv-platform-fill`.** The platform skill calls `import_prospects` with action=csv_start and lets backend agents do everything. 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.
 
 ## Inputs
 
@@ -88,7 +88,7 @@ Convert each row to the canonical shape (defined in `pipeline-fill/RESEARCH-ENGI
 }
 ```
 
-The `csv_extra_columns` field keeps unmapped data on the candidate so an operator can later inspect it via `get_user_people` if a question comes up about why a particular prospect was imported.
+The `csv_extra_columns` field keeps unmapped data on the candidate so an operator can later inspect it via `search` type=people if a question comes up about why a particular prospect was imported.
 
 ### Step 8: Hand off to /pipeline-fill (canonical handoff prompt)
 
@@ -118,5 +118,5 @@ Continue automatically? (y/n)
 ## Notes
 
 - **Sourcing phase is ~free** (file read + parsing). Real-money costs live in `/pipeline-fill`'s deep-research subagents.
-- **For backend-driven CSV import** (fire-and-forget, no in-chat research): the platform-mode CSV skill calls `start_csv_import` directly and lets backend agents do sourcing/research/gate. Pick this skill when you want to see the deep research happen in your chat instead.
+- **For backend-driven CSV import** (fire-and-forget, no in-chat research): the platform-mode CSV skill calls `import_prospects` with action=csv_start directly and lets backend agents do sourcing/research/gate. Pick this skill when you want to see the deep research happen in your chat instead.
 - **Composability** with `/pipeline-fill`: standard pattern. Run this skill standalone for "I just want this CSV imported with deep research today" or invoke via the orchestrator's source picker.

package/skills/deal-triage/SKILL.md

@@ -17,7 +17,7 @@ Deal review requires cross-referencing multiple data sources per deal: stakehold
 ## Subagent architecture
 
 This skill uses the custom agent `vruum-deal-reviewer` (bundled at `agents/vruum-deal-reviewer.md`). That agent has:
-- **Read-only** Vruum MCP access (`get_deal`, `get_deal_360`, `get_deal_alerts`, `inspect_pipeline`, `get_person_360`, `get_company_research`, `get_account_state`). It has NO write tools by design — review is analysis, not mutation. Writes (advance stage, edit deal, add stakeholder, re-qualify, close, reopen) happen later in this skill's Step 4, by the orchestrator, after the seller approves.
+- **Read-only** Vruum MCP access (`fetch` for deal, deal_alerts, company_research, and account_state reads; `search` for deal lists; plus the composites `get_deal_360`, `inspect_pipeline`, `get_person_360`). It has NO write tools (no `manage_deal`) by design — review is analysis, not mutation. Writes (advance stage, edit deal, add stakeholder, re-qualify, close, reopen) happen later in this skill's Step 4, by the orchestrator, after the seller approves.
 - Web search for prospect/company research
 - Complete deal review instructions baked into its system prompt
 
@@ -32,7 +32,7 @@ For small reviews (3 or fewer flagged deals) or when subagents can't access MCP,
 Call two MCP tools to understand the current state:
 
 1. `inspect_pipeline` — returns top at-risk deals with risk scores, risk factors, days in stage
-2. `get_deal_alerts` — returns all active alerts (silence 7+ days, overdue next steps, slippage past close date)
+2. `fetch` with type=deal_alerts — returns all active alerts (silence 7+ days, overdue next steps, slippage past close date)
 
 Combine the results into a prioritized triage list. Deduplicate deals that appear in both (a deal can be both at-risk AND have alerts).
 
@@ -44,7 +44,7 @@ Present a brief overview:
 
 ### Step 2: Dispatch parallel subagents
 
-For each unique flagged deal (from `inspect_pipeline` + `get_deal_alerts`, max 7), spawn a `vruum-deal-reviewer` subagent with `run_in_background=true`.
+For each unique flagged deal (from `inspect_pipeline` + the deal_alerts fetch, max 7), spawn a `vruum-deal-reviewer` subagent with `run_in_background=true`.
 
 Each subagent prompt should include:
 - The `deal_id`
@@ -53,10 +53,10 @@ Each subagent prompt should include:
 - Instructions to follow the subagent workflow below
 
 **Subagent workflow** (each subagent runs read-only and independently — its tool surface excludes deal writes by design; mutation happens later in Step 4 with the seller's approval):
-1. Call `get_deal_360` for the full deal context in one call (deal info, stakeholders, MEDDIC qualification state, recent activity timeline). If the consolidated endpoint isn't available in your tool list, fall back to `get_deal` — the deal row carries `qualification` and `qualification_score` when previously computed.
-2. **Read** `qualification` / `qualification_score` from the response — do NOT call `qualify_deal` from the reviewer. `qualify_deal` writes a fresh MEDDIC JSONB (an LLM call + a DB write); the reviewer is read-only. If `qualification` is null, the score is < 40, or the last qualification is older than 30 days, the reviewer emits a `re_qualify` recommendation and the orchestrator (this skill) runs `qualify_deal` ONLY after the seller approves in Step 4.
+1. Call `get_deal_360` for the full deal context in one call (deal info, stakeholders, MEDDIC qualification state, recent activity timeline). If the consolidated endpoint isn't available in your tool list, fall back to `fetch` with type=deal — the deal row carries `qualification` and `qualification_score` when previously computed.
+2. **Read** `qualification` / `qualification_score` from the response — do NOT qualify from the reviewer. `manage_deal` with action=qualify writes a fresh MEDDIC JSONB (an LLM call + a DB write); the reviewer is read-only. If `qualification` is null, the score is < 40, or the last qualification is older than 30 days, the reviewer emits a `re_qualify` recommendation and the orchestrator (this skill) runs `manage_deal` action=qualify ONLY after the seller approves in Step 4.
 3. Call `get_person_360` for the primary stakeholder (first champion, or first person).
-4. Call `get_account_state` for the deal's account stage + health. If 404 (no row yet), default to `prospect` / null health.
+4. Call `fetch` with type=account_state for the deal's account stage + health. If 404 (no row yet), default to `prospect` / null health.
 5. Return a structured summary in this exact format:
 
 ```
@@ -94,18 +94,18 @@ For each deal, show the structured summary. Highlight critical alerts in bold.
 
 After presenting results, the user can request actions. Execute them using MCP tools:
 
-- **Advance stage** → `update_deal` with new stage
-- **Set next step** → `update_deal` with `next_step` + `next_step_due_at`
-- **Add stakeholder** → `manage_deal_stakeholders` with action='add'
-- **Re-qualify** → `qualify_deal` (runs MEDDIC analysis again)
-- **Close deal** → `record_deal_outcome` with outcome (won/lost/stalled)
-- **Reopen deal** → `reopen_deal` with desired stage
-- **Mark stalled** → `update_deal` with stage='stalled'
+- **Advance stage** → `manage_deal` action=stage with payload={stage}
+- **Set next step** → `manage_deal` action=update with payload={next_step, next_step_due_at}
+- **Add stakeholder** → `manage_deal` action=stakeholders with payload={action: 'add', person_id, role}
+- **Re-qualify** → `manage_deal` action=qualify (runs MEDDIC analysis again)
+- **Close deal** → `manage_deal` action=won or action=lost (payload carries win_factors / loss_reason)
+- **Reopen deal** → `manage_deal` action=reopen with payload={stage}
+- **Mark stalled** → `manage_deal` action=stalled (records the stalled outcome; payload optional)
 
 For batch actions ("advance all deals in proposal"), confirm with the user before executing.
 
 ## Error handling
 
 - If a subagent fails (LLM rate limit, timeout, tool error): present results for successful subagents, note failures
-- If `inspect_pipeline` or `get_deal_alerts` fails: fall back to `get_deals` and manually check `updated_at` for staleness
+- If `inspect_pipeline` or the deal_alerts fetch fails: fall back to `search` with type=deals and manually check `updated_at` for staleness
 - Never block the entire triage on a single failure