@sellable/mcp 0.1.321 → 0.1.323

package/dist/tools/prompts.d.ts

@@ -137,7 +137,7 @@ export interface PostFindLeadsScoutRegistryResponse {
 }
 export declare const DEFAULT_SUBSKILL_PROMPT_CHUNK_CHARS = 48000;
 export declare const MAX_SUBSKILL_PROMPT_CHUNK_CHARS = 48000;
-export declare const ALLOWED_SUBSKILL_PROMPT_NAMES: readonly ["building-gtm-tables", "content", "create-ab-test", "create-campaign", "create-campaign-brief", "create-campaign-v2", "create-campaign-v2-tail", "create-campaign-v2-validation", "create-post", "create-rubric", "engage", "enrich-prospects", "find-leads", "foundation", "generate-messages", "interview", "load-voice", "research", "research-prospect", "research-sender", "workflow-sequences"];
+export declare const ALLOWED_SUBSKILL_PROMPT_NAMES: readonly ["building-gtm-tables", "content", "create-ab-test", "create-campaign", "create-campaign-brief", "create-campaign-v2", "create-campaign-v2-tail", "create-campaign-v2-validation", "create-evergreen-campaigns", "create-post", "create-rubric", "engage", "enrich-prospects", "fill-send-horizon", "find-leads", "foundation", "generate-messages", "interview", "load-voice", "refresh-sender-engagement", "research", "research-prospect", "research-sender", "weekly-campaign-summary", "workflow-sequences"];
 export declare const promptToolDefinitions: ({
     name: string;
     description: string;
@@ -181,7 +181,7 @@ export declare const promptToolDefinitions: ({
         properties: {
             subskillName: {
                 type: string;
-                enum: readonly ["building-gtm-tables", "content", "create-ab-test", "create-campaign", "create-campaign-brief", "create-campaign-v2", "create-campaign-v2-tail", "create-campaign-v2-validation", "create-post", "create-rubric", "engage", "enrich-prospects", "find-leads", "foundation", "generate-messages", "interview", "load-voice", "research", "research-prospect", "research-sender", "workflow-sequences"];
+                enum: readonly ["building-gtm-tables", "content", "create-ab-test", "create-campaign", "create-campaign-brief", "create-campaign-v2", "create-campaign-v2-tail", "create-campaign-v2-validation", "create-evergreen-campaigns", "create-post", "create-rubric", "engage", "enrich-prospects", "fill-send-horizon", "find-leads", "foundation", "generate-messages", "interview", "load-voice", "refresh-sender-engagement", "research", "research-prospect", "research-sender", "weekly-campaign-summary", "workflow-sequences"];
                 description: string;
             };
             offset: {
@@ -216,7 +216,7 @@ export declare const promptToolDefinitions: ({
         properties: {
             subskillName: {
                 type: string;
-                enum: readonly ["building-gtm-tables", "content", "create-ab-test", "create-campaign", "create-campaign-brief", "create-campaign-v2", "create-campaign-v2-tail", "create-campaign-v2-validation", "create-post", "create-rubric", "engage", "enrich-prospects", "find-leads", "foundation", "generate-messages", "interview", "load-voice", "research", "research-prospect", "research-sender", "workflow-sequences"];
+                enum: readonly ["building-gtm-tables", "content", "create-ab-test", "create-campaign", "create-campaign-brief", "create-campaign-v2", "create-campaign-v2-tail", "create-campaign-v2-validation", "create-evergreen-campaigns", "create-post", "create-rubric", "engage", "enrich-prospects", "fill-send-horizon", "find-leads", "foundation", "generate-messages", "interview", "load-voice", "refresh-sender-engagement", "research", "research-prospect", "research-sender", "weekly-campaign-summary", "workflow-sequences"];
                 description: string;
             };
             assetPath: {

package/dist/tools/prompts.js

@@ -25,18 +25,22 @@ export const ALLOWED_SUBSKILL_PROMPT_NAMES = [
     "create-campaign-v2",
     "create-campaign-v2-tail",
     "create-campaign-v2-validation",
+    "create-evergreen-campaigns",
     "create-post",
     "create-rubric",
     "engage",
     "enrich-prospects",
+    "fill-send-horizon",
     "find-leads",
     "foundation",
     "generate-messages",
     "interview",
     "load-voice",
+    "refresh-sender-engagement",
     "research",
     "research-prospect",
     "research-sender",
+    "weekly-campaign-summary",
     "workflow-sequences",
 ];
 export const promptToolDefinitions = [

package/dist/tools/registry.d.ts

@@ -236,7 +236,7 @@ export declare const allTools: ({
         properties: {
             subskillName: {
                 type: string;
-                enum: readonly ["building-gtm-tables", "content", "create-ab-test", "create-campaign", "create-campaign-brief", "create-campaign-v2", "create-campaign-v2-tail", "create-campaign-v2-validation", "create-post", "create-rubric", "engage", "enrich-prospects", "find-leads", "foundation", "generate-messages", "interview", "load-voice", "research", "research-prospect", "research-sender", "workflow-sequences"];
+                enum: readonly ["building-gtm-tables", "content", "create-ab-test", "create-campaign", "create-campaign-brief", "create-campaign-v2", "create-campaign-v2-tail", "create-campaign-v2-validation", "create-evergreen-campaigns", "create-post", "create-rubric", "engage", "enrich-prospects", "fill-send-horizon", "find-leads", "foundation", "generate-messages", "interview", "load-voice", "refresh-sender-engagement", "research", "research-prospect", "research-sender", "weekly-campaign-summary", "workflow-sequences"];
                 description: string;
             };
             offset: {
@@ -271,7 +271,7 @@ export declare const allTools: ({
         properties: {
             subskillName: {
                 type: string;
-                enum: readonly ["building-gtm-tables", "content", "create-ab-test", "create-campaign", "create-campaign-brief", "create-campaign-v2", "create-campaign-v2-tail", "create-campaign-v2-validation", "create-post", "create-rubric", "engage", "enrich-prospects", "find-leads", "foundation", "generate-messages", "interview", "load-voice", "research", "research-prospect", "research-sender", "workflow-sequences"];
+                enum: readonly ["building-gtm-tables", "content", "create-ab-test", "create-campaign", "create-campaign-brief", "create-campaign-v2", "create-campaign-v2-tail", "create-campaign-v2-validation", "create-evergreen-campaigns", "create-post", "create-rubric", "engage", "enrich-prospects", "fill-send-horizon", "find-leads", "foundation", "generate-messages", "interview", "load-voice", "refresh-sender-engagement", "research", "research-prospect", "research-sender", "weekly-campaign-summary", "workflow-sequences"];
                 description: string;
             };
             assetPath: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.321",
+  "version": "0.1.323",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-evergreen-campaigns/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: create-evergreen-campaigns
+description: Reconcile a sender team's evergreen campaign structure — create-or-reuse the standing campaigns (per-sender post engagers + shared fallback lanes) idempotently, with sequences attached and prospect-safe message briefs. Never duplicates, never launches. Schedule-automation friendly ("make sure evergreen campaigns exist for these users").
+visibility: internal
+---
+
+# Create Evergreen Campaigns
+
+<role>
+You are a campaign structure reconciler. Evergreen campaigns are the standing
+always-on lanes every sender should have. Your job is to make reality match the
+plan — creating only what is missing, reusing everything that exists, and never
+producing duplicates. Reconcile/create-reuse only; this skill never launches campaigns.
+</role>
+
+<inputs>
+The invoking prompt names the senders ("create evergreen campaigns for csreyes92 and thomas"). Resolve each via `list_senders`.
+
+Default evergreen plan per workspace (override only if the prompt specifies different lanes):
+
+1. **`<Sender Name> - Post Engagers`** — one per sender (warm lane, highest priority)
+2. **`<Workspace/Team> - Shared Signal Discovery`** — one shared across senders
+3. **`<Workspace/Team> - Shared Cold Fallback`** — one shared across senders
+</inputs>
+
+<objective>
+1. **Inventory first**: `get_campaigns` + `list_tables` in the active workspace. Match existing campaigns to the plan by name (case-insensitive, ignore suffixes like "(Copy)"). A matching non-archived campaign = REUSE; record it and move on. Never create a second campaign for a slot that already has one.
+2. **Create only the missing slots** with `create_on_demand_campaign({ name, senderIds, campaignBrief })`:
+   - Post Engagers lanes: that sender's ID only. Shared lanes: all the senders' IDs.
+   - The brief must include the warm post-engager first-message template style — short, casual, references the post they engaged with, closed question, **no internal vocabulary, no pitch, no meeting ask** in message one:
+
+     ```
+     {{first_name}}
+
+     Hey there
+
+     Saw you pop up on my post about {{post_topic_line}}
+     ```
+
+   - The sequence is auto-selected by sender tier; do not hand-author sequence templates here. Never select a paid-InMail template.
+3. **Verify each slot** after create/reuse: `get_campaign` shows the table exists and a sequence is attached (`list_tables({ hasSequence: true })` as a cross-check).
+4. **Report the reconcile plan and result** — every slot tagged `reused` or `created`, nothing else:
+
+```
+Evergreen Reconcile — {date}
+• Christian Reyes - Post Engagers: reused (18 rows)
+• Thomas Nobbs - Post Engagers: reused (8 rows)
+• Sellable.dev - Shared Signal Discovery: reused
+• Sellable.dev - Shared Cold Fallback: created (empty — needs leads)
+All campaigns remain unlaunched. Next: refresh-sender-engagement to supply the warm lanes, then fill-send-horizon.
+```
+</objective>
+
+<safety>
+- **Idempotent by construction**: rerunning on a schedule must produce all-`reused` and zero new campaigns. If a name matches ambiguously (two candidates), reuse the most recently updated and flag the duplicate for the operator instead of creating a third.
+- Never call `start_campaign` / `start_on_demand_campaign`. New campaigns stay in their default unlaunched state.
+- Never archive, rename, or delete existing campaigns — reconcile is additive; structural removals are operator actions.
+- Respect workspace boundaries: senders and campaigns must belong to the active workspace.
+</safety>

package/skills/fill-send-horizon/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: fill-send-horizon
+description: Keep campaigns' send queues full for the next N days — enrich, score, and prepare messages for eligible rows so approved sends are always staged ahead. Schedule-automation friendly ("fill send horizon for these users/campaigns"). Never launches campaigns, never spends paid InMail.
+visibility: internal
+---
+
+# Fill Send Horizon
+
+<role>
+You are a campaign operations agent keeping send queues full. Your job: for each target campaign, make sure the next two working days (or the requested horizon) have prepared, ready-to-send messages staged — without ever launching a campaign or sending anything yourself.
+</role>
+
+<inputs>
+The invoking prompt (often a scheduled automation) names the targets. Accept any of:
+
+- Campaign names or IDs ("fill send horizon for Christian Reyes - Post Engagers")
+- Sender names ("…for csreyes92 and thomas") — resolve via `list_senders`, then `get_campaigns` and match campaigns attached to those senders
+- Nothing specific ("fill send horizon") — operate on all non-archived campaign tables in the active workspace that have a sequence attached (`list_tables({ hasSequence: true })`), skipping ARCHIVED ones
+
+Optional inputs: `targetPreparedMessages` (default: leave unset for the adaptive default), an explicit "approve" instruction (see safety rules), and a **waterfall priority order** (see below).
+</inputs>
+
+<objective>
+For each target campaign:
+
+1. `get_campaign` → confirm workspace, workflowTableId, and current stats. Skip and report any campaign whose table is ARCHIVED.
+2. `start_campaign_message_preparation({ campaignId })` — this queues pending Enrich Prospect cells, lets ICP/rubric and Generate Message cascade, and marks prepared rows ready. Omit `maxRowsToCheck` and `batchSize` for the adaptive default unless the invoking prompt sets them.
+3. Poll `get_campaign_message_preparation_status` until the job completes or stops. Read `progress.enrichedRows`, `preparedMessages`, and `stopReason` — never treat `checkedRows` as enriched rows.
+4. If the stop reason is source exhaustion (no more eligible rows), report it as "source thin — needs new leads" and name `refresh-sender-engagement` (for post-engager lanes) or `find-leads` as the refill path. Do not invent leads.
+5. Report per campaign: prepared count, approved count, what is staged for the horizon, and the single next operator action (usually "approve messages in the UI").
+</objective>
+
+<waterfall>
+## Campaign hierarchy (waterfall order)
+
+When the invoking prompt gives an ordered list — or when a sender has the standard evergreen lanes — fill in **priority order** and only fall through when a lane runs dry:
+
+1. **Default order per sender**: `<Sender> - Post Engagers` (warmest) → `Shared Signal Discovery` → `Shared Cold Fallback` (coldest). The invoking prompt can override with any explicit order ("fill in this order: A, B, C").
+2. **Fill the top lane first.** Move to the next lane ONLY when the current one stops with source exhaustion / no more eligible rows — never because it is merely slow.
+3. **Stop descending once the horizon target is met.** If the warm lane alone fills the horizon, the cold lanes get nothing this run — that is correct, not a gap.
+4. **Report per lane** so the operator can see the waterfall working:
+
+```
+csreyes92 waterfall: Post Engagers filled 4/4 (horizon met — lower lanes skipped)
+thomas waterfall: Post Engagers 1/4 (source thin) → Shared Signal Discovery 3/3 remaining
+```
+
+To **change the hierarchy**, the scheduled automation just states the new order in its prompt — the order is an input to this skill, not stored state.
+</waterfall>
+
+<safety>
+- **Never call `start_campaign`, `start_on_demand_campaign`, or `start_direct_campaign`.** Activating a campaign is always an explicit human action outside this skill.
+- Use `approvalMode: "approve"` ONLY when the invoking prompt explicitly says to auto-approve (e.g. "fill and approve"). Default is `mark_ready` — a human approves in the UI.
+- Never use a sender from one workspace for another workspace's campaign. If `get_campaign` shows a workspace mismatch with the active workspace, stop and report.
+- Paid InMail: never opt a campaign into paid-InMail templates or spend credits. If a campaign's sequence already includes a paid-InMail step, note it in the report but do not alter it.
+- This skill prepares; the product's sweeper sends — only from ACTIVE campaigns, only approved rows, only inside sending hours. Say so in the report so the operator knows nothing went out.
+</safety>
+
+<output>
+One compact report:
+
+```
+Fill Send Horizon — {date}
+• {Campaign A}: {n} messages prepared ({m} awaiting approval) — horizon staged through {date}
+• {Campaign B}: source thin after {k} prepared — refill via refresh-sender-engagement
+Next operator action: approve {m} messages in {Campaign A}
+Nothing was sent or launched; campaigns remain in their current status.
+```
+</output>

package/skills/refresh-sender-engagement/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: refresh-sender-engagement
+description: Top up a sender's post-engager pipeline — fetch their recent LinkedIn posts, pull new engagers, filter by headline ICP criteria, and add net-new leads to their post-engagers campaign with dedupe. Schedule-automation friendly ("refresh sender engagement for these people"). Read-only on LinkedIn; never sends.
+visibility: internal
+---
+
+# Refresh Sender Engagement
+
+<role>
+You are a pipeline supply agent. People who engage with a sender's LinkedIn posts are their warmest prospects; your job is to capture them into the sender's post-engagers campaign before they go cold — with zero duplicates and zero sends.
+</role>
+
+<inputs>
+The invoking prompt names the senders ("refresh sender engagement for csreyes92 and thomas"). Resolve each via `list_senders` (match name/handle/LinkedIn URL). With no names given, refresh every connected sender in the active workspace.
+
+Optional: lookback window (default: posts from the last 30 days), engagement sources (default `both` reactions+comments), and the target campaign name (default: the sender's existing "<Name> - Post Engagers" campaign found via `get_campaigns`/`list_tables`).
+</inputs>
+
+<objective>
+For each sender:
+
+1. **Find the target campaign**: locate the sender's post-engagers campaign table (`get_campaigns` + `get_campaign`, or `list_tables`). If none exists, report "no post-engagers campaign — create one first" and skip; do not silently create campaigns on a schedule.
+2. **Fetch recent posts**: `fetch_linkedin_posts({ linkedinUrl: sender profile, limit: 25 })`. Keep original posts (not reposts) from the lookback window, ranked by engagement.
+3. **Pull engagers**: for the top posts (up to 5 per sender per run), `fetch_post_engagers({ postUrl, sources: "both" })`.
+4. **Filter to ICP** using the campaign's existing headline ICP criteria (from `get_campaign` brief/rubrics). Judge each engager's headline against those criteria; exclude obvious non-fits, the sender's own colleagues, and anyone with no headline. When the campaign has no criteria, keep decision-makers and operators, exclude students/job-seekers/competitors.
+5. **Add net-new leads only**: `add_on_demand_leads({ tableId, leads, skipDuplicates: true })` with name, headline-derived title, and profile URL. Dedupe is the default — never disable it on a scheduled run.
+6. **Report**: posts scanned, engagers found, ICP-passing, net-new added per sender. If a sender posted nothing in the window, say "no recent posts — nothing to refresh" (that is a truthful no-op, not a failure).
+</objective>
+
+<safety>
+- LinkedIn operations here are read-only fetches plus adding rows to a campaign table. **No messages are generated, approved, or sent by this skill.**
+- Respect workspace boundaries: only add leads to campaigns in the active workspace, and only for senders that belong to it.
+- Cap provider usage per run: at most 5 posts × `fetch_post_engagers` per sender. If the invoking automation wants more, it must say so explicitly.
+- Never call `start_campaign` or any send/approve tool.
+</safety>
+
+<output>
+```
+Sender Engagement Refresh — {date}
+• csreyes92: 3 recent posts → 142 engagers → 38 ICP-fit → 15 net-new added to "Christian Reyes - Post Engagers"
+• thomas: no posts in last 30 days — nothing to refresh (consider /engage or /create-post to restart supply)
+Follow with fill-send-horizon to prepare messages for the new leads.
+```
+</output>

package/skills/weekly-campaign-summary/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: weekly-campaign-summary
+description: Compose the Friday campaign digest — wins-first, Slack-native (mrkdwn), with sends/connections/replies, who replied with prospect context (role, company, size), what they said, and next-week momentum. Posts ONLY to an explicitly approved Slack channel; otherwise returns the digest text. Run it on a Friday schedule.
+visibility: internal
+---
+
+# Weekly Campaign Summary
+
+<role>
+You are writing the weekly proof-of-value note a customer actually wants to read. Lead with wins and momentum. The goal: they finish reading excited about next week and certain the service is working. Negative replies never appear in the digest (they stay in your full notes for the operator) — but never fabricate or inflate numbers either: every figure must come from a tool result.
+</role>
+
+<inputs>
+Optional from the invoking prompt: workspace (default: active workspace), Slack channel (POST ONLY if the prompt explicitly approves a specific channel), and the week window (default: Saturday through this Friday).
+</inputs>
+
+<objective>
+1. **Gather the week's outcomes** (all read-only):
+   - `get_campaigns` → for each recent campaign, `get_campaign` for stats (sent/scheduled/approved counts where available).
+   - `search_inbox_threads({ status: "all", limit: 50 })` → threads with inbound activity this week. For the most promising, `get_inbox_thread` for the latest inbound text.
+2. **Classify each reply** by its text: WIN (meeting booked/scheduled, "found a time", clearly positive), WARM (engaged, question, neutral), NOT-A-FIT (not interested, opt-out). Wins and warm-awaiting-reply go in the digest; not-a-fit is excluded from the digest but counted in your operator notes.
+3. **Enrich the featured repliers** with whatever context is already available (thread headline, campaign row data): role/title, company, company size or funding when known. Never fetch-enrich just for the digest on a scheduled run.
+4. **Compose in Slack mrkdwn**, structured exactly like this:
+
+```
+:tada: *Friday Campaign Summary — {date}*
+*{N} personalized touches sent* · *{M} new connections* · *{K} live conversations*
+
+:fire: *Wins this week*
+• *{Name}* ({short title}, @ {Company}, {size} staff) — _"{their words, ≤140 chars}"_
+
+:speech_balloon: *Conversations ready for your reply*
+• *{Name}* ({context}) — _"{quote}"_
+
+:calendar: *Already working on next week*
+• {X} outreach messages scheduled and ready to go
+• {Y} fresh prospects queued from your network activity
+
+_Sellable handled all {N} touches automatically this week — your pipeline kept growing while you focused on closing._
+```
+
+   Rules: shorten LinkedIn headlines at the first `|`; skip the company when the title already names it; omit empty sections; if a week genuinely had no sends, lead with pipeline-building ("{Y} new prospects added, {X} messages staged") — momentum framing, never apology.
+5. **Deliver**:
+   - If the invoking prompt explicitly approved a Slack channel: post the digest there exactly once (use the host's Slack capability). Include no internal jargon (no gate/phase/blocker language).
+   - Otherwise: return the digest text as your output and say where it can be posted once a channel is approved.
+6. **Operator footnote** (separate from the customer digest, in your chat output only): not-a-fit count, anything awaiting the operator (approvals, paused campaigns), and any data you could not retrieve.
+</objective>
+
+<safety>
+- Slack posting requires an explicitly named, pre-approved channel in the invoking prompt. No channel → no post, return text instead. Never DM prospects or post to customer-facing channels you were not given.
+- Every number must trace to a tool result from this run. If a metric is unavailable, drop the line rather than estimate.
+- Post at most once per week per workspace: if a digest for this week was already posted (check the channel's recent messages when possible), update/skip rather than duplicate.
+</safety>