@vruum/skills 0.6.55 → 0.6.57
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "vruum",
|
|
3
|
-
"version": "0.6.
|
|
3
|
+
"version": "0.6.57",
|
|
4
4
|
"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
5
|
"author": {
|
|
6
6
|
"name": "Vruum AI",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "vruum",
|
|
3
|
-
"version": "0.6.
|
|
3
|
+
"version": "0.6.57",
|
|
4
4
|
"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
5
|
"author": {
|
|
6
6
|
"name": "Vruum AI",
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@vruum/skills",
|
|
3
|
-
"version": "0.6.
|
|
3
|
+
"version": "0.6.57",
|
|
4
4
|
"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.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"repository": {
|
|
@@ -41,5 +41,5 @@
|
|
|
41
41
|
"outreach",
|
|
42
42
|
"gtm"
|
|
43
43
|
],
|
|
44
|
-
"contentHash": "
|
|
44
|
+
"contentHash": "90e7e98387116c7f975f8312ceef6a487ea485ac1d2e952b67c270ccf7b99dfa"
|
|
45
45
|
}
|
|
@@ -53,7 +53,7 @@ Each subagent prompt should include:
|
|
|
53
53
|
- Instructions to follow the subagent workflow below
|
|
54
54
|
|
|
55
55
|
**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):
|
|
56
|
-
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.
|
|
56
|
+
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.
|
|
57
57
|
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.
|
|
58
58
|
3. Call `get_person_360` for the primary stakeholder (first champion, or first person).
|
|
59
59
|
4. Call `fetch` with type=account_state for the deal's account stage + health. If 404 (no row yet), default to `prospect` / null health.
|
|
@@ -71,7 +71,7 @@ RISK_SCORE: {0-100}
|
|
|
71
71
|
ALERTS: {silence_14d, overdue_next_step, slippage, etc. or "none"}
|
|
72
72
|
STAKEHOLDERS: {count} ({comma-separated roles})
|
|
73
73
|
QUALIFICATION: {score}/100 — gaps: {comma-separated gaps or "none"}
|
|
74
|
-
RECOMMENDATION: {advance_stage | set_next_step | add_stakeholder | re_qualify | close | mark_stalled | no_action}
|
|
74
|
+
RECOMMENDATION: {advance_stage | set_next_step | add_stakeholder | re_qualify | record_impact | close | mark_stalled | no_action}
|
|
75
75
|
CONFIDENCE: {high | medium | low}
|
|
76
76
|
REASONING: {1-2 sentences explaining the recommendation, including post-close trajectory when account_stage is informative}
|
|
77
77
|
SUGGESTED_NEXT_STEP: {specific, actionable next step}
|
|
@@ -97,7 +97,8 @@ After presenting results, the user can request actions. Execute them using MCP t
|
|
|
97
97
|
- **Advance stage** → `manage_deal` action=stage with payload={stage}
|
|
98
98
|
- **Set next step** → `manage_deal` action=update with payload={next_step, next_step_due_at}
|
|
99
99
|
- **Add stakeholder** → `manage_deal` action=stakeholders with payload={action: 'add', person_id, role}
|
|
100
|
-
- **Re-qualify** → `manage_deal` action=qualify (runs MEDDIC analysis again)
|
|
100
|
+
- **Re-qualify** → `manage_deal` action=qualify (runs MEDDIC analysis again and refreshes the Customer Impact record from it)
|
|
101
|
+
- **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.
|
|
101
102
|
- **Close deal** → `manage_deal` action=won or action=lost (payload carries win_factors / loss_reason)
|
|
102
103
|
- **Reopen deal** → `manage_deal` action=reopen with payload={stage}
|
|
103
104
|
- **Mark stalled** → `manage_deal` action=stalled (records the stalled outcome; payload optional)
|
|
@@ -64,7 +64,7 @@ For each row, include a one-line "hook" — a specific recent observation from `
|
|
|
64
64
|
|
|
65
65
|
Step 6 — Hand off to outreach. Two options:
|
|
66
66
|
- **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.
|
|
67
|
-
- **Option B**: Direct `manage_outreach` action=start with an expansion
|
|
67
|
+
- **Option B**: Direct `manage_outreach` action=start with an expansion objective: create it with `target.lever = {"component": "expansion"}` (`objective_create`) and the right tone — formal, ROI-focused, no opener-hooks since the customer already knows you. The lever does the sourcing work: the plan's pool is the installed base (`accounts.account_stage = 'expansion_ready'`, no open deal), no discovery provider runs, the conversion evidence is scoped to expansion (an acquisition rate never sizes it), and `objective_source` qualifies the buyer titles at those accounts for free.
|
|
68
68
|
|
|
69
69
|
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:
|
|
70
70
|
```
|
|
@@ -84,7 +84,7 @@ If no hook can be generated → defer the row. Warm via marketing/content first,
|
|
|
84
84
|
|
|
85
85
|
Step 6 — Hand off. Two options:
|
|
86
86
|
- **Option A (recommended)**: Approve the list; run `/pipeline-fill` with the prospect_list for harness deep research + outreach. Plans get `outreach_plans.tag = bowtie_pilot:winback`.
|
|
87
|
-
- **Option B**: Direct `manage_outreach` action=start with a winback-flavored objective (pre-create a `winback_<your-tenant>` objective — tone: empathetic, no apology, lead with what changed since last conversation).
|
|
87
|
+
- **Option B**: Direct `manage_outreach` action=start with a winback-flavored objective (pre-create a `winback_<your-tenant>` objective — tone: empathetic, no apology, lead with what changed since last conversation). Winback is the book's closed loop over the Bowtie, not a growth component: leave `target.lever` at its default (acquisition by volume) and select the dormant/churned accounts through the objective audience (`objective_account`), so their people are the cohort and the plan does not buy new prospects for them.
|
|
88
88
|
|
|
89
89
|
Step 7 — Success tracking (auto). The calendar webhook records the impact event, equivalent to:
|
|
90
90
|
```
|