@vruum/skills 0.5.1 → 0.5.2
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.
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@vruum/skills",
|
|
3
|
-
"version": "0.5.
|
|
3
|
+
"version": "0.5.2",
|
|
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": {
|
|
@@ -36,5 +36,5 @@
|
|
|
36
36
|
"outreach",
|
|
37
37
|
"gtm"
|
|
38
38
|
],
|
|
39
|
-
"contentHash": "
|
|
39
|
+
"contentHash": "e0050f63b3a0e2e8dfd104839324afe1d385046dc74fe0a2347ba37906ddd7b4"
|
|
40
40
|
}
|
|
@@ -31,6 +31,18 @@ Call `get_seller_signal_bundle` with the seller's rough topic as the `draft_brie
|
|
|
31
31
|
- If `formatted_evidence` is present → use it as the grounding evidence in Step 3.
|
|
32
32
|
- If `formatted_evidence` is `null` (a `formatted_evidence_skipped_reason` of `bundle_empty` means there was no signal to draw on yet; any other reason means the evidence was withheld and the `bundle` text is redacted to empty too) → say so plainly and fall back to a **profile-only draft**: write from the company voice profile and the seller's stated topic alone, with no evidence grounding.
|
|
33
33
|
|
|
34
|
+
## Step 2.5: Check the calendar (optional)
|
|
35
|
+
|
|
36
|
+
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 3 silently and draft anyway.
|
|
37
|
+
|
|
38
|
+
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:
|
|
39
|
+
|
|
40
|
+
- **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.
|
|
41
|
+
- **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.
|
|
42
|
+
- **Adapt a strong recent angle** — if a recent post's theme clearly resonated, consider building on it instead of repeating a weaker one. This is soft: the tool orders by recency, not performance, so treat "recent" as a hint, not proof that an angle worked.
|
|
43
|
+
|
|
44
|
+
Surface anything useful to the seller as a light suggestion ("you posted on this theme last week — want a different angle, or a follow-up?"), never as a blocker. If `posts` is empty, the tool is unavailable, or it errors, say nothing about the calendar and just continue. Do not retry it.
|
|
45
|
+
|
|
34
46
|
## Step 3: Surface the evidence and settle the brief
|
|
35
47
|
|
|
36
48
|
If you have `formatted_evidence`, show the seller the relevant points you found, in plain language:
|