		{
		"name": "vruum",
		"version": "0.6.48",
		"version": "0.6.49",
		"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.",
		@@ -5,0 +5,0 @@ "author": {

+1

-1

.codex-plugin/plugin.json

		{
		"name": "vruum",
		"version": "0.6.48",
		"version": "0.6.49",
		"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.",
		@@ -5,0 +5,0 @@ "author": {

+2

-2

package.json

		{
		"name": "@vruum/skills",
		"version": "0.6.48",
		"version": "0.6.49",
		"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.",
		@@ -44,3 +44,3 @@ "license": "MIT",
		],
		"contentHash": "531c180127ac433327c9639789d1845b98e18e7515db04dab9c9ee31dfee3be0"
		"contentHash": "08900b7700c6e749f7d02081bf8a319ccac72e36b01c794594b4f07d44b2db84"
		}

+1

-1

skills/pipeline-fill/RESEARCH-ENGINE.md

		@@ -254,3 +254,3 @@ # Pipeline Fill — Research Engine
		### a. Resolve and save the company (once per unique current employer)
		In `save` and `save-and-enroll` modes, reuse a trustworthy candidate `company_id` when one is already known. Otherwise call `research(action="save_company", payload={idempotency_key: <stable run/company save key>, name: <CURRENT COMPANY>, website: <canonical website or domain>, linkedin_url: <canonical LinkedIn company URL>, person_id: <the person's Vruum UUID, when researching an EXISTING person's employer>, company_summary, company_stage, funding_data, growth_metrics, current_priorities: <newline-joined descriptions>, sources_by_field})` once per unique current employer and capture the returned `company_id`. This call is required for identity resolution even when Phase A produced no new fixed research fields; in that case omit those research fields and their evidence, but still send the strongest known company anchor. The API field is `name`, not `company_name`; it accepts `website`, not `domain`; and `current_priorities` is one string. Omit reusable fields that were not revalidated so the atomic patch preserves them. Explicit null deliberately clears a field, so do not send null merely because Phase A did not research it. `sources_by_field` keys must equal exactly the supplied non-null research fields. Preserve the identical idempotency key and payload for unknown-commit replay; every bulk item needs its own key. Reuse the returned `company_id` for every prospect at that employer.
		In `save` and `save-and-enroll` modes, reuse a trustworthy candidate `company_id` when one is already known. Otherwise call `research(action="save_company", payload={idempotency_key: <stable run/company save key>, name: <CURRENT COMPANY>, industry: <required Vruum canonical industry>, website: <canonical website or domain>, linkedin_url: <canonical LinkedIn company URL>, person_id: <the person's Vruum UUID, when researching an EXISTING person's employer>, company_summary, company_stage, funding_data, growth_metrics, current_priorities: <newline-joined descriptions>, sources_by_field})` once per unique current employer and capture the returned `company_id`. This call is required for identity resolution even when Phase A produced no new fixed research fields; canonical industry is still required, while unsourced research fields and their evidence stay omitted. Select `industry` from this exact list: Agriculture; Construction; Consumer Goods; Consumer Services; Education; Energy & Utilities; Financial Services; Government; Healthcare; Hospitality & Travel; Legal Services; Manufacturing; Marketing & Advertising; Media & Entertainment; Nonprofit; Professional Services; Real Estate; Retail & E-commerce; Software & Technology; Staffing & Recruiting; Telecommunications; Transportation & Logistics; Wholesale & Distribution; Other. Never send `Unspecified` or a provider-specific label. The API field is `name`, not `company_name`; it accepts `website`, not `domain`; and `current_priorities` is one string. Omit reusable fields that were not revalidated so the atomic patch preserves them. Explicit null deliberately clears a field, so do not send null merely because Phase A did not research it. `sources_by_field` keys must equal exactly the supplied non-null research fields. Preserve the identical idempotency key and payload for unknown-commit replay; every bulk item needs its own key. Reuse the returned `company_id` for every prospect at that employer.

		@@ -257,0 +257,0 @@ Person linkage check (VRU-767): when the research is about a saved person's employer (triage/authoring-time refresh), ALWAYS pass their UUID as `payload.person_id` and read the response's `person_link`. `matched`/`linked`/`repointed` mean the person's future touches will see this research. `mismatch` means no pin was written because the evidence disagreed — the pin sits on a DIFFERENT company (anchored, or a stub whose name carries more identity than the researched one), or an unpinned person's known positions show no role at the researched company. People can hold multiple positions and researching a secondary employer never switches the primary pin. This research will NOT surface on their touches — verify which company they actually work for before authoring from it. `conflict` is a transient race (the pin changed mid-save): replay the identical payload with the same idempotency key once — `person_id` is exempt from the idempotency hash, so adding it to a replay of an earlier save is also the supported repair path. Never assume a bare `success` means the research reached the person.

@vruum/skills - npm Package Compare versions

Improved metrics