@vruum/skills 0.6.51 → 0.6.52
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.52",
|
|
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.52",
|
|
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.52",
|
|
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": "df905b694d203db92ba40dd12ed04bbc3a8e400408533d1deef213894e987760"
|
|
45
45
|
}
|
|
@@ -52,6 +52,27 @@ Two paths — ask which:
|
|
|
52
52
|
- **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.
|
|
53
53
|
- **Fresh**: `manage_campaign` action=create payload={name, ...} — then offer to set tone/cadence via action=update once created.
|
|
54
54
|
|
|
55
|
+
After creation, call `fetch` with `type=settings subtype=channel_status` and
|
|
56
|
+
resolve the campaign's selected sender before assignment or launch:
|
|
57
|
+
|
|
58
|
+
- For email, list every `channels.email.accounts[]` row whose `user_id` matches
|
|
59
|
+
the selected sender. This is the campaign's configured mailbox pool. Treat
|
|
60
|
+
only rows with `eligible=true` as the live rotation pool, and show each
|
|
61
|
+
ineligible row's `eligibility_reason`. Do not describe one mailbox as the
|
|
62
|
+
fixed sender for every new prospect; first sends rotate across eligible rows.
|
|
63
|
+
- For LinkedIn, match `channels.linkedin_accounts[]` by `user_id` and require
|
|
64
|
+
`connected=true` for every LinkedIn action the sequence can select.
|
|
65
|
+
- If the sequence needs email and the selected sender has no mailbox with
|
|
66
|
+
`eligible=true`, stop with `state: "paused"`, code
|
|
67
|
+
`sender_channel_unavailable`. Do the same for a required LinkedIn route with
|
|
68
|
+
no connected LinkedIn account.
|
|
69
|
+
- State the identity rule: after the first email send, every email follow-up and
|
|
70
|
+
reply stays on that mailbox. An unavailable thread-owner mailbox holds the
|
|
71
|
+
action; Vruum never substitutes another email identity.
|
|
72
|
+
|
|
73
|
+
Do not silently add a channel because the sender has it connected. The authored
|
|
74
|
+
touch sequence remains the campaign's channel policy.
|
|
75
|
+
|
|
55
76
|
### Exact wording: touch templates (optional)
|
|
56
77
|
|
|
57
78
|
If the seller wants the SAME proven email/message every time (instead of per-person AI drafting), set a **template** on the touch: `manage_campaign` action=update id=<campaign uuid> with the full `touch_sequence` where that step gains `{"template": {"subject": "...", "body": "..."}}`. Rules:
|
|
@@ -73,6 +94,16 @@ Show the seller a launch summary before anything sends:
|
|
|
73
94
|
- Campaign name, source of messaging (cloned from X / fresh)
|
|
74
95
|
- Cohort size and criteria
|
|
75
96
|
- Channels, cadence, and maximum touches (from the campaign config). Enrollment schedules the first action immediately; spacing between later touches must already be represented in the campaign cadence.
|
|
97
|
+
- Selected sender and the email inboxes in that sender's campaign pool
|
|
98
|
+
- Any required sender channel that is disconnected or missing
|
|
99
|
+
- Reply behavior: a human reply permanently pauses every active enrollment for
|
|
100
|
+
that prospect and queues a response on the channel that received the reply
|
|
101
|
+
- Email identity behavior: new conversations rotate; established conversations
|
|
102
|
+
and email replies remain pinned to their original inbox
|
|
103
|
+
|
|
104
|
+
Refresh `fetch type=settings subtype=channel_status` immediately before asking
|
|
105
|
+
for launch confirmation. Do not trust the Step 3 snapshot because a connection
|
|
106
|
+
can change while the seller reviews the campaign.
|
|
76
107
|
|
|
77
108
|
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}`). Do not pass `start_immediately`; the MCP intentionally ignores it.
|
|
78
109
|
|