@vruum/skills 0.6.9 → 0.6.11

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.9",
+  "version": "0.6.11",
   "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.9",
+  "version": "0.6.11",
   "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.9",
+  "version": "0.6.11",
   "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": "a5a4c4ca055a85e6cf18e68b9de923329ee48b100098f4078e8e0b9d4d463b07"
+  "contentHash": "7a697ed805b730dd66f49fb54b7834b7d35189acd48ac7f0e9adcf4bbfe41149"
 }

package/skills/engagement-triage/SKILL.md

@@ -16,11 +16,15 @@ Do not silently fall back to generic Claude responses.
 
 # Engagement Triage
 
-You review the user's pending LinkedIn engagement drafts (warming comments, nurture reactions, marketing comments) and demand-gen content posts. Subagents dispatch in parallel to UPLIFT the backend's shippable-floor output into great comments, then present results for approval. Separate from `/outreach-triage` (which handles outreach messages).
+You review the user's pending LinkedIn engagement queue (warming comments, nurture reactions, marketing comments) and demand-gen content posts. Subagents dispatch in parallel to AUTHOR comments awaiting prose and UPLIFT any legacy backend drafts, then present results for approval. Separate from `/outreach-triage` (which handles outreach messages).
 
 ## Why this is a skill and not just "call the tool"
 
-The backend produces a research dossier + shippable-floor comment for every engagement (the `polished_floor` field — quality SLA for all four front doors per `project_four_front_doors_architecture`). The skill's job is to UPLIFT that floor into a great comment using the operator's Claude subscription, then write the polished result back via `manage_engagements` with `polish_provenance.source="skill"` so the two-stage edit diff is captured.
+The backend no longer writes engagement prose (VRU-570: the harness authors everything). Items arrive as `needs_draft` — the deterministic research dossier, the target post, and the person context attached, but NO comment text. These are blank pages, not rewrites: the skill AUTHORS the comment in the seller's voice and submits it via `manage_engagements` action=edit (which flips the item to a normal reviewable `draft`), then the operator approves.
+
+**Authoring is the second qualification gate.** The backend's relevance scoring picked the post; whether it's actually comment-worthy is now YOUR call — the judgment the retired agent used to make. If the post isn't worth a comment, recommend skip. NOTE the bundle semantics: skipping a needs_draft comment cascade-skips its bundled like (same `engagement_group_id`), so skip means "don't engage this post at all", not "like without commenting."
+
+Legacy `draft` items (created before the cutover, or under the fallback env) still carry `polished_floor` — for those the job is UPLIFT: rewrite the floor into a great comment, with `polish_provenance.source="skill"` so the edit diff is captured.
 
 Reviewing inline burns tokens fast. Subagents with their own context windows do the uplift in parallel and return compact verdicts.
 
@@ -123,14 +127,24 @@ Hard constraints:
 - No company/product names, URLs, or CTAs.
 
 For each engagement:
-1. Read polished_floor + dossier + pitch_phrases + validator_failures.
-2. Decide UPLIFT, KEEP, or FLAG:
+1. Read status + content + dossier + target_post_text + pitch_phrases (+
+   polished_floor/validator_failures on legacy drafts).
+2. Branch on status:
+   **needs_draft → AUTHOR or FLAG** (this is the default post-VRU-570):
+   - AUTHOR: write the comment from scratch — grounded in the dossier and
+     the actual post text, in the seller's voice, against the same quality
+     bars below. This is a blank page, not a rewrite. Submit via
+     manage_engagements action="edit" (the edit flips the item to draft).
+   - FLAG: the post isn't comment-worthy (generic, off-topic, bad fit) —
+     recommend skip. Skipping cascades to the bundled like, so this means
+     "don't engage this post at all."
+   **draft (legacy/fallback) → UPLIFT, KEEP, or FLAG:**
    - UPLIFT: rewrite to fix listed validator_failures AND/OR pull a sharper
      specific fact from the dossier. Materially better, not lateral.
    - KEEP: polished_floor is already strong. Don't edit.
    - FLAG: structurally broken (off-topic, wrong stage, prospect bad fit).
      Recommend skip + plan-stop cascade.
-3. If UPLIFT, call manage_engagements with:
+3. If AUTHOR or UPLIFT, call manage_engagements with:
      action="edit"
      id="<id>"
      payload={
@@ -147,7 +161,7 @@ IMPORTANT: Do NOT approve or skip engagements. Return recommendations only.
 The operator approves in Step 5.
 
 Return a structured summary for each item:
-ENGAGEMENT: {id} | TYPE: {reaction|comment} | PERSON: {name} | SOURCE: {warming|nurture|marketing} | RECOMMENDATION: {uplifted|kept|flag} | CONFIDENCE: {high|medium|low} | REASONING: {1-2 sentences} | UPLIFTED: {yes/no} | COMMENT_TEXT: {the comment text, or "reaction" for likes} | VALIDATOR_FAILURES_FIXED: {comma-separated, or "none"}
+ENGAGEMENT: {id} | TYPE: {reaction|comment} | PERSON: {name} | SOURCE: {warming|nurture|marketing} | RECOMMENDATION: {authored|uplifted|kept|flag} | CONFIDENCE: {high|medium|low} | REASONING: {1-2 sentences} | AUTHORED_OR_UPLIFTED: {yes/no} | COMMENT_TEXT: {the comment text, or "reaction" for likes} | VALIDATOR_FAILURES_FIXED: {comma-separated, or "none"}
 ```
 
 For high-value comments (match score 80+, nurture, cold marketing), use research mode: 1 comment per subagent. The subagent reads the prospect's actual post via `get_person_360`, cross-checks against the dossier, and uplifts only when there's a real opportunity to improve.

package/skills/engagement-triage/references/engagement-subagent-instructions.md

@@ -1,8 +1,8 @@
-# Subagent Instructions: Engagement Uplift Agent
+# Subagent Instructions: Engagement Authoring Agent
 
-You are uplifting AI-generated LinkedIn engagement items (comments, reactions, reposts) before a human operator approves them. Your job is **uplift, not just review** — the Vruum backend already produced a shippable-floor comment for each item. You take it from "good" to "great" using the dossier, then record provenance so the system learns from the two-stage edit diff.
+You author and review LinkedIn engagement items (comments, reactions, reposts) before a human operator approves them. Post-VRU-570 the backend writes NO engagement prose — items arrive as `status="needs_draft"` carrying the research dossier, the target post, and person context, with no comment text. Your job for those is **authoring**: write the comment from scratch, grounded in the dossier, in the seller's voice. Legacy `status="draft"` items (pre-cutover or fallback-env) still carry a backend `polished_floor` — for those the job is **uplift**.
 
-This is front door 1 (managed ops) in the four-front-doors architecture (see project memory `project_four_front_doors_architecture`). Front doors 2/3/4 ship `polished_floor` from the backend directly; we're the layer that makes managed-ops comments stand out.
+Authoring is also the second qualification gate: the retired backend agent used to decide "should we even comment on this post?" — that call is now yours. A post that isn't comment-worthy gets FLAG (skip), and note that skipping a needs_draft comment cascade-skips its bundled like (`engagement_group_id`).
 
 ## Step 1: Load your items
 
@@ -26,9 +26,24 @@ Call `get_engagement_review` with your assigned `engagement_ids`, `content_lengt
 - `budget_status` — sender daily quota
 - `schema_version` + `rules_version` — backward-compat signals
 
-**Backward-compat:** if `polished_floor` is null (pre-migration queue row), use `content` (== `first_draft`) as your starting point and proceed without dossier grounding. Note `legacy_payload` in REASONING.
+**Backward-compat:** if `polished_floor` is null on a `draft` row (pre-migration queue row), use `content` (== `first_draft`) as your starting point and proceed without dossier grounding. Note `legacy_payload` in REASONING.
 
-## Step 2: Decide UPLIFT / KEEP / FLAG per item
+## Step 2: Branch on status
+
+### needs_draft → AUTHOR or FLAG (the default post-VRU-570)
+
+There is no starting text — `content` is null and that is correct, not an
+error. Write the comment from scratch against the same ACQ structure and
+quality bars as an uplift (Acknowledge a specific phrase/number/entity from
+`target_post_text`; add Context from the dossier; Question optional ~40%).
+Same hard rules: length, banned openers, no pitch_phrases, no
+company/product names or CTAs. Submit via `manage_engagements`
+action="edit" with the content — the edit transitions the item to a normal
+reviewable `draft`. If the post is not comment-worthy (generic engagement
+bait, off-topic for the relationship, prospect bad fit), FLAG it for skip
+instead — do not force a mediocre comment onto a weak post.
+
+### draft (legacy/fallback) → decide UPLIFT / KEEP / FLAG per item
 
 ### 2a. KEEP
 The polished_floor already passes ACQ, references a specific dossier fact, has no validator_failures, and you cannot materially improve it. Don't edit. Don't make lateral moves (swapping synonyms isn't uplift).

package/skills/outreach-triage/SKILL.md

@@ -38,6 +38,8 @@ Keep it short. The user knows their queue — they just need the numbers to deci
 
 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.
 
+**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 (research older than ~14 days or missing → research first with WebSearch + the research reads, and persist what you learn via `research` action=save_person 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.
+
 Categorize into three processing groups:
 
 1. **Reply responses** (category=reply_response) — someone replied, always P1, always human review

package/skills/outreach-triage/references/subagent-instructions.md

@@ -4,6 +4,8 @@ You are reviewing and improving outreach messages before they go to a human oper
 
 You do NOT approve or send messages. You review, edit if needed, and return a structured summary.
 
+**needs_draft items are authoring jobs, not reviews.** The item arrives with decision context (channel, touch number, signals, prior touches) and NO content — the backend does not write prose. Author the message from scratch: verify research freshness first (missing or >14 days stale → research with WebSearch and the research reads, persist findings via `research` action=save_person), then write the touch in the seller's voice to the same standards below, and submit it with `manage_messages` action=edit (content) — that turns it into a normal draft for the orchestrator's approval flow. If the prospect is a bad fit on fresh evidence, recommend skip with the reason instead of writing.
+
 ## Step 1: Load your messages
 
 Call `get_outreach_review` with your assigned `message_ids`, `content_length="full"`. This returns full context for each message including: