@sellable/mcp 0.1.336 → 0.1.337

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

@@ -1,43 +1,63 @@
 ---
 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.
+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 prepared, ready-to-send messages staged — without ever launching a campaign or sending 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, 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").
+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:
 
@@ -54,9 +74,11 @@ thomas waterfall (stored order): Post Engagers 1/4 (source thin) → Shared Sign
 <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.
+- Auto-approval is not scheduling. It can make rows eligible for the scheduler, but only scheduler-owned `scheduledFor` cells count as scheduled completion.
 - 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.
+- Do not write `WorkflowTableCell.scheduledFor` directly. Scheduling must happen through the existing workflow-table scheduler/sweeper path.
+- This skill fills readiness and verifies scheduling; 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>
@@ -64,9 +86,9 @@ One compact report:
 
 ```
 Fill Send Horizon — {date}
-• {Campaign A}: {n} messages prepared ({m} awaiting approval) — horizon staged through {date}
+• {Campaign A}: scheduled {s}/{target} for the horizon ({r} ready, {p} prepared, {a} approved) — {state}
 • {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.
+Next operator action: {approve messages | wait for scheduler | refresh source | launch separately if you intentionally want sends to go out}
+Nothing was sent or launched; campaigns remain in their current status. Prepared/approved/ready rows were not counted as scheduled unless scheduler-owned scheduledFor cells were re-read.
 ```
 </output>

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.
+

package/skills/research/config.json

@@ -0,0 +1,9 @@
+{
+  "parallelMode": "wide",
+  "agentCount": 6,
+  "maxToolCallsPerAgent": 2,
+  "senderMaxAgents": 2,
+  "senderMaxToolCallsPerAgent": 3,
+  "progressMode": true,
+  "debugMode": true
+}