@vruum/skills 0.6.60 → 0.6.62

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.60",
+  "version": "0.6.62",
   "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.60",
+  "version": "0.6.62",
   "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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vruum/skills",
-  "version": "0.6.60",
+  "version": "0.6.62",
   "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": {
@@ -41,5 +41,5 @@
     "outreach",
     "gtm"
   ],
-  "contentHash": "559d42027f1ec16aa3dec684dc62bb66f5c4d240568c719fec789cb12fe2999a"
+  "contentHash": "dd7d9424d7124210c3f1920fe0da9fbfe7a95099a5d189a5893d49c8045e1988"
 }

package/skills/deal-triage/SKILL.md

@@ -8,11 +8,11 @@ description: >-
 ---
 # Deal Triage
 
-You are a deal pipeline orchestrator. Your job is to efficiently review the seller's active deals by dispatching subagents that do deep deal analysis (timeline, stakeholders, MEDDIC qualification), then presenting structured results back to the seller for decisions.
+You are a deal pipeline orchestrator. Your job is to efficiently review the seller's active deals by dispatching subagents that do deep deal analysis (timeline, the buying center, the SPICED record), then presenting structured results back to the seller for decisions.
 
 ## Why this skill exists
 
-Deal review requires cross-referencing multiple data sources per deal: stakeholder map, conversation timeline, MEDDIC qualification, meeting notes, risk signals. Each deal with full context consumes significant tokens. This skill dispatches independent subagents per deal, each with their own context window, who do deep analysis and return compact summaries.
+Deal review requires cross-referencing multiple data sources per deal: the buying center, conversation timeline, the SPICED record (MEDDIC derived from it), meeting notes, risk signals. Each deal with full context consumes significant tokens. This skill dispatches independent subagents per deal, each with their own context window, who do deep analysis and return compact summaries.
 
 ## Subagent architecture
 
@@ -53,8 +53,8 @@ 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, the Customer Impact record under `impact_commitment` — SPICED fields with their basis, status, derived confidence, and `verified_priority` — and the 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.
+1. Call `get_deal_360` for the full deal context in one call (deal info, the buying center under `stakeholders` — the nine roles: initiator, user, champion, decider, gatekeeper, influencer, executive_buyer, approver, purchaser — the Customer Impact record under `impact_commitment` — SPICED fields with their basis, `spiced` completeness with the `next` element to establish, the derived `meddic` view, status, confidence, `verified_priority` — and the 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** `impact_commitment.spiced` / `qualification_score` from the response — do NOT qualify from the reviewer. `manage_deal` with action=qualify extracts a fresh SPICED record from the conversations (an LLM call + a claim write; MEDDIC is derived from it); the reviewer is read-only. If no record stands, the completeness score is < 40, or the record 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 `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:
@@ -70,7 +70,7 @@ ACCOUNT_HEALTH: {0-100 or "—"}
 RISK_SCORE: {0-100}
 ALERTS: {silence_14d, overdue_next_step, slippage, etc. or "none"}
 STAKEHOLDERS: {count} ({comma-separated roles})
-QUALIFICATION: {score}/100 — gaps: {comma-separated gaps or "none"}
+SPICED: {completeness score}/100 — next: {situation | pain | impact | critical_event | decision | "complete"} — MEDDIC gaps: {comma-separated derived gaps or "none"}
 RECOMMENDATION: {advance_stage | set_next_step | add_stakeholder | re_qualify | record_impact | close | mark_stalled | no_action}
 CONFIDENCE: {high | medium | low}
 REASONING: {1-2 sentences explaining the recommendation, including post-close trajectory when account_stage is informative}
@@ -97,8 +97,8 @@ After presenting results, the user can request actions. Execute them using MCP t
 - **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 and refreshes the Customer Impact record from it)
-- **Record impact** → `manage_deal` action=impact_commitment with the SPICED fields the seller confirmed (payload={situation?, pain?, impact? {rational? {metric, baseline, target, unit, by}, emotional?}, critical_event? {kind, due|milestone, consequence}, decision?, first_impact_by?, clear_critical_event?}). Recommend it when `impact_commitment` is null, when `verified_priority` is false on a deal past discovery (no critical event with a consequence, or no named beneficiary), or when the conversation named a different impact or date than the record. Never invent a critical event from the seller's timeline; a renewal date is compelling at most.
+- **Re-qualify** → `manage_deal` action=qualify (extracts the SPICED record again from the conversations and meetings, refreshes the Customer Impact record, and re-projects the MEDDIC view; the operator's own fields stand)
+- **Record impact** → `manage_deal` action=impact_commitment with the SPICED fields the seller confirmed (payload={situation?, pain?, impact? {rational? {metric, baseline, target, unit, by}, emotional?}, critical_event? {kind, due|milestone, consequence}, decision? {criteria?, process?, buying_center? [{name | person_id, role}]}, first_impact_by?, clear_critical_event?}). Recommend it when `impact_commitment` is null, when `verified_priority` is false on a deal past discovery (no critical event with a consequence, or no named beneficiary), or when the conversation named a different impact or date than the record. Never invent a critical event from the seller's timeline; a renewal date is compelling at most.
 - **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)

package/skills/ingest-meetings/SKILL.md

@@ -97,7 +97,7 @@ For each approved transcript:
      Source: <transcript filename> (Google Drive)
      ```
      The `[vruum-meeting:<doc_id>]` marker is what makes re-runs idempotent (Step 5 scans for it). It **must be the very first thing in the summary** — `get_person_360` truncates the activity description to ~200 chars, so a marker placed at the end is cut off and the dedup scan silently fails (re-runs would create duplicate meetings). Keep it verbatim, at the front.
-2. **Record the impact event** — call `manage_account` with action=record_impact, id=<the person's company_id> (from `get_person_360`), and payload={practice: "meeting", event_type: "meeting_held", person_id, summary: <the 1–2 sentence recap, WITHOUT the marker>}. This stamps the account's `first/last_impact_at` and feeds the impact scoreboard — a held meeting is exactly the "value delivered" moment that table exists to record. Skip silently if the person has no linked company.
+2. **Name the meeting's purpose** — pass `purpose` on the `manage_person` interaction (step 1) when the transcript makes it clear: discovery, demo, proposal, negotiation, commit, kickoff, impact_review, renewal, expansion, winback, internal, other. A purpose you got wrong is corrected later with `manage_person` action=set_meeting_purpose (id = `li:<interaction id>` for a logged meeting, or the meeting id; payload={purpose}) — it moves the held event to the right practice. The held meeting's timeline event under its practice (`discovery_held`, `kickoff_held`, `impact_review_held`, …) is written by the backend from the purpose; you do NOT call `manage_account` action=record_impact for the meeting itself — a held meeting is not impact. Record impact only when the transcript states a RESULT the customer got (a value in a unit): then `manage_account` action=record_impact with a post-commit practice (onboarding | adoption | expansion), its event type, `value_delivered_numeric` and `value_delivered_unit`.
 3. **Create each approved task** — `manage_tasks` action=create with:
    - `title` (the action item), `person_id` (+ `deal_id` if there is one)
    - `priority`, and `due_at` as ISO-8601 **only if** a date was actually parseable (omit otherwise)

package/skills/objective-builder/SKILL.md

@@ -20,7 +20,7 @@ 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"}`
+- **Persona** (buying-center role, Revenue Architecture Table 8.2): initiator | user | champion | decider | gatekeeper | influencer | executive_buyer | approver | purchaser — `filters={persona: "executive_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.