@vruum/skills 0.6.15 → 0.6.17

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.15",
+  "version": "0.6.17",
   "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.15",
+  "version": "0.6.17",
   "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/bin/vruum-skills-update-check

@@ -21,7 +21,9 @@ CONFIG_FILE="$STATE_DIR/config.yaml"
 REMOTE_URL="${VRUUM_REMOTE_URL:-https://registry.npmjs.org/@vruum/skills/latest}"
 
 # Force flag busts cache + snooze (used by /vruum-skills-upgrade directly)
+FORCE=0
 if [ "${1:-}" = "--force" ]; then
+  FORCE=1
   rm -f "$CACHE_FILE" "$SNOOZE_FILE"
 fi
 
@@ -75,6 +77,7 @@ if [ -f "$CACHE_FILE" ]; then
   case "$CACHED" in
     UP_TO_DATE*)        TTL=60 ;;
     UPGRADE_AVAILABLE*) TTL=720 ;;
+    CHECK_FAILED*)      TTL=30 ;;
     *)                  TTL=0 ;;
   esac
   STALE=$(find "$CACHE_FILE" -mmin +"$TTL" 2>/dev/null || true)
@@ -93,6 +96,12 @@ if [ -f "$CACHE_FILE" ]; then
           exit 0
         fi
         ;;
+      CHECK_FAILED*)
+        # Recent fetch failure cached — stay quiet and do NOT imply "up to
+        # date". Retry once the short TTL expires. A --force run never reaches
+        # here (it cleared the cache above), so it always re-fetches.
+        exit 0
+        ;;
     esac
   fi
 fi
@@ -100,13 +109,24 @@ fi
 # Step 5: slow path — fetch latest from npm registry.
 mkdir -p "$STATE_DIR"
 RESP="$(curl -fsSL --max-time 5 "$REMOTE_URL" 2>/dev/null || true)"
-# Extract "version":"X.Y.Z" without jq.
-REMOTE="$(echo "$RESP" | grep -oE '"version"[[:space:]]*:[[:space:]]*"[^"]+"' | head -1 | sed -E 's/.*"([^"]+)"$/\1/')"
+# Extract "version":"X.Y.Z" without jq. The trailing `|| true` is load-bearing
+# under `set -euo pipefail`: on a failed/empty fetch the grep matches nothing
+# and (with pipefail) the pipeline exits non-zero, which would errexit the whole
+# script mid-way — the original silent-failure path. Swallow it so REMOTE ends
+# up empty and the unreachable-registry branch below handles it deliberately.
+REMOTE="$(echo "$RESP" | grep -oE '"version"[[:space:]]*:[[:space:]]*"[^"]+"' | head -1 | sed -E 's/.*"([^"]+)"$/\1/' || true)"
 REMOTE="$(echo "$REMOTE" | tr -d '[:space:]')"
 
-# Reject anything that doesn't look like a semver number.
+# Registry unreachable or unparseable response. A failed fetch is NOT evidence
+# the local version is current — caching UP_TO_DATE here is the false-positive
+# that pinned a sandboxed client to a stale bundle: its forced check returned
+# nothing, which /vruum-skills-upgrade reads as "already on latest". Cache a
+# short-lived CHECK_FAILED marker so passive checks don't hammer the registry,
+# but never claim current. A forced check surfaces the failure so the user
+# knows it couldn't run (vs. a real up-to-date).
 if ! echo "$REMOTE" | grep -qE '^[0-9]+\.[0-9]+\.[0-9]+'; then
-  echo "UP_TO_DATE $LOCAL" > "$CACHE_FILE"
+  echo "CHECK_FAILED $LOCAL $(date +%s)" > "$CACHE_FILE"
+  if [ "$FORCE" = 1 ]; then echo "CHECK_FAILED $LOCAL"; fi
   exit 0
 fi
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vruum/skills",
-  "version": "0.6.15",
+  "version": "0.6.17",
   "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": "b2f0ddac2806baa9a94b8f6e0bcbd7a31f7f6195cc1b4928c9e7bd09914c11a5"
+  "contentHash": "ea6ebae97d7fd0f6f8ffe802a6634b495697627372def939359629ba6a0a0bee"
 }

package/skills/csv-pipeline-fill/SKILL.md

@@ -15,7 +15,7 @@ You are the CSV harness-mode source for `/pipeline-fill`. You read a CSV the ope
 ## Inputs
 
 - `file_path`: absolute path to the CSV. If not provided, ask for it. Common locations: `~/Downloads/`, `.context/attachments/` in the workspace.
-- `segment`: target segment (single)
+- `campaign`: target campaign (single)
 - `column_mapping` (optional): explicit `{header_name: canonical_field}` mapping if headers don't auto-resolve. Default: auto-detect.
 
 ## Workflow
@@ -97,7 +97,7 @@ Emit the canonical handoff prompt (defined in `pipeline-fill/RESEARCH-ENGINE.md`
 ```
 Candidate list ready: {N} prospects from csv (after {dedup_count} dedup).
 
-NEXT: invoke /pipeline-fill Step 3 onward (deep research → harness gate → save) with this list and segment {segment_id}.
+NEXT: invoke /pipeline-fill Step 3 onward (deep research → harness gate → save) with this list and campaign {campaign_id}.
 
 Continue automatically? (y/n)
 ```

package/skills/diagnose-reply/SKILL.md

@@ -28,7 +28,7 @@ From the person_360 response, read the full conversation thread. Identify:
 
 ## Step 3: Diagnose
 
-Call `get_performance_metrics` with `view='funnel'` and the segment_id to get segment-level reply rates by channel.
+Call `get_performance_metrics` with `view='funnel'` and the campaign_id to get campaign-level reply rates by channel.
 
 Synthesize a diagnosis:
 
@@ -37,13 +37,13 @@ Synthesize a diagnosis:
 **The message that got the reply:** T3 via LinkedIn DM, 'workflow_pain' angle, referenced their recent job posting for DevOps engineer (specific signal), ended with a question about their current tooling.
 
 **Why it likely worked:**
-- Channel: LinkedIn DM has [X]% reply rate in this segment (vs [Y]% email)
-- Angle: 'workflow_pain' converts at [X]% in this segment ([Z]x above average)
+- Channel: LinkedIn DM has [X]% reply rate in this campaign (vs [Y]% email)
+- Angle: 'workflow_pain' converts at [X]% in this campaign ([Z]x above average)
 - Signal: Referenced a specific, verifiable company signal (job posting)
 - CTA: Question CTA has [X]x lift over statement CTAs
 
 **What's different from the ghosted messages:**
-- T1 and T2 used 'cost_replacement' angle (segment average: [X]%)
+- T1 and T2 used 'cost_replacement' angle (campaign average: [X]%)
 - T1 had surface-level personalization (company name only)
 - T2 had no question CTA
 
@@ -52,10 +52,10 @@ Synthesize a diagnosis:
 ## Step 4: Suggest action
 
 **If positive reply** (interested, wants to learn more, asks a question):
-- "This combination is worth repeating: [angle + specific signal + CTA style]. Note it in your segment's strategy so the next batch follows the same shape."
+- "This combination is worth repeating: [angle + specific signal + CTA style]. Note it in your campaign's strategy so the next batch follows the same shape."
 
 **If negative reply** (not interested, wrong person, bad timing):
-- "This is the [N]th rejection using the '[angle]' strategy in this segment. If the pattern holds, consider deprioritizing this angle for the segment."
+- "This is the [N]th rejection using the '[angle]' strategy in this campaign. If the pattern holds, consider deprioritizing this angle for the campaign."
 
 **If objection or question** (pricing, timing, skepticism):
 - "This is a live conversation. The reply response draft should address [specific objection]. Check the outreach queue — there may be a draft pending."
@@ -64,5 +64,5 @@ Synthesize a diagnosis:
 
 - This skill is diagnostic, not prescriptive. It explains what happened; acting on the pattern (deprioritizing an angle, repeating a winning combination) is a separate, deliberate decision.
 - When the conversation has many touches, focus on the touch that triggered the reply, not the full sequence.
-- Always compare against segment averages to distinguish signal from noise. One data point doesn't make a pattern.
-- If `get_performance_metrics` doesn't have enough data for the segment, say so: "Not enough segment data to compare against. This is a single data point."
+- Always compare against campaign averages to distinguish signal from noise. One data point doesn't make a pattern.
+- If `get_performance_metrics` doesn't have enough data for the campaign, say so: "Not enough campaign data to compare against. This is a single data point."

package/skills/engagement-triage/SKILL.md

@@ -194,7 +194,7 @@ After the first batch returns for any engagement type:
 
 - **All reactions clean:** "First batch of reactions all approved. N more look similar — approve the rest?" Apply without more agents.
 - **All comments have the same issue** (e.g., all too generic, all missing sender voice): Flag the pattern to the user. "First 8 comments are all generic 'great post' style — likely a prompt issue. Want me to edit them all with the same fix, or skip the batch?"
-- **Systematic voice mismatch:** If comments consistently don't sound like the sender, flag it as a segment/prompt config issue rather than fixing each one individually.
+- **Systematic voice mismatch:** If comments consistently don't sound like the sender, flag it as a campaign/prompt config issue rather than fixing each one individually.
 
 ### Step 8: Summary
 

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

@@ -21,7 +21,7 @@ Call `get_engagement_review` with your assigned `engagement_ids`, `content_lengt
 - `polish_provenance.polished_floor.regressed` — true means the backend's floor rewrite was worse than first_draft and was reverted (signal that the rules are hard for this draft)
 - `validator_failures` — structural failures recorded by the backend (e.g. `["banned_opener:Yep","no_specific_marker:0/1"]`). Treat as a checklist.
 - `target_post_text` — what the prospect actually posted
-- `person_id`, `person_name`, `person_title`, `match_score`, `segment_name` — person context
+- `person_id`, `person_name`, `person_title`, `match_score`, `campaign_name` — person context
 - `source` — `warming` / `nurture` / `marketing`
 - `budget_status` — sender daily quota
 - `schema_version` + `rules_version` — backward-compat signals

package/skills/expansion-fill/SKILL.md

@@ -64,7 +64,7 @@ For each row, include a one-line "hook" — a specific recent observation from `
 
 Step 6 — Hand off to outreach. Two options:
 - **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.
-- **Option B**: Direct `manage_outreach` action=start with an expansion-flavored segment (pre-create an `expansion_<your-tenant>` segment with the right tone — formal, ROI-focused, no opener-hooks since the customer already knows you).
+- **Option B**: Direct `manage_outreach` action=start with an expansion-flavored campaign (pre-create an `expansion_<your-tenant>` campaign with the right tone — formal, ROI-focused, no opener-hooks since the customer already knows you).
 
 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:
 ```

package/skills/outreach-triage/SKILL.md

@@ -11,7 +11,7 @@ You are an outreach queue orchestrator. Your job is to efficiently process pendi
 
 ## Why this skill exists
 
-Reviewing outreach messages is context-expensive. Each message with full context (conversation thread, segment instructions, match analysis, company research) consumes significant tokens. This skill solves that by dispatching messages to independent subagents, each with their own context window, who do the deep review work and return compact summaries.
+Reviewing outreach messages is context-expensive. Each message with full context (conversation thread, campaign instructions, match analysis, company research) consumes significant tokens. This skill solves that by dispatching messages to independent subagents, each with their own context window, who do the deep review work and return compact summaries.
 
 ## Subagent architecture
 
@@ -116,7 +116,7 @@ Prospect: {person_name}, {title} at {company}
 Message type: T{sequence_number} follow-up
 
 Steps:
-1. Call get_outreach_review with message_ids="{message_id}" and content_length="full" to get the current message, thread context, segment instructions, and match analysis.
+1. Call get_outreach_review with message_ids="{message_id}" and content_length="full" to get the current message, thread context, campaign instructions, and match analysis.
 2. Call fetch with type=person_research plus get_person_360 for this person to get everything we know.
 3. Call fetch with type=company_research to understand the company's product, positioning, and what problems it solves.
 4. Search the web for this prospect and their company to understand what they actually do, what challenges they face, what they post about.

package/skills/outreach-triage/references/quality-standards.md

@@ -8,7 +8,7 @@ Every outreach message must pass one test: "Would the person sending this actual
 
 ## Tone and Voice
 
-The sender's identity and tone vary by company. Some senders are founders, some are AEs, some are BDRs. The segment's tone instructions define the specific voice. Always follow them.
+The sender's identity and tone vary by company. Some senders are founders, some are AEs, some are BDRs. The campaign's tone instructions define the specific voice. Always follow them.
 
 **Universal rules that apply to every sender:**
 
@@ -53,16 +53,16 @@ This matters more as touch count increases. A 5-touch sequence has fewer angles
 
 ## Touch Sequence Compliance
 
-Each segment defines its own touch sequence with per-touch instructions, channel, timing, and format constraints. These are the source of truth for what each touch should do.
+Each campaign defines its own touch sequence with per-touch instructions, channel, timing, and format constraints. These are the source of truth for what each touch should do.
 
 When reviewing a message:
-- Check the touch_number against the segment's touch_sequence
+- Check the touch_number against the campaign's touch_sequence
 - Read the per-touch instructions (these are one-sentence intents the writer interprets)
 - Verify the message follows the intent (e.g., "No pitch, no product mention" means exactly that)
 - Check word/character limits specified for that touch
 - Verify the CTA approach matches the touch stage (early touches typically use questions, later touches may include calendar links, breakup touches have no ask)
 
-Do NOT apply hardcoded assumptions about what any touch number should do. A T4 might be a breakup in a 5-touch sequence but a mid-funnel touch in a 15-touch sequence. Always read the segment's specific instructions.
+Do NOT apply hardcoded assumptions about what any touch number should do. A T4 might be a breakup in a 5-touch sequence but a mid-funnel touch in a 15-touch sequence. Always read the campaign's specific instructions.
 
 ## Personalization Standards
 
@@ -83,22 +83,22 @@ If personalization is surface-level and better data exists in the review context
 
 ## Vertical and Industry Language
 
-Each segment's selling strategy includes vertical context with industry-native terminology. Messages should use the language the prospect uses, not generic sales language.
+Each campaign's selling strategy includes vertical context with industry-native terminology. Messages should use the language the prospect uses, not generic sales language.
 
 When reviewing:
-- Check if the message uses terms from the segment's vertical context
-- Flag messages that use generic business language when the segment specifies industry terminology
+- Check if the message uses terms from the campaign's vertical context
+- Flag messages that use generic business language when the campaign specifies industry terminology
 - The selling strategy's role adaptation section tells you how to frame things differently for different titles (CEO vs VP vs Director, etc.)
 
-Do NOT hardcode vertical knowledge. Always pull it from the segment instructions for that specific message.
+Do NOT hardcode vertical knowledge. Always pull it from the campaign instructions for that specific message.
 
 ## Channel-Specific Rules
 
 **LinkedIn connection requests**: Hard 280 character limit. No exceptions. Count characters, not words.
 
-**LinkedIn DMs**: Keep within the word limit specified per touch in the segment's touch sequence. No bullet points or numbered lists. Write like a chat message, not an email.
+**LinkedIn DMs**: Keep within the word limit specified per touch in the campaign's touch sequence. No bullet points or numbered lists. Write like a chat message, not an email.
 
-**Email**: Subject line matters. Can be longer and more structured than LinkedIn. Follow the segment's email formatting rules if specified.
+**Email**: Subject line matters. Can be longer and more structured than LinkedIn. Follow the campaign's email formatting rules if specified.
 
 ## Real Examples of Common Failures
 
@@ -113,7 +113,7 @@ Do NOT hardcode vertical knowledge. Always pull it from the segment instructions
 
 **Bad:** "Worth 15 min to see how it works?" / "Worth a quick call?" / "Open to a brief chat?"
 **Why it fails:** Every automated outreach tool uses this pattern. It's the single biggest AI tell in 2026.
-**Fix:** Follow the segment's CTA rules for that touch number. Early touches end with questions. Later touches with calendar links should frame them conversationally, not as a close.
+**Fix:** Follow the campaign's CTA rules for that touch number. Early touches end with questions. Later touches with calendar links should frame them conversationally, not as a close.
 
 ### Failure: Surface personalization
 

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

@@ -12,8 +12,8 @@ Call `get_outreach_review` with your assigned `message_ids`, `content_length="fu
 
 - The draft message content
 - Person info (name, title, company, match score)
-- Segment tone instructions (including anti-AI-tell rules)
-- Segment selling strategy and touch sequence
+- Campaign tone instructions (including anti-AI-tell rules)
+- Campaign selling strategy and touch sequence
 - Match analysis with alignment points and recommended approach
 - Company research summary
 - Recent LinkedIn posts from the prospect
@@ -45,7 +45,7 @@ If ANY repetition is found, the message needs a rewrite. This is the most common
 
 ### 2c. AI tell detection
 
-Scan the message against the anti-AI-tell rules in the segment tone instructions. Also check for:
+Scan the message against the anti-AI-tell rules in the campaign tone instructions. Also check for:
 - Uniform sentence length (every sentence roughly the same word count)
 - Generic opener patterns ("I noticed that...", "I came across your...")
 - Fake personalization (mentioning something vague rather than specific)
@@ -97,7 +97,7 @@ If the message needs changes, rewrite it and apply the edit using `manage_messag
 
 When rewriting:
 - Keep the same strategic intent (don't change a T2 into a T4)
-- Follow the segment tone instructions exactly
+- Follow the campaign tone instructions exactly
 - Stay within word/character limits
 - Make it sound like something a real person would actually type in a LinkedIn DM
 - Use the selling strategy's role adaptation for this person's title
@@ -147,7 +147,7 @@ RESEARCH_DONE: {list of extra research you did, or "none"}
 - You flagged the message for human review
 - The conversation thread suggests strategic complexity (pricing discussions, objections, competitor mentions)
 - You couldn't find enough context to personalize well
-- The segment instructions conflict with what seems like the right approach
+- The campaign instructions conflict with what seems like the right approach
 
 ## Decision Framework
 

package/skills/pipeline-fill/RESEARCH-ENGINE.md

@@ -4,7 +4,7 @@ This is the canonical research-engine doc referenced by `/pipeline-fill` (orches
 
 When a source skill produces a candidate list, it hands off to this engine via the canonical handoff prompt at the bottom of this doc. The engine then runs Steps 3–8: pre-flight → Phase A → Phase B → harness gate → save → report.
 
-The orchestrator's SKILL.md owns the front-of-flow: segment picker (Step 1), source picker (Step 2), and the inline manual-list parser. Everything from Step 3 onward is defined here. **Don't duplicate this doc in source skills** — link to it.
+The orchestrator's SKILL.md owns the front-of-flow: campaign picker (Step 1), source picker (Step 2), and the inline manual-list parser. Everything from Step 3 onward is defined here. **Don't duplicate this doc in source skills** — link to it.
 
 ---
 
@@ -37,7 +37,7 @@ All harness source skills produce candidate lists matching this shape exactly. T
 
 ## MCP-availability precheck (load-bearing — runs before Step 3)
 
-Before any other Step 3 work, call `fetch(type="research_playbook", id=<segment_id>)`. If this fails with "tool not found" / 404 / connection error, abort the run with this exact message:
+Before any other Step 3 work, call `fetch(type="research_playbook", id=<campaign_id>)`. If this fails with "tool not found" / 404 / connection error, abort the run with this exact message:
 
 > Vruum MCP not configured as a user-scoped server. Run:
 >
@@ -53,7 +53,7 @@ The research_playbook fetch also doubles as the ICP load — capture target_titl
 
 ## Step 3 — Pre-flight
 
-Per segment's candidate list:
+Per campaign's candidate list:
 
 1. **MCP precheck + ICP load** (above) — abort run on failure.
 2. **Batch dedup against existing pipeline.** Call `search(type="people", query=[{name, company, linkedin_url} for each candidate])`. Returns one match record per candidate (in input order). Drop candidates with non-null `match` — they're already in pipeline.
@@ -75,11 +75,11 @@ Dispatch one `vruum-company-deep-researcher` per unique uncached company. Subage
 Dispatch prompt template (fill in placeholders):
 
 ```
-You are vruum-company-deep-researcher. Research this company against segment "{segment_name}".
+You are vruum-company-deep-researcher. Research this company against campaign "{campaign_name}".
 
 company_name: {name}
 domain: {domain}
-segment_icp_summary: {one paragraph from the research_playbook fetch}
+campaign_icp_summary: {one paragraph from the research_playbook fetch}
 acv_floor: {dollars or default $10K}
 
 Run your workflow (a–i) and return the structured output block.
@@ -108,7 +108,7 @@ Dispatch one `vruum-prospect-deep-researcher` per surviving candidate. Subagent
 Dispatch prompt template:
 
 ```
-You are vruum-prospect-deep-researcher. Research this prospect against segment "{segment_name}".
+You are vruum-prospect-deep-researcher. Research this prospect against campaign "{campaign_name}".
 
 full_name: {name}
 first_name: {first_name or null}
@@ -122,7 +122,7 @@ phase_a_signals:
   outbound_motion_score: {0|1|2 or null}
   triggers: [list or null]
 
-segment_icp_summary: {one paragraph from the research_playbook fetch}
+campaign_icp_summary: {one paragraph from the research_playbook fetch}
 acv_floor: {dollars}
 
 Run your workflow (a–k) and return the structured output block. Note: do NOT call manage_person action=save_discovered or manage_outreach action=start — those are orchestrator-only and not in your tools list.
@@ -141,19 +141,19 @@ Each subagent returns: `topics_of_interest`, `recent_posts`, `opening_hooks[]` (
 
 This is a **coarse pre-filter** — its job is to avoid wasted backend save calls (`manage_person` action=save_discovered) on obvious dismisses. The **authoritative** gate is server-side `MatchAnalysisAgent.match_score >= 70` and runs inside that save call. The harness gate cannot override the backend gate; it can only dismiss before reaching it.
 
-Per surviving prospect, evaluate four criteria using the segment's playbook ICP and the Phase A + Phase B signals:
+Per surviving prospect, evaluate four criteria using the campaign's playbook ICP and the Phase A + Phase B signals:
 
-### 1. ACV class meets segment threshold?
-- `acv_class >= acv_floor_class` → pass this criterion (smb=$5K, mid=$5–50K, ent=$50K+; segment's `acv_floor` from playbook maps to a class)
+### 1. ACV class meets campaign threshold?
+- `acv_class >= acv_floor_class` → pass this criterion (smb=$5K, mid=$5–50K, ent=$50K+; campaign's `acv_floor` from playbook maps to a class)
 - If no → dismiss `acv_too_low`. Don't call `manage_person` action=save_discovered.
 
 ### 2. Outbound motion or hiring signal?
 - `outbound_motion_score > 0` OR explicit hiring trigger present → pass
-- If no → flag `warming_candidate` (still call `manage_person` action=save_discovered — operator may want to warm-track them; backend match analysis tells us if the segment fit is real)
+- If no → flag `warming_candidate` (still call `manage_person` action=save_discovered — operator may want to warm-track them; backend match analysis tells us if the campaign fit is real)
 
 ### 3. Decision-maker level senior?
 - `decision_maker_level == senior` → pass
-- If `mid` → pass with a note (segment owner decides if mid is acceptable)
+- If `mid` → pass with a note (campaign owner decides if mid is acceptable)
 - If `junior` → look for a more-senior person at the same `company_id` in the Phase B output set. If found, swap and rerun. If not, dismiss `decision_maker_junior`.
 
 ### 4. Trigger event in last 90d?
@@ -217,18 +217,18 @@ If the prospect's company isn't already cached and Phase A produced fresh resear
 
 ### c. Save discovered person (the backend authoritative gate runs here)
 
-Call `manage_person(action="save_discovered", payload={person_id: <from b>, segment_id: ...})`. This:
+Call `manage_person(action="save_discovered", payload={person_id: <from b>, campaign_id: ...})`. This:
 - Runs server-side `analyze_person_match` + signal eval
 - Returns `match_score` (0–100) and `quality_gate_pass` (bool, true iff `match_score >= 70`)
-- Writes the `company_people` row that puts the prospect into the segment
+- Writes the `company_people` row that puts the prospect into the campaign
 
 **Distinguish two failure modes (Codex Finding #9):**
 - **Request failure (5xx, timeout, network):** retry once with 2s backoff. If still failing, leave the prospect in `discovery_failed` status and surface in the final report. **Don't** claim "saved as gate-fail" — the row was never written.
-- **Request success + low score (`quality_gate_pass: false`):** the prospect IS saved with research; backend marks gate-fail; surface for operator review. This is a soft-fail. The prospect is on file with full research, useful for future segments.
+- **Request success + low score (`quality_gate_pass: false`):** the prospect IS saved with research; backend marks gate-fail; surface for operator review. This is a soft-fail. The prospect is on file with full research, useful for future campaigns.
 
 ### d. Bulk enrollment (only after all prospects saved)
 
-Collect all `person_id`s where `harness_gate_status == pass` AND backend `quality_gate_pass == true` AND `mode == save-and-enroll`. Then call `manage_outreach(action="start", id=[those person_ids], payload={segment_id: ...})` ONCE at the end of Step 7.
+Collect all `person_id`s where `harness_gate_status == pass` AND backend `quality_gate_pass == true` AND `mode == save-and-enroll`. Then call `manage_outreach(action="start", id=[those person_ids], payload={campaign_id: ...})` ONCE at the end of Step 7.
 
 - Per-prospect outcomes are returned (enrolled | skipped | failed). Surface per-prospect failures in the report.
 - If `harness_gate_status` is `warming` or `low_priority`, exclude from the bulk enroll list. Operator decides on review.
@@ -241,7 +241,7 @@ Collect all `person_id`s where `harness_gate_status == pass` AND backend `qualit
 Print to chat AND write to `.context/runs/pipeline-fill-{ISO-timestamp}.md` (workspace-local; `.context/` is gitignored per CLAUDE.md). Format identical for both surfaces.
 
 ```
-Pipeline fill complete: {segment_name} (source: {source}, mode: {harness|platform})
+Pipeline fill complete: {campaign_name} (source: {source}, mode: {harness|platform})
 
 Candidates flow:
   source       : {N from source skill output}
@@ -274,14 +274,14 @@ Pool status: healthy | drying up | exhausted ⚠️
 Audit log written: .context/runs/pipeline-fill-{timestamp}.md
 ```
 
-For multi-segment runs, group the report by segment and include a totals summary at the bottom.
+For multi-campaign runs, group the report by campaign and include a totals summary at the bottom.
 
 ---
 
 ## Edge cases + failure handling reference
 
 - **Source returns empty after dedup** — orchestrator says "All {N} candidates already in pipeline, nothing to research" and exits cleanly.
-- **Mid-flight cancellation** (operator Ctrl+C between Phase A and Phase B) — Phase A research is saved server-side. Re-running `/pipeline-fill` for the same segment + source picks up via batch dedup; no re-research of cached companies. Note this in the cancellation message.
+- **Mid-flight cancellation** (operator Ctrl+C between Phase A and Phase B) — Phase A research is saved server-side. Re-running `/pipeline-fill` for the same campaign + source picks up via batch dedup; no re-research of cached companies. Note this in the cancellation message.
 - **Subagent timeout cascade** — Phase A failed for a company → Phase B runs degraded → harness gate marks `gate_inconclusive` → backend decides via cached company research. See Step 4.
 - **Two-gate disagreement** — harness pass + backend fail (or vice versa) → see Step 7c. Stricter outcome wins for enrollment; both states surfaced in the report.
 - **Cached company research >90 days old** — Phase A re-runs the company subagent. Don't trust stale signals for an active fill.
@@ -299,7 +299,7 @@ When a HARNESS source skill completes its sourcing flow and has a candidate list
 ```
 Candidate list ready: {N} prospects from {source}.
 
-NEXT: invoke /pipeline-fill Step 3 onward (deep research → harness gate → save) with this list and segment {segment_id}.
+NEXT: invoke /pipeline-fill Step 3 onward (deep research → harness gate → save) with this list and campaign {campaign_id}.
 
 Continue automatically? (y/n)
 ```

package/skills/pipeline-fill/SKILL.md

@@ -9,19 +9,19 @@ description: >-
 ---
 # Pipeline Fill
 
-You are a source-agnostic pipeline filler. You pick segments to fill, pick a source per segment (Sales Nav / YC / CSV / discovery), and orchestrate harness deep research that gates against the segment ICP before saving prospects into the backend pipeline.
+You are a source-agnostic pipeline filler. You pick campaigns to fill, pick a source per campaign (Sales Nav / YC / CSV / discovery), and orchestrate harness deep research that gates against the campaign ICP before saving prospects into the backend pipeline.
 
 ## Why this skill exists
 
-Filling your pipeline by source-of-the-day is normal. Sales Nav drying up doesn't mean you're stuck — pick YC, paste a CSV, or run discovery (paste candidates OR describe an ICP and the harness sources them via WebSearch + Vruum MCP + LinkedIn search). This skill orchestrates deep research per prospect in your IDE (your compute), pre-filters against segment ICP, then saves the qualified ones into the segment via the backend's canonical gate.
+Filling your pipeline by source-of-the-day is normal. Sales Nav drying up doesn't mean you're stuck — pick YC, paste a CSV, or run discovery (paste candidates OR describe an ICP and the harness sources them via WebSearch + Vruum MCP + LinkedIn search). This skill orchestrates deep research per prospect in your IDE (your compute), pre-filters against campaign ICP, then saves the qualified ones into the campaign via the backend's canonical gate.
 
 ## Where the heavy logic lives
 
 Steps 3–8 (pre-flight, Phase A research, Phase B research, harness gate, save chain, audit-log report) are defined in `RESEARCH-ENGINE.md` (in this same skill directory). This skill owns:
-- Step 1: segment picker (with ETA)
+- Step 1: campaign picker (with ETA)
 - Step 2: source picker (conditional PLATFORM block + always-visible HARNESS block)
 - The discovery-mode handler (paste candidates inline OR describe an ICP and source via harness tools)
-- The multi-segment grammar
+- The multi-campaign grammar
 
 When you reach Step 3, **stop and read** `RESEARCH-ENGINE.md`. That doc is the canonical source for the candidate-list shape, the harness gate criteria, the identity-resolution save chain, and the canonical handoff prompt that source skills use.
 
@@ -50,13 +50,13 @@ The orchestrator's MCP precheck at the top of Step 3 (the `fetch` type=research_
 ## Inputs
 
 - `prospect_list` (optional): pre-built candidate list matching the canonical shape in `RESEARCH-ENGINE.md`. If provided, skip the source-picker step and go straight to Step 3 (pre-flight). This is how source skills hand off.
-- `segment(s)`: target segment(s); multi-segment supported.
+- `campaign(s)`: target campaign(s); multi-campaign supported.
 - `mode`: `research-only` | `save` | `save-and-enroll` (default: `save-and-enroll`).
-- `gate_threshold`: minimum backend `match_score` to enroll (default: segment's existing quality_gate).
+- `gate_threshold`: minimum backend `match_score` to enroll (default: campaign's existing quality_gate).
 
-## Workflow — Step 1: Show pipeline status & pick segments
+## Workflow — Step 1: Show pipeline status & pick campaigns
 
-Call `import_prospects(action="sales_nav_searches", payload={action: "list"})` + `fetch(type="stats", subtype="outreach")` for queue depth + `search(type="campaigns")` for non-Sales-Nav segments. Present a numbered table with **per-segment ETA**:
+Call `import_prospects(action="sales_nav_searches", payload={action: "list"})` + `fetch(type="stats", subtype="outreach")` for queue depth + `search(type="campaigns")` for non-Sales-Nav campaigns. Present a numbered table with **per-campaign ETA**:
 
 ```
 Pipeline status:
@@ -66,29 +66,29 @@ Pipeline status:
   3. Houston CTOs   — 0/20  (20 needed) — harness ETA: ~18m
   4. NYC Partners   — 40/40 ✓
 
-Which segments to fill? (all / 1,3 / skip 2)
+Which campaigns to fill? (all / 1,3 / skip 2)
 Total if all needing fill: ~37m sequential.
 ```
 
-ETA estimates: ~2s for batch Step 3 dedup + ~30s/wave Phase A + ~60s/wave Phase B (5-parallel cap on Phase B). Multi-segment ETAs are sequential.
+ETA estimates: ~2s for batch Step 3 dedup + ~30s/wave Phase A + ~60s/wave Phase B (5-parallel cap on Phase B). Multi-campaign ETAs are sequential.
 
 **Table rules:**
-- One row per segment, numbered sequentially
+- One row per campaign, numbered sequentially
 - Show current/target counts and how many are needed
 - Flag searches that are drying up (⚠️) or accounts near capacity
-- Mark segments already at target with ✓ and don't number them
-- Show per-segment ETA so operator can budget time
+- Mark campaigns already at target with ✓ and don't number them
+- Show per-campaign ETA so operator can budget time
 
-**Wait for the user's response.** Parse: "all", "1, 3", "skip 2", "just the CFO ones", etc. Only proceed with the selected segments.
+**Wait for the user's response.** Parse: "all", "1, 3", "skip 2", "just the CFO ones", etc. Only proceed with the selected campaigns.
 
-## Workflow — Step 2: Pick source per segment (only if `prospect_list` not provided)
+## Workflow — Step 2: Pick source per campaign (only if `prospect_list` not provided)
 
-Per selected segment, prompt:
+Per selected campaign, prompt:
 
 In **public mode** (the package builder strips the PLATFORM block from this skill before publishing), the picker shows only HARNESS modes, renumbered 1–4:
 
 ```
-Source for {segment_name}?
+Source for {campaign_name}?
   HARNESS mode (your compute, in-chat deep research, visible & interruptible):
     1. sales-nav-deep    — Sales Nav profiles + harness deep research
     2. yc                — scrape YC directory with filters you provide
@@ -107,7 +107,7 @@ Per source pick, dispatch:
 - `csv` → invoke `/csv-pipeline-fill` to produce a candidate list, then continue to Step 3 with it.
 - `discovery` → use the discovery-mode handler below to produce a candidate list (handler branches: paste-shaped input → parse, prose ICP brief → harness sources via WebSearch + Vruum MCP + LinkedIn search), then continue to Step 3 with it.
 
-**Multi-segment behavior:** segments run sequentially. Segment 1's Step 7 (save chain + bulk enroll) completes before segment 2's Step 3 starts. Predictable rate-limit behavior, simple progress narrative. Trade-off: 3-segment fills are ~37min wall-clock vs ~22min if Phase A/B were overlapped across segments. Cross-segment overlap is a v2.
+**Multi-campaign behavior:** campaigns run sequentially. Campaign 1's Step 7 (save chain + bulk enroll) completes before campaign 2's Step 3 starts. Predictable rate-limit behavior, simple progress narrative. Trade-off: 3-campaign fills are ~37min wall-clock vs ~22min if Phase A/B were overlapped across campaigns. Cross-campaign overlap is a v2.
 
 ## Discovery-mode handler (for `discovery` source)
 
@@ -127,13 +127,13 @@ Drop blank lines and lines starting with `#` (treat as comments).
 **Path B — operator describes an ICP** (you want the harness to discover candidates)
 Operator gives a brief like "Series A-C SaaS founders, US, 50-500 ppl" or "directors of operations at MSPs in DFW, recently posted about hiring". Harness sources candidates from scratch:
 
-1. **Anchor on segment ICP** — read the segment's existing ICP/company profile (via `fetch` type=campaign and `fetch` type=settings subtype=profile) and merge with the operator's brief. Show a one-line synthesis ("OK so: Series A-C SaaS, US, 50-500 ppl, founder/CEO/CTO titles") and confirm before sourcing.
+1. **Anchor on campaign ICP** — read the campaign's existing ICP/company profile (via `fetch` type=campaign and `fetch` type=settings subtype=profile) and merge with the operator's brief. Show a one-line synthesis ("OK so: Series A-C SaaS, US, 50-500 ppl, founder/CEO/CTO titles") and confirm before sourcing.
 2. **Source companies first** — use harness tools to find candidate companies matching the brief:
    - `WebSearch` for funding announcements, news, lists ("Series A SaaS 2026", "TechCrunch Series B SaaS announcements")
    - `WebFetch` on Crunchbase / PitchBook / company directories
    - `mcp__vruum__import_prospects` with action=sales_nav_search (payload={keywords, title, limit}) for company-fitting roles when the brief is people-shaped (e.g. "VPs of Eng at Series A SaaS")
-3. **Source people from each company** — for each candidate company, use `mcp__vruum__search` with type=companies and filters={domain, seniority} (Unipile-backed; respects LinkedIn rate limits) to find titles matching the segment ICP. Cap at ~5 people per company to spread the discovery surface.
-4. **Dedup against existing pipeline** — for each discovered person, check `mcp__vruum__search` with type=people and a name/company keyword query so you don't research someone the segment already has.
+3. **Source people from each company** — for each candidate company, use `mcp__vruum__search` with type=companies and filters={domain, seniority} (Unipile-backed; respects LinkedIn rate limits) to find titles matching the campaign ICP. Cap at ~5 people per company to spread the discovery surface.
+4. **Dedup against existing pipeline** — for each discovered person, check `mcp__vruum__search` with type=people and a name/company keyword query so you don't research someone the campaign already has.
 5. **Show the discovered list to the operator** before handoff. Format: `Name (title) — Company [linkedin]`. Cap the surface at 2x daily_target so we don't over-source. Get a "go" / "drop X" before continuing.
 
 Discovery-path candidates produced in either path use the canonical shape in `RESEARCH-ENGINE.md` and feed into Step 3 the same way.

package/skills/sales-nav-deep-fill/SKILL.md

@@ -14,18 +14,18 @@ You are the Sales Nav harness-mode source for `/pipeline-fill`. You produce a ca
 
 ## Inputs
 
-- `segment`: target segment (single — multi-segment lives in `/pipeline-fill`)
+- `campaign`: target campaign (single — multi-campaign lives in `/pipeline-fill`)
 - `count`: how many profiles to pre-filter (default 30)
 
 ## Workflow
 
 ### Step 1: Preview Sales Nav profiles
 
-Call `import_prospects(action="sales_nav_preview", payload={segment: ..., count: ...})`. Returns profile data + segment ICP context (target_titles, target_industries, value_proposition, positioning_angle, differentiators).
+Call `import_prospects(action="sales_nav_preview", payload={campaign: ..., count: ...})`. Returns profile data + campaign ICP context (target_titles, target_industries, value_proposition, positioning_angle, differentiators).
 
 ### Step 2: Dispatch `vruum-pipeline-filter` for ICP pre-filter
 
-Spawn the existing `vruum-pipeline-filter` subagent (defined at `.claude/agents/vruum-pipeline-filter.md`). It evaluates each profile against the segment ICP using cheap title/company matching — no LinkedIn API calls, no deep research. APPROVE / DISMISS per profile.
+Spawn the existing `vruum-pipeline-filter` subagent (defined at `.claude/agents/vruum-pipeline-filter.md`). It evaluates each profile against the campaign ICP using cheap title/company matching — no LinkedIn API calls, no deep research. APPROVE / DISMISS per profile.
 
 This is the cheap pre-filter — it removes obvious mismatches (titled-wrong, industry-wrong) before they enter Phase A/B deep research. Saves ~8 minutes per fill on a 30-profile preview that has 10 mismatches.
 
@@ -47,7 +47,7 @@ Emit the canonical handoff prompt (defined in `pipeline-fill/RESEARCH-ENGINE.md`
 ```
 Candidate list ready: {N} prospects from sales-nav-deep.
 
-NEXT: invoke /pipeline-fill Step 3 onward (deep research → harness gate → save) with this list and segment {segment_id}.
+NEXT: invoke /pipeline-fill Step 3 onward (deep research → harness gate → save) with this list and campaign {campaign_id}.
 
 Continue automatically? (y/n)
 ```

package/skills/vruum-skills-upgrade/SKILL.md

@@ -67,10 +67,13 @@ Force a fresh check first, then run the flow above starting from Step 2:
 ~/.vruum/bin/vruum-skills-update-check --force
 ```
 
-If the forced check returns nothing, report `already on latest (v$(cat ~/.vruum/VERSION))` and exit.
+Interpret the forced check's output:
+- Returns nothing → genuinely up to date. Report `already on latest (v$(cat ~/.vruum/VERSION))` and exit.
+- `CHECK_FAILED <local>` → the registry could NOT be reached (network/sandbox), so we do **not** know if you're current. Report `upgrade check failed — couldn't reach the npm registry (network/sandbox); not necessarily on latest. Try again later or from an unsandboxed shell.` Do NOT claim "already on latest." (A forced check emits this whenever the fetch fails; a sandbox that blocks the registry is the common cause.)
+- `UPGRADE_AVAILABLE <old> <new>` → run the upgrade flow from Step 2.
 
 ## When something goes wrong
 
 - `npm install` fails with permissions → tell the user to re-run with `sudo` or fix their npm prefix. Don't auto-sudo.
 - `vruum-skills install` reports skipped skills → surface the conflict message verbatim; user needs to remove conflicting files.
-- Network failure on registry lookup → report `upgrade check failed, try again later` and continue with the original skill (don't block work on a transient fetch error).
+- Network failure on registry lookup → the forced check now emits `CHECK_FAILED <local>` (it no longer silently looks up to date). Report `upgrade check failed, try again later` and continue with the original skill (don't block work on a transient fetch error).

package/skills/winback-fill/SKILL.md

@@ -84,7 +84,7 @@ If no hook can be generated → defer the row. Warm via marketing/content first,
 
 Step 6 — Hand off. Two options:
 - **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`.
-- **Option B**: Direct `manage_outreach` action=start with a winback-flavored segment (pre-create a `winback_<your-tenant>` segment — tone: empathetic, no apology, lead with what changed since last conversation).
+- **Option B**: Direct `manage_outreach` action=start with a winback-flavored campaign (pre-create a `winback_<your-tenant>` campaign — tone: empathetic, no apology, lead with what changed since last conversation).
 
 Step 7 — Success tracking (auto). The calendar webhook records the impact event, equivalent to:
 ```

package/skills/yc-pipeline-fill/SKILL.md

@@ -10,11 +10,11 @@ description: >-
 
 You are the YCombinator harness-mode source for `/pipeline-fill`. You scrape YC's public directory, extract founder LinkedIn URLs, dedup, and hand a candidate list to the orchestrator. No deep research, no harness gate, no save chain in this skill — that's all in `pipeline-fill/RESEARCH-ENGINE.md`.
 
-This is the answer to "DFW CFOs Sales Nav is dead, what now?" — pivot to YC, get 30 founders into the segment in ~15 minutes.
+This is the answer to "DFW CFOs Sales Nav is dead, what now?" — pivot to YC, get 30 founders into the campaign in ~15 minutes.
 
 ## Inputs
 
-- `segment`: target segment (single)
+- `campaign`: target campaign (single)
 - `count`: target number of imports (default 50)
 - `filters` (REQUIRED — no defaults; operator must specify at least one):
   - `team_size_min` / `team_size_max` (proxy for funding stage)
@@ -27,9 +27,9 @@ If the operator runs the skill without filters, prompt: "YC has 5K+ companies
 
 ## Workflow
 
-### Step 1: Load segment ICP
+### Step 1: Load campaign ICP
 
-Call `fetch` type=research_playbook id=<segment_id> to load ICP context. The downstream subagents need it for classification; capture it now to pass forward.
+Call `fetch` type=research_playbook id=<campaign_id> to load ICP context. The downstream subagents need it for classification; capture it now to pass forward.
 
 ### Step 2: Algolia connectivity precheck
 
@@ -149,7 +149,7 @@ Emit the canonical handoff prompt (defined in `pipeline-fill/RESEARCH-ENGINE.md`
 ```
 Candidate list ready: {N} prospects from yc.
 
-NEXT: invoke /pipeline-fill Step 3 onward (deep research → harness gate → save) with this list and segment {segment_id}.
+NEXT: invoke /pipeline-fill Step 3 onward (deep research → harness gate → save) with this list and campaign {campaign_id}.
 
 Continue automatically? (y/n)
 ```