@sellable/mcp 0.1.336 → 0.1.338

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

@@ -1,72 +1,33 @@
 ---
 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. Fill horizon requests load the skill-led refill workflow; fill_campaign_horizon remains evergreen-only lower-level execution.
 visibility: internal
+allowed-tools:
+  - mcp__sellable__get_subskill_prompt
+  - mcp__sellable__resolve_campaign_fill_route
+  - mcp__sellable__get_campaign_refill_state
+  - 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.
-</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)
-
-The fill order is **stored workspace state**, 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.
-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.
-
-Fill mechanics, whatever the source of the order:
-
-- **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.
-- **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.
-- **Report per lane** so the operator can see the waterfall working:
+This is a compatibility alias. For plain operator language such as "fill",
+"refill sends", "max out sends", "load everyone up", or "fill horizon sends",
+load the canonical workflow first:
 
+```text
+get_subskill_prompt({ subskillName: "refill-sends-workflow" })
 ```
-csreyes92 waterfall (stored order): Post Engagers filled 4/4 (horizon met — lower lanes skipped)
-thomas waterfall (stored order): Post Engagers 1/4 (source thin) → Shared Signal Discovery 3/3 remaining
-```
-</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>
+Then follow the workflow:
 
-<output>
-One compact report:
+1. Call `resolve_campaign_fill_route`.
+2. Call `get_campaign_refill_state` for the exact selected target.
+3. Treat public targets as regular campaigns or evergreen campaigns only.
+4. Stop on `unsupported_campaign_type` for internal direct campaign tables.
+5. Use `fill_campaign_horizon` only after route and refill-state evidence prove
+   the target is an evergreen campaign.
 
-```
-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>
+Do not start or launch campaigns. Do not raw-write scheduler fields. Do not
+claim scheduled success without rereading scheduler-owned cells with non-null
+`scheduledFor`.

package/skills/refill-sends/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: refill-sends
+description: Plan regular campaign and evergreen campaign send refill work through the skill-led refill workflow.
+visibility: public
+allowed-tools:
+  - mcp__sellable__get_subskill_prompt
+  - mcp__sellable__search_subskill_prompts
+  - mcp__sellable__resolve_campaign_fill_route
+  - mcp__sellable__get_campaign_refill_state
+  - mcp__sellable__fill_campaign_horizon
+  - mcp__sellable__get_campaign
+  - mcp__sellable__get_campaign_message_preparation_status
+  - mcp__sellable__start_campaign_message_preparation
+  - mcp__sellable__cancel_campaign_message_preparation
+  - mcp__sellable__import_leads
+  - mcp__sellable__wait_for_lead_list_ready
+  - mcp__sellable__confirm_lead_list
+  - mcp__sellable__search_signals
+  - mcp__sellable__fetch_post_engagers
+  - mcp__sellable__search_sales_nav
+  - mcp__sellable__lookup_sales_nav_filter
+  - mcp__sellable__search_prospeo
+  - mcp__sellable__search_prospeo_companies
+  - mcp__sellable__confirm_prospeo_company_accounts
+  - mcp__sellable__load_csv_linkedin_leads
+  - mcp__sellable__load_csv_domains
+  - mcp__sellable__list_dnc_entries
+  - mcp__sellable__load_csv_dnc_entries
+  - mcp__sellable__get_rows
+  - mcp__sellable__get_rows_minimal
+  - mcp__sellable__get_table_rows
+---
+
+# Refill Sends
+
+Use this public wrapper for plain operator requests such as "fill", "refill sends",
+"max out sends", "load everyone up", or "fill horizon sends".
+
+Load the internal workflow prompt before taking any operational step:
+
+```text
+get_subskill_prompt({ subskillName: "refill-sends-workflow" })
+```
+
+Then follow that workflow exactly. The default path is read-only research:
+resolve the route, read target refill state, report the next safe step, and stop
+before mutation unless the user has explicitly approved the exact workspace,
+campaign/table/source ids, caps/dates, approval mode, expected side effects,
+and stop/rollback condition.
+
+Public concepts are regular campaign and evergreen campaign. Internal direct
+campaign types are unsupported refill targets. `fill_campaign_horizon` is only a
+legacy evergreen-only lower-level primitive after route and refill-state
+evidence proves an evergreen target.

package/skills/refill-sends-workflow/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: refill-sends-workflow
+description: Internal skill-led refill sends workflow for regular campaigns and evergreen campaigns.
+visibility: internal
+allowed-tools:
+  - mcp__sellable__resolve_campaign_fill_route
+  - mcp__sellable__get_campaign_refill_state
+  - mcp__sellable__fill_campaign_horizon
+  - mcp__sellable__get_campaign
+  - mcp__sellable__get_campaign_message_preparation_status
+  - mcp__sellable__start_campaign_message_preparation
+  - mcp__sellable__cancel_campaign_message_preparation
+  - mcp__sellable__import_leads
+  - mcp__sellable__wait_for_lead_list_ready
+  - mcp__sellable__confirm_lead_list
+  - mcp__sellable__search_signals
+  - mcp__sellable__fetch_post_engagers
+  - mcp__sellable__search_sales_nav
+  - mcp__sellable__lookup_sales_nav_filter
+  - mcp__sellable__search_prospeo
+  - mcp__sellable__search_prospeo_companies
+  - mcp__sellable__confirm_prospeo_company_accounts
+  - mcp__sellable__load_csv_linkedin_leads
+  - mcp__sellable__load_csv_domains
+  - mcp__sellable__list_dnc_entries
+  - mcp__sellable__load_csv_dnc_entries
+  - mcp__sellable__get_rows
+  - mcp__sellable__get_rows_minimal
+  - mcp__sellable__get_table_rows
+---
+
+# Refill Sends Workflow
+
+Default mode is read-only research. This workflow decides the next safe refill
+step in the parent thread; backend tools remain narrow route, state, source,
+prep, readiness, and evergreen primitives.
+
+## Entry
+
+Plain phrases that enter here include "fill", "refill sends", "max out sends",
+"load everyone up", and "fill horizon sends".
+
+1. Call `resolve_campaign_fill_route` first. Use `intent:"plain"` for generic
+   fill/load language, `intent:"active"` only when the user explicitly narrowed
+   to active regular campaigns, and `intent:"evergreen"` only when the user
+   explicitly asked for evergreen or horizon work.
+2. Pick exact ids from the resolver result. Do not use campaign names or table
+   names as target identifiers.
+3. Call `get_campaign_refill_state` for the selected `campaignId` or `tableId`.
+   This must be the next target-specific research primitive.
+4. Classify the target from refill state:
+   - regular campaign: campaign-backed workflow table with normal source,
+     sequence, senders, and send/refill stages.
+   - evergreen campaign: managed always-on lane with current source evidence.
+   - `unsupported_campaign_type`: internal direct campaign table; report the
+     blocker and stop without mutation.
+
+## Research Checklist
+
+Use the refill-state response as the current facts receipt:
+
+- campaign status/current step, workflow table id, table config type, and public
+  type;
+- selected source list/provider identity, source id, target prospect gap,
+  cursor/inventory state, dedupe/DNC/provider exclusions, good-prospect yield,
+  scan/import caps, and proof;
+- sender ids, healthy senders, disconnected senders, and daily capacity;
+- row/stage counts: source available, rows, enriched, passed, generated,
+  approved, ready to schedule, scheduled;
+- active message prep job;
+- scheduler-owned scheduled counts by date/action from cells with non-null
+  `scheduledFor`;
+- `freshness.stateHash` and exact campaign/table/workspace ids.
+
+Empty or unsafe states stop with the blocker: no fillable target, missing or deleted campaign,
+missing table, paused/archive campaign, zero sender capacity, zero source candidates,
+zero viable rows, no approved/preparable rows, active prep job, awaiting
+scheduler, or unsupported direct campaign type.
+
+## Regular Campaign Decision
+
+For regular campaign workspaces, rank regular campaigns from route and
+`get_campaign_refill_state` evidence. Choose the best existing refill target.
+Do not create side campaigns, warm-post-engager side campaigns, on-demand campaigns,
+or unrelated campaigns as the default answer to a fill request.
+
+When the best regular campaign is source-exhausted, recommend same-campaign source-ladder replenishment.
+Keep `selectedLeadListId` source identity distinct
+from the campaign `workflowTableId`.
+
+Source replenishment choices:
+
+- existing source list reuse: append/confirm the existing source list when it
+  has enough eligible rows;
+- CSV path: load CSV profiles/domains, then import into the same campaign/source
+  path;
+- Sales Nav path: use Sales Nav lookup/search, then import selected prospects;
+- Prospeo path: use account/person search as appropriate, then import selected
+  prospects;
+- Signal Discovery path: search/select posts or engagers, import selected
+  source prospects into the same campaign/source-list path, then confirm
+  readiness.
+
+Before any source mutation, show exact approval evidence: workspace id,
+campaign id, workflow table id, source/provider id, source-list id when known,
+import caps, target dates/caps, dedupe/DNC/provider exclusion expectations, and
+expected row side effects. Then reread `get_campaign_refill_state`; if
+`freshness.stateHash` or exact ids changed, stop and ask for a fresh approval.
+
+After source import, call `wait_for_lead_list_ready` and `confirm_lead_list`
+with the source-list id and campaign id. Imports append to the existing
+campaign/source path; they must not reset campaign state, sequence, sender
+assignment, current step, or watch state. If provider auth, rate limit, timeout,
+partial import, duplicate-only import, DNC-only result, CSV parse failure,
+readiness timeout, or `confirm_lead_list` failure occurs, stop before prep and
+report the blocker/retry path.
+
+## Prep, Approval, And Scheduler Proof
+
+Existing rows normally move through enrichment/prep/approval using
+`start_campaign_message_preparation` and
+`get_campaign_message_preparation_status`. Standalone Generate Message is not the normal refill action;
+it is only for a manual/user-authored message path
+that requires it.
+
+Approval mode:
+
+- default is `approvalMode:"mark_ready"`, not approve;
+- use `approvalMode:"approve"` only when the user explicitly asks to approve
+  messages or schedule sends and has approved the exact bounded cohort;
+- never launch/start a campaign from refill.
+
+Before prep or approval mutation, reread `get_campaign_refill_state` and compare
+`freshness.stateHash`, campaign id, table id, workspace id, source id, and caps.
+If they changed, stop. A second concurrent refill run must see the first run's
+import/prep state on reread and avoid duplicate work.
+
+Scheduled success requires a post-action reread proving scheduler-owned cells
+with non-null `scheduledFor`. Prepared, approved, and ready-to-schedule rows are
+intermediate states; report them as awaiting scheduler unless scheduled cells
+are present.
+
+## Evergreen Campaign Discipline
+
+`fill_campaign_horizon` is a legacy evergreen-only lower-level primitive. Call it
+only after `resolve_campaign_fill_route` and `get_campaign_refill_state` prove an
+evergreen campaign target.
+
+For evergreen campaigns, do not advance down the source ladder while the current source can produce enough good prospects.
+The current source is exhausted, or
+unable to produce enough good prospects, only when evidence includes source id,
+target prospect gap, cursor/inventory state, dedupe/DNC/provider exclusions,
+good-prospect yield, and scan/import caps. If that proof is missing, continue
+the current source or ask for more research instead of walking the ladder.
+
+## Hard Safety Rules
+
+- Never call start or launch tools.
+- Never raw-write `scheduledFor`, `scheduledAt`, scheduled status, or sender
+  assignment fields.
+- Never expose internal direct campaign types as an operator refill path.
+- Never claim scheduled success without rereading scheduler-owned cells with
+  non-null `scheduledFor`.
+- No mutation in production unless Christian explicitly approves exact
+  workspace, campaign/table ids, source/action ids, caps/dates, approval mode,
+  expected side effects, and rollback/stop condition.
+
+## Report
+
+Report the selected target, target type, source state, blockers, exact next
+primitive, approval required, and the freshness hash used. Say explicitly that
+nothing was launched and nothing was sent.

package/skills/research/config.json

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