@sellable/mcp 0.1.335 → 0.1.337

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

@@ -1,48 +1,63 @@
 ---
 name: fill-send-horizon
-description: Fill campaigns' next N-day send horizon through product-native enrichment, message prep, exact-row approval, and scheduler-owned scheduling proof. Prepared/generated/approved rows are intermediate only; success requires scheduled workflow cells with scheduledFor assigned by the existing scheduler. Never launches campaigns, never spends paid InMail.
+description: Compatibility alias for refill-sends. Plain fill, refill sends, max out sends, load everyone up, and fill horizon sends now route to refill_campaign_sends plan mode first. Legacy fill_campaign_horizon remains evergreen-only lower-level audit/apply.
 visibility: internal
+allowed-tools:
+  - mcp__sellable__refill_campaign_sends
+  - mcp__sellable__resolve_campaign_fill_route
+  - mcp__sellable__fill_campaign_horizon
 ---
 
 # 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 actual scheduled workflow-table action cells with `scheduledFor` assigned by the existing scheduler path. Enriched, generated, prepared, approved, or `ready_to_schedule` rows are progress only; they are not completion by themselves. Never launch a campaign or send anything yourself.
+This is a compatibility alias. For plain operator language, use the new refill
+command first: `refill_campaign_sends({ mode: "plan", intent: "plain" })`.
+The word "horizon" means send window. Do not use `fill_campaign_horizon` as the
+generic regular-campaign fill path.
 </role>
 
 <inputs>
-The invoking prompt (often a scheduled automation) names the targets. Accept any of:
+The invoking prompt (often a scheduled automation) names the targets or gives a
+plain fill request. Route before acting:
 
-- 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
+- Plain fill/load requests ("fill campaigns", "load everyone up", "fill send horizon") — first call `refill_campaign_sends({ mode: "plan", intent: "plain" })`.
+- If no `--yolo`, report the plan and stop.
+- If `--yolo`, call plan first, then apply only with the returned `planRevision` and selected `actionIds`.
+- If `refill_campaign_sends` is unavailable in an older install, use `resolve_campaign_fill_route` and read-only diagnostics only, then stop before mutation.
 
 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, campaign status, sender IDs, current stats, and scheduled/ready/approved/prepared counts where the tool exposes them. Skip and report any campaign whose table is ARCHIVED.
-2. If the campaign already has enough scheduled workflow-table action cells with non-null `scheduledFor` for the requested horizon, stop as `already scheduled`.
-3. If there are eligible rows but the horizon is not scheduled, use the product-native fill/prep tools only on the bounded target cohort:
-   - Prefer `fill_campaign_horizon({ action: "audit" })` then `fill_campaign_horizon({ action: "apply", stateRevision })` when the campaign has a source lead list / Signal Discovery source and needs import plus message prep.
-   - Use `start_campaign_message_preparation({ campaignId })` when rows already exist and only enrichment/rubric/message prep/approval readiness is needed.
-   - Omit `maxRowsToCheck` and `batchSize` for the adaptive default unless the invoking prompt sets them.
-4. Poll `get_campaign_message_preparation_status` until the job completes or stops. Read `progress.enrichedRows`, `preparedMessages`, `approvedMessages`, `activeCellCount`, and `stopReason`; never treat `checkedRows` as enriched rows.
-5. After any prep/approval work, re-read campaign/table state. Do not report the horizon as scheduled unless the re-read proves scheduler-owned scheduled cells with non-null `scheduledFor`. If only prepared/approved/ready cells exist, report the exact state as `prepared/approved/ready - awaiting scheduler`, not complete.
-6. 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.
-7. Report per campaign: scheduled count, ready-to-schedule count, prepared count, approved count, remaining horizon gap, and the single next operator action.
+Route result handling:
+
+1. If `refill_campaign_sends` returns regular campaigns, report the ranked plan.
+2. If it returns evergreen campaigns, report the current-source audit and any legacy evergreen send-window subplan.
+3. If it returns blockers, report them and stop.
+4. If `--yolo` is approved, apply only selected immutable actions from the plan.
+
+For each active campaign target:
+
+1. Confirm workspace, `workflowTableId`, `campaignStatus:"ACTIVE"`, sender IDs, current stats, and scheduled/ready/approved/prepared counts where available. Skip and report PAUSED/DRAFT/ARCHIVED targets separately.
+2. Check `get_campaign_message_preparation_status({ campaignId, tableId })` first. If an active prep job exists for the same target, report it and do not start an overlapping job.
+3. If rows already exist, let `refill_campaign_sends` plan/apply the bounded preparation action. Do not call lower-level preparation manually unless the command is unavailable.
+4. If source is thin and the user asked to add/fill more leads, source fresh Signal Discovery/post engagement leads only into the same `campaignOfferId`/`campaignId` context. Do not create warm-post-engager side campaigns, on-demand campaigns, or unrelated campaigns.
+5. Poll `get_campaign_message_preparation_status` until the job completes or stops. Read `progress.enrichedRows`, `preparedMessages`, `approvedMessages`, `activeCellCount`, active prep blockers, and `stopReason`; never treat `checkedRows` as enriched rows.
+6. After any prep/approval work, re-read campaign/table state. Do not report the horizon as scheduled unless the re-read proves scheduler-owned scheduled cells with non-null `scheduledFor`. If only prepared/approved/ready cells exist, report the exact state as `prepared/approved/ready - awaiting scheduler`, not complete.
+7. Report appended rows, enriched rows, prepared messages, approved messages, ready-to-schedule rows, scheduler-owned scheduled cells, active preparation jobs, and sender-health blockers such as disconnected Sales Nav, deleted LinkedIn accounts, missing sequence state, or exhausted source rows as separate lines.
 </objective>
 
 <waterfall>
 ## Campaign hierarchy (waterfall order)
 
-The fill order is **stored workspace state**, not something each automation restates. Resolve it in this precedence:
+Evergreen/horizon fill order is **stored workspace state** returned by
+`resolve_campaign_fill_route`, not something each automation restates. Resolve
+it in this precedence:
 
-1. **Stored hierarchy (default)**: call `get_campaign_waterfall` first. It returns each waterfall (per sender or shared) with slots in stored priority order — campaign offer IDs included. Fill in that order.
+1. **Stored hierarchy (default)**: the resolver reads the stored managed waterfall and returns slots in priority order with campaign offer IDs included. Fill in that order.
 2. **Per-invocation override**: if the invoking prompt states an explicit order ("fill in this order: Signal Discovery, Post Engagers"), use it for this run only and say in the report that the stored order was overridden. To change the order durably, use `set_campaign_waterfall_order` — but only when the user/automation explicitly asks to change the hierarchy, never as a side effect of a fill run.
-3. **No stored hierarchy** (tool returns empty — evergreen reconcile hasn't run): fall back to the conventional order `<Sender> - Post Engagers` (warmest) → `Shared Signal Discovery` → `Shared Cold Fallback` (coldest), and note that running `create-evergreen-campaigns` will materialize a stored hierarchy.
+3. **No stored hierarchy**: resolver returns active targets or ask-create. Do not invent a conventional evergreen waterfall. Ask whether to create normal campaigns or evergreen campaigns only after `ask_create`.
 
 Fill mechanics, whatever the source of the order:
 

package/skills/refill-sends/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: refill-sends
+description: Plan and optionally apply bounded campaign send refill work. Plain fill, refill sends, max out sends, load everyone up, and fill send window requests route to refill_campaign_sends plan mode first. Apply requires --yolo, a fresh planRevision, and selected actionIds.
+visibility: internal
+allowed-tools:
+  - mcp__sellable__refill_campaign_sends
+  - mcp__sellable__resolve_campaign_fill_route
+  - mcp__sellable__fill_campaign_horizon
+  - mcp__sellable__get_campaign
+  - mcp__sellable__get_campaign_message_preparation_status
+---
+
+# Refill Sends
+
+Use this skill for plain operator requests such as "fill", "refill sends",
+"max out sends", "load everyone up", or "fill horizon sends".
+
+## Default Flow
+
+1. Call `refill_campaign_sends({ mode: "plan", intent: "plain" })`.
+2. Report the returned plan and stop when the user did not include `--yolo`.
+3. If the user included `--yolo`, still call plan first. Inspect blockers.
+4. Apply only by calling `refill_campaign_sends({ mode: "apply", yolo: true, planRevision, actionIds })` with action IDs copied from the fresh plan.
+
+Do not manually chain lower-level tools unless `refill_campaign_sends` is
+unavailable. In that fallback case, run read-only diagnostics only, then stop
+before mutation.
+
+## Public Concepts
+
+- Regular campaign: a campaign with a brief, source, sequence, senders, and a
+  campaign-backed workflow table.
+- Evergreen campaign: a managed always-on send-window lane.
+- Send window: the dates/capacity the operator wants kept full.
+
+Do not expose internal direct campaign types as an operator refill path. If the
+plan reports `unsupported_campaign_type`, report it and stop.
+
+## Safety Rules
+
+- Default mode is read-only plan.
+- Apply requires `yolo: true`, a fresh stable `planRevision`, and selected immutable `actionIds`.
+- Production yolo/apply requires explicit approval of workspace, campaign/table IDs, selected action IDs, caps/dates, and expected side effects.
+- Never create side campaigns.
+- Never call `start_campaign`, `start_on_demand_campaign`, or `start_direct_campaign`.
+- Never raw-write scheduled fields or sender assignment fields.
+- Scheduled success requires rereading scheduler-owned cells with non-null `scheduledFor`.
+- Generate Message normally happens through downstream propagation from enrichment/prep, not as a standalone action.
+
+## Evergreen Source Ladder
+
+For evergreen campaigns, do not move down the source ladder until the plan proves
+the current source is exhausted or cannot produce enough good prospects within
+configured caps. Required evidence includes source ID, target prospect gap,
+cursor/inventory state, dedupe/DNC/provider exclusions, good-prospect yield,
+and scan/import caps.
+