@vruum/skills 0.6.13 → 0.6.15

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.13",
+  "version": "0.6.15",
   "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.13",
+  "version": "0.6.15",
   "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/README.md

@@ -71,6 +71,7 @@ npx @vruum/skills install --target /path/to/skills/dir
 - `/create-content` — Co-produce an on-voice LinkedIn content post — pull your own signal, steer the angle conversationally, draft in your voice, then save as draft, schedule, or publish. Use when: write a post, draft LinkedIn content, create content, post about, content co-production, help me write a post.
 - `/csv-pipeline-fill` — CSV harness source for /pipeline-fill. Reads a CSV, auto-detects headers, maps columns, hands off to /pipeline-fill for harness deep research and import. Use when: import CSV, paste a CSV, csv import, prospect list from CSV, csv harness mode.
 - `/deal-triage` — Triage your active deal pipeline. Flags at-risk deals, surfaces stalled-deal alerts, runs MEDDIC qualification, and recommends next actions. Use when: review deals, triage deals, check pipeline, deal review, morning deals, pipeline review, deal health, at-risk deals.
+- `/demand-gen-loop` — Run the full demand-gen motion end to end from your harness — set a goal, build the audience, co-produce the creative, get explicit approval, boost the published post, then monitor engagement and bridge engagers into outreach. Hands off to the specialist skills behind a HARD approval gate. Use when: run demand gen, demand gen loop, goal to boosted post, launch a paid post, boost a post, sponsor a post, full marketing motion, paid amplification.
 - `/diagnose-reply` — Diagnose why a reply happened — what worked or didn't in the outreach that triggered it. Use when: why did they reply, what worked, diagnose reply, reply diagnosis, analyze this reply, what caused this reply, reply analysis.
 - `/engagement-triage` — Review and approve your pending LinkedIn engagement drafts and demand-gen content posts. Use when: triage engagements, review engagement queue, review warming comments, review nurture reactions, review marketing comments, review content drafts, check engagement queue.
 - `/enrich-prospect` — Deep prospect diarization — synthesize everything known about a person into a structured intelligence profile. Use when: enrich prospect, deep research, profile this person, who is this person, research prospect, diarize prospect, prospect briefing.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vruum/skills",
-  "version": "0.6.13",
+  "version": "0.6.15",
   "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": {
@@ -42,5 +42,5 @@
     "outreach",
     "gtm"
   ],
-  "contentHash": "104003ea41ae6f61c9aa3313671763b34c3fcf5409aa179528047d57d080ca37"
+  "contentHash": "b2f0ddac2806baa9a94b8f6e0bcbd7a31f7f6195cc1b4928c9e7bd09914c11a5"
 }

package/skills/demand-gen-loop/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: demand-gen-loop
+description: >-
+  Run the full demand-gen motion end to end from your harness — set a goal,
+  build the audience, co-produce the creative, get explicit approval, boost the
+  published post, then monitor engagement and bridge engagers into outreach.
+  Hands off to the specialist skills behind a HARD approval gate. Use when: run
+  demand gen, demand gen loop, goal to boosted post, launch a paid post, boost a
+  post, sponsor a post, full marketing motion, paid amplification.
+---
+# Demand-Gen Loop
+
+You guide the seller through the whole demand-gen motion in one session: **goal → audience → creative → approve → boost → monitor**. You are a tour guide, not a textbook — you orient on the seller's real numbers, then **hand off** to the specialist skill that owns each piece. The value here is the *spine* that connects them and the **hard approval gate** that sits in front of any spend, not a re-explanation of work another skill already does.
+
+**The rule that overrides everything: nothing spends and nothing publishes until the seller has explicitly approved copy, creative, budget, AND audience.** Default every step to `draft`. The loop can run all the way to "ready to boost" on its own; the seller's money and their public feed are the two things only they can authorize.
+
+## Step 1: Goal intake — ground on who they are
+
+Before talking about creative, read the account so the goal is grounded in their real ICP, signal, and history — never from memory:
+
+- `fetch` type=seller_signals → what the seller actually has to say (their calls, posts, notes, knowledge). This is the raw material for the angle.
+- `fetch` type=stats subtype=outreach → sends, replies, meetings — the demand baseline this post is trying to move.
+- `fetch` type=settings subtype=profile → company profile / ICP completeness.
+
+If `seller_signals` comes back empty (no calls/posts/notes yet), say so plainly and run a **profile-only** goal: build the angle from the company profile and the seller's stated objective alone. Don't invent signal you don't have.
+
+Then settle a one-line goal with the seller in plain language: *who* they want to reach and *what* they want them to do (book a call, learn about a launch, hear a point of view). Hold that goal — every later step references it.
+
+## Step 2: Audience — preview the cohort, iterate to the right one
+
+Turn the goal into targeting criteria and **preview before committing**:
+
+- `search` with `type="people"` and the criteria (include `filters={research_status: "all"}` so stub imports are visible). Read the **total count** and show a **5-row sample** (name, title, company, persona, the attributes that matched).
+- Iterate the criteria conversationally until the cohort is the right size and shape for the goal. An empty preview means the criteria are too tight — loosen and re-run; never proceed to boost on a zero-count audience.
+
+This is the same segmentation conversation `/campaign-builder` runs — **do not reproduce its steps here.** If the seller wants to turn this cohort into an outreach campaign too, hand off to **`/campaign-builder`**. For the boost itself you don't need to pre-materialize an audience: the boost in Step 5 accepts the `{criteria}` directly (it builds the matched audience internally), or a `{matched_audience_id}` if one already exists.
+
+Hold the settled audience (the `{criteria}` you previewed, or a `matched_audience_id`). It is one of the four things the seller approves in Step 4.
+
+## Step 3: Creative — copy, then the visual
+
+**Copy — hand off, don't write it here.** Invoke **`/create-content`** to co-produce the on-voice post. That skill owns author resolution, signal grounding, the steer→draft loop, and the publish guards — narrate it as it works, but never reproduce its drafting procedure. It leaves you a **draft** content post (its id is what Step 5 boosts). Keep the post a draft for now — publish is gated behind the seller's approval in Step 4.
+
+**Visual — generate it on your own tokens, then store it as a draft.** Vruum does not host image-generation infra, so *you* (the harness) generate the ad image yourself and hand Vruum the bytes:
+
+- Generate the image with your own image tools, guided by the settled goal + the approved copy's angle.
+- Store it as a **draft** creative via `manage_campaign` kind='ad' action='store_creative', payload `{image_base64 (raw base64, no data: URL prefix), generation_prompt, generation_provenance: {model, tool, generated_at, notes}}`. It lands as a draft library asset (zero spend, approval is separate). Pass the real `generation_prompt` and provenance so the asset is auditable.
+
+Note the split the platform makes: the **stored creative** is the versioned/library visual asset; the thing the boost actually sponsors is the **published organic post** (Step 5). Attaching the image to the organic post is out of scope for this loop — store it as the creative asset and move on.
+
+## Step 4: HARD approval gate — the money-and-feed checkpoint
+
+This is the load-bearing step. **Before any publish or any spend**, lay out all four things together and get the seller's explicit go-ahead on each:
+
+1. **Copy** — the exact post text from `/create-content`.
+2. **Creative** — the stored visual (generation prompt + provenance).
+3. **Budget** — the daily/total budget you're about to commit. Budget rides the money-gate: state the number in plain currency and get an explicit "yes, spend this."
+4. **Audience** — the previewed cohort (count + the criteria or `matched_audience_id`).
+
+Invariants — these never bend:
+
+- **No spend or publish before approval.** Until the seller has approved all four, you do not call publish and you do not call boost. Period.
+- **Always default to draft.** Both the stored creative and the boost default to `draft`. Draft is the resting state; "live" is something the seller turns on, never something you assume.
+- **Never auto-boost without explicit budget approval.** Do **not** call boost with `approval_mode='auto'` unless the seller has explicitly approved the specific budget in this step. `approval_mode='auto'` is what pushes real paid spend to LinkedIn; absent an explicit budget yes, you pass `approval_mode='draft'` (or omit it — draft is the default) so the campaign lands in the approval queue instead of spending.
+
+If the seller hesitates on any of the four, stop at draft and leave the loop resumable — nothing is lost, nothing has spent.
+
+## Step 5: Launch — publish, then boost
+
+Only after the Step 4 approvals:
+
+1. **Publish the organic post** — `manage_content action=publish` on the draft from `/create-content`. (This inherits `/create-content`'s author guard: if the chosen author's LinkedIn account isn't connected/healthy, publish fails hard rather than posting under another identity — surface that to the seller, don't retry blindly.) This is the post the boost will sponsor.
+2. **Boost the published post** — `manage_campaign` kind='ad' action='boost', payload `{content_post_id: <the just-published post id>, budget: {daily_budget_cents | total_budget_cents}, audience: {criteria} OR {matched_audience_id}, duration_days?, approval_mode}`. Use the `approval_mode` the seller authorized in Step 4 — `draft` unless they explicitly approved the budget for `auto`. The boost double-submit case is handled for you (the endpoint is idempotent on the content post), so don't paper over a retry with a second call.
+
+Report back what went live: the published post and whether the boost is a draft awaiting approval in the queue or pushed.
+
+## Step 6: Monitor + bridge to outreach
+
+The loop doesn't end at "boosted." Teach the operating rhythm:
+
+- **Engagement** — `fetch` type=post_analytics (omit the id for all posts, or pass the post id) for impressions / reactions / comments and the per-post `engagers` sample. `fetch` type=ads subtype=attribution for what the paid spend is attributable to.
+- **The bridge** — engagers on your own published/boosted posts are captured automatically and fanned out as activity; the cron bridges warm engagers toward outreach. The seller's job is the rhythm, not the plumbing: check the **outreach queue** for newly-bridged people, and run **`/engagement-triage`** to review and approve the engagement drafts and demand-gen content the post generates. Point them there — don't reproduce its review procedure.
+
+Close by naming what shipped this session (post live, boost drafted/pushed, first engagers visible) and what the next check-in should look at.
+
+## Hard rules
+
+- **Hand off, never re-teach.** `/create-content` owns copy, `/campaign-builder` owns campaign segmentation, `/engagement-triage` owns engagement review. When one of them owns a step, invoke it and narrate — if you catch yourself writing a numbered sub-procedure that already lives in another skill, stop and hand off.
+- **Inherit every safety gate.** The publish author guard, the boost idempotency, the approval queue — they belong to the platform and the specialist skills. Never bypass, summarize past, or pre-approve through them.
+- **The approval gate is not optional and not summarizable.** Copy + creative + budget + audience, each explicitly approved, before any publish or spend. Default to draft. Never `approval_mode='auto'` without an explicit budget yes.
+- **Tailor from reads, not stereotypes.** Goal, audience, and angle all cite the seller's real numbers from Step 1. If a read fails, say what you couldn't see — don't fill the gap with a guess.

package/skills/outreach-triage/SKILL.md

@@ -28,15 +28,15 @@ For small queues (5 or fewer) or when subagents can't access MCP, review directl
 
 ### Step 1: Get the lay of the land
 
-Call `fetch` with type=stats and subtype=outreach to see the pending queue shape. Present a quick summary:
+Call `fetch` with type=stats and subtype=outreach to see the pending queue shape. The response carries `needs_draft_count` (unauthored touches awaiting authoring) alongside `draft_count` (authored, awaiting approval) — surface both so the authoring backlog is visible up front. Present a quick summary:
 
-"You have X reply responses, Y pending T1s, Z T2+ follow-ups. [Any critical alerts.] Want me to run full triage or focus on a specific category?"
+"You have N to author (needs_draft), X reply responses, Y pending T1s, Z T2+ follow-ups. [Any critical alerts.] Want me to run full triage or focus on a specific category?"
 
 Keep it short. The user knows their queue — they just need the numbers to decide what to prioritize.
 
 ### Step 2: Build the dispatch list and categorize
 
-Once the user says go (or picks a focus area), pull the lightweight message queue via `search` with type=messages, a status=draft filter, and limit=100. This returns message IDs, person names, categories, sequence numbers, and match scores WITHOUT message content. Very cheap on tokens.
+Once the user says go (or picks a focus area), pull the lightweight message queue via `search` with type=messages and limit=100 — make TWO cheap calls: `status=needs_draft` (the authoring lane) and `status=draft` (the review lane). Each returns message IDs, person names, categories, sequence numbers, and match scores WITHOUT message content — very cheap on tokens. Tag each item with its status so dispatch routes it to the right mode: `needs_draft` → authoring, `draft` → review. (Omitting the status filter returns the default actionable set — needs_draft + draft + approved — but pull the two lanes explicitly so already-approved messages awaiting send don't enter triage.)
 
 **Authoring mode (needs_draft items).** The backend no longer writes outreach prose — touches arrive as `needs_draft` items carrying the decision context (channel, touch number, signals) and no content. These are not rewrites; they are blank pages. For each needs_draft item the subagent AUTHORS the message: check the person's research freshness from the review item itself — `person_researched_at` / `company_researched_at` / `research_status` are on the payload, no extra fetch needed (older than ~14 days or missing → research first with WebSearch + the research reads, and persist what you learn via `research` action=save_person, plus action=save_company when you learned something about the company, so it compounds), then write the touch from scratch in the seller's voice against the same quality standards as any review, then submit it via `manage_messages` action=edit with the content — that transitions the item to a normal draft — and approve only what the user's standing instructions allow. Inbound replies also arrive as needs_draft (category inbound_reply, with the conversation attached): author the reply with full thread context. If a prospect turns out to be a bad fit at authoring time, skip the item and say why — authoring is the second qualification gate, not an obligation to write.