@sellable/mcp 0.1.335 → 0.1.336

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

@@ -1,6 +1,6 @@
 ---
 name: create-evergreen-campaigns
-description: Reconcile a sender team's evergreen campaigns — create-or-reuse the standing campaigns (per-sender post engagers + shared signal/cold lanes) idempotently, and when asked for customer-ready/full setup, complete each customer-visible campaign to paused send review with brief, rows, generated review messages, one approval gate row, and sequence. Never duplicates, never launches.
+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
 ---
 
@@ -10,49 +10,21 @@ visibility: internal
 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. This skill never launches campaigns; customer-visible
-completion stops at paused send review.
+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`.
 
-If the invoking prompt says scheduled, automation, cron, heartbeat, fresh-thread,
-run without user input, or similar, run in **automation mode**:
-
-- Do not ask the user to confirm templates, delivery format, or sample output.
-- Reconcile structure and record any template/config polish as `created`,
-  `reused`, `repaired`, `flagged`, or `blocked`.
-- Choose the automation depth from the invoking prompt:
-  - **Structure-only reconcile** is for heartbeat prompts that only say to
-    ensure slots exist. It may create/reuse shells and apply metadata repairs,
-    but it does not create rows, generate messages, approve rows, or attach new
-    send work.
-  - **Customer-visible completion** is required when the prompt says full
-    campaign, customer-ready, send-review-ready, went through
-    `$sellable:create-campaign`, fill out, approve one, only needs enrich and
-    approve more, or similar. For every dashboard campaign card in that mode,
-    mirror the create-campaign completion path: brief -> source rows -> filter
-    decision -> Message Drafting -> first review batch -> generated messages ->
-    sender/settings validation -> recommended sequence -> `currentStep:"send"`.
-    This mode may create/copy bounded rows, generate review messages, approve
-    exactly one quality-valid route-proof row when needed, and attach the
-    recommended sequence, but it still must not launch campaigns, schedule
-    sends, send messages, or spend paid InMail.
-
-If the invoking prompt explicitly asks for interactive message polish or sample
-proof, run in **interactive polish mode** and use the confirmation/sample steps
-below.
-
 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 warm-signal campaign lane across senders
-3. **`<Workspace/Team> - Shared Cold Fallback`** — one shared cold/fallback campaign lane across senders
+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` + `get_campaign_waterfall` in the active workspace. Treat `list_tables` and the managed waterfall as authoritative for older managed slots; `get_campaigns` is a recent campaign page and may miss canonical evergreen lanes. Match existing campaigns/tables/waterfall slots to the plan by name (case-insensitive, ignore suffixes like "(Copy)") and stored slot identity. `list_tables.campaignStatus` and `list_tables.dashboardBucket` are part of the identity check: a matching `ARCHIVED` table/campaign is not a plain `REUSE`. If it is the canonical prod slot and the invocation explicitly allows dashboard visibility repair, repair it to `PAUSED`; otherwise mark it `flagged`/`blocked` and do not create a duplicate. A matching non-archived campaign/table/waterfall slot = REUSE; record it and move on. Never create a second campaign for a slot that already has one in any of those inventories.
+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:
@@ -70,76 +42,24 @@ Default evergreen plan per workspace (override only if the prompt specifies diff
      - **InMail lanes can never be multiline**: an InMail is one message and the recipient must reply before anything else can be sent. InMail-bound templates must read as one cohesive message — declare `Delivery format: single message (InMail — no follow-up until reply)` and never structure the copy to depend on multi-message pacing.
 
    - The sequence is auto-selected by sender tier; do not hand-author sequence templates here. Never select a paid-InMail template.
-3. **Customer-Visible Completion Contract**: a named evergreen lane that appears
-   as a campaign card or campaign-backed table is not done when the shell exists.
-   It is done only when the customer can open the campaign and land on final
-   send review with all setup state present:
-   - `currentStep:"send"`.
-   - The linked workflow table has `campaignStatus:"PAUSED"`; `ACTIVE` means
-     already launched and must be reported separately, and `ARCHIVED` must be
-     repaired only when the prompt explicitly allows dashboard visibility repair.
-   - A full campaign brief exists, including delivery format, token rules,
-     hard avoids, source-use rules, and the approved first-message template.
-   - A source/list decision has been resolved and campaign rows are loaded. If
-     there is no approved source or no rows can be copied, report `blocked` with
-     the missing source detail; do not call the campaign complete.
-   - The filter step is resolved: either saved/applied filters are present, or
-     the campaign explicitly skipped filters. Do not leave customer-visible
-     campaigns at `filter-choice`, `filter-rules`, or `apply-icp-rubric` and
-     report success.
-   - Message Drafting has run from the current campaign/table basis, using the
-     create-campaign message prompt/assets and validation gate. Updating
-     `currentStep:"messages"` is not proof. Parent-thread handwritten copy is
-     not a substitute.
-   - The first review batch exists and at least 3 review rows have generated
-     messages from the approved brief. If fewer than 3 usable rows exist, report
-     the actual count and why.
-   - At least one generated row is approved as a route-proof gate. If zero rows
-     are approved and the prompt explicitly asked for full/customer-ready
-     completion, approve exactly one quality-valid generated row. If one or more
-     rows are already approved, do not add more approvals during evergreen
-     completion. Never broad approve all rows.
-   - The recommended non-paid sequence is attached, and the watched campaign is
-     on Send. Use `attach_recommended_sequence({ campaignId, currentStep:"send" })`
-     when a safe attach is needed. Existing sequence proof may come from
-     `SEQUENCE_EXISTS`; do not replace it without explicit user confirmation.
-   - No scheduled, queued outbound, sent outbound, campaign launch, or paid
-     InMail spend is created by this skill.
-4. **Verify each slot** after create/reuse/repair:
-   - `get_campaign` shows the campaign exists, remains unlaunched, and has the expected workflow table.
-   - Builder truth must match dashboard truth. `currentStep:"running"` is valid only when the linked table has `campaignStatus:"ACTIVE"`. For a `PAUSED` or `ARCHIVED` campaign/table, repair or flag stale `currentStep:"running"` back to launch review (`send` / review-ready) before reporting the slot done. Never call `start_campaign` just to make a stale `running` step true.
-   - Send/action lanes such as Post Engagers have a sequence attached. Use `list_tables({ hasSequence: true })` as a quick cross-check, but do not treat that filter as the only proof. If the canonical campaign/table is missing from the sequence-filtered table list but a safe `attach_recommended_sequence({ campaignId })` repair/precheck returns `SEQUENCE_EXISTS`, record `sequence attached (verified by SEQUENCE_EXISTS precheck; list_tables.hasSequence mismatch)` and do not retry.
-   - Only use `attach_recommended_sequence({ campaignId })` for a send-lane sequence repair/precheck when the target is a canonical prod slot and the invoking prompt allows sequence repair. Call it at most once without `confirmed`; a successful response is `repaired`, and `SEQUENCE_EXISTS` is non-mutating proof that a sequence already exists. Never call `attach_recommended_sequence` or `attach_sequence` with `confirmed:true` in evergreen automation unless the user explicitly asks to replace an existing sequence.
-   - Do not report `source-only/no sequence expected` for any named evergreen
-     campaign that appears in Campaigns, has a CampaignOffer ID, or is backed by
-     a campaign dashboard table. Shared Signal Discovery and Shared Cold
-     Fallback campaign cards are still customer-visible campaigns and must
-     satisfy the Customer-Visible Completion Contract when the prompt asks for
-     full/customer-ready completion.
-   - Source-only shared lanes are allowed only for explicitly internal waterfall
-     inventory objects that are not represented as campaign cards. For those
-     internal-only objects, verify the active waterfall linkage, table ID,
-     source type, and priority, and label them `internal source pool` rather
-     than treating them as completed campaigns.
-   - Post Engagers lanes are sender-owned source lanes. The selected/source LinkedIn posts must be authored by that exact sender (for example, Thomas post-engager source posts must visibly be Thomas-authored posts). If selected/source posts include another person or company author, mark the slot `blocked`/`flagged` for source repair; do not scrape/import engagers or report completion until the source is sender-owned. Shared Signal Discovery lanes are the only evergreen lanes allowed to mix authors.
-5. **Interactive polish mode only: confirm the message template with the user — and check it reads chat-native.** Show the exact first-message template each created campaign's brief carries and ask the user to confirm or adjust it before moving on. Because DM copy may send paragraph-by-paragraph (each blank-line block becomes its own message), every paragraph must read like something a human literally typed as a separate chat message:
+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. **Confirm the message template with the user — and check it reads chat-native.** Show the exact first-message template each created campaign's brief carries and ask the user to confirm or adjust it before moving on. Because DM copy may send paragraph-by-paragraph (each blank-line block becomes its own message), every paragraph must read like something a human literally typed as a separate chat message:
    - **No letter punctuation.** `Hey {{first_name}}` — never `Hey {{first_name}},` (nobody types a trailing comma and hits send). No `Dear`, no sign-offs, no `Best,`.
    - Each paragraph stands alone as a message — short, lowercase-casual is fine, sentence fragments are fine.
    - No paragraph should depend on letter formatting (no "As I mentioned above" referencing layout).
    If the template violates these, propose the chat-native version and ask; on approval, update the brief via `update_campaign_brief` and show the final version.
 
    **Also confirm the delivery format and keep config in sync.** Ask the user whether DM lanes should send multiline (paragraph-per-message) or as a single message. Record the answer as the brief's `Delivery format:` line, and when multiline is chosen, set `actionConfig.sendEachParagraphAsMessage: true` on that campaign's `send_dm` column via `update_column` (config edits run no cells and nothing sends from unlaunched campaigns). Never set the paragraph-split flag on InMail columns — the option does not apply to InMail.
-6. **Interactive polish mode only: prove the template on one real row.** For ONE campaign that has at least one lead row (add one via `add_on_demand_leads` if every lane is empty and the user provides/approves a test lead), generate a message for exactly one row (`queue_campaign_cells` with `columnRole: "generateMessage"`, `rowSelector: { type: "reviewBatch", limit: 1 }` or the single row's ID), wait for it, then show the user the generated message next to the template — AND show how it would split if paragraph-per-message sending is enabled (list each paragraph as `msg 1:`, `msg 2:`, …) so the user confirms each one reads like a real typed message. Check alignment: tone, structure, no internal vocabulary, correct token substitution, no letter punctuation. Do NOT approve the row or generate for more rows — one sample only.
-7. **Automation mode template/config audit**: inspect existing send-lane briefs for a `Delivery format:` line and chat-native warm template. If a send lane is missing the line and the prompt allows cleanup, update only the campaign brief metadata with the safest default for that lane (`Delivery format: single message (LinkedIn DM; line breaks remain inside one generated message; no follow-up until reply)`). If cleanup is not allowed, flag it. Do not generate a sample row in automation mode unless the invocation explicitly asks for sample proof. In structure-only automation, do not generate a sample row unless the invocation explicitly asks for sample proof. In customer-visible completion, follow the Customer-Visible Completion Contract instead.
-8. **Report the reconcile plan and result** — every slot tagged `reused`, `created`, `repaired`, `flagged`, or `blocked`, plus template/sample details only when that mode ran:
+5. **Prove the template on one real row.** For ONE campaign that has at least one lead row (add one via `add_on_demand_leads` if every lane is empty and the user provides/approves a test lead), generate a message for exactly one row (`queue_campaign_cells` with `columnRole: "generateMessage"`, `rowSelector: { type: "reviewBatch", limit: 1 }` or the single row's ID), wait for it, then show the user the generated message next to the template — AND show how it would split if paragraph-per-message sending is enabled (list each paragraph as `msg 1:`, `msg 2:`, …) so the user confirms each one reads like a real typed message. Check alignment: tone, structure, no internal vocabulary, correct token substitution, no letter punctuation. Do NOT approve the row or generate for more rows — one sample only.
+6. **Report the reconcile plan and result** — every slot tagged `reused` or `created`, plus the confirmed template and the sample message:
 
 ```
 Evergreen Reconcile — {date}
-• Christian Reyes - Post Engagers: reused (send review ready; 18 rows, 3 generated, 1 approved gate row, sequence attached, paused)
-• Thomas Nobbs - Post Engagers: reused (send review ready; 8 rows, 3 generated, 1 approved gate row, sequence attached, paused)
-• Sellable.dev - Shared Signal Discovery: repaired (send review ready; 50 rows, 3 generated, 1 approved gate row, sequence attached, paused)
-• Sellable.dev - Shared Cold Fallback: created (send review ready; 50 rows, 3 generated, 1 approved gate row, sequence attached, paused)
-All campaigns remain unlaunched. Next: enrich/approve more rows when you want more items ready to schedule.
+• 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>
 

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

@@ -1,13 +1,13 @@
 ---
 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: 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 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.
+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>
@@ -23,16 +23,11 @@ Optional inputs: `targetPreparedMessages` (default: leave unset for the adaptive
 <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.
+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>
@@ -59,11 +54,9 @@ 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.
-- 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.
+- 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>
@@ -71,9 +64,9 @@ One compact report:
 
 ```
 Fill Send Horizon — {date}
-• {Campaign A}: scheduled {s}/{target} for the horizon ({r} ready, {p} prepared, {a} approved) — {state}
+• {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 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.
+Next operator action: approve {m} messages in {Campaign A}
+Nothing was sent or launched; campaigns remain in their current status.
 ```
 </output>

package/dist/tools/campaign-horizon-fill.d.ts

@@ -1,93 +0,0 @@
-type FillCampaignHorizonInput = {
-    action: "audit" | "apply";
-    campaignId: string;
-    tableId?: string;
-    stateRevision?: string;
-    excludedPostIds?: string[];
-    excludedPostUrls?: string[];
-    excludedAuthorProfileUrls?: string[];
-    excludedAuthorNames?: string[];
-    targetPreparedMessages?: number;
-    maxRowsToCheck?: number;
-    batchSize?: number;
-};
-export declare const campaignHorizonFillToolDefinitions: {
-    name: string;
-    description: string;
-    inputSchema: {
-        type: string;
-        properties: {
-            action: {
-                type: string;
-                enum: string[];
-                description: string;
-            };
-            campaignId: {
-                type: string;
-                description: string;
-            };
-            tableId: {
-                type: string;
-                description: string;
-            };
-            stateRevision: {
-                type: string;
-                description: string;
-            };
-            excludedPostIds: {
-                type: string;
-                items: {
-                    type: string;
-                };
-                maxItems: number;
-                description: string;
-            };
-            excludedPostUrls: {
-                type: string;
-                items: {
-                    type: string;
-                };
-                maxItems: number;
-                description: string;
-            };
-            excludedAuthorProfileUrls: {
-                type: string;
-                items: {
-                    type: string;
-                };
-                maxItems: number;
-                description: string;
-            };
-            excludedAuthorNames: {
-                type: string;
-                items: {
-                    type: string;
-                };
-                maxItems: number;
-                description: string;
-            };
-            targetPreparedMessages: {
-                type: string;
-                minimum: number;
-                maximum: number;
-                description: string;
-            };
-            maxRowsToCheck: {
-                type: string;
-                minimum: number;
-                maximum: number;
-                description: string;
-            };
-            batchSize: {
-                type: string;
-                minimum: number;
-                maximum: number;
-                description: string;
-            };
-        };
-        required: string[];
-        additionalProperties: boolean;
-    };
-}[];
-export declare function fillCampaignHorizon(input: FillCampaignHorizonInput): Promise<unknown>;
-export {};

package/dist/tools/campaign-horizon-fill.js

@@ -1,92 +0,0 @@
-import { getApi } from "../api.js";
-async function postHorizonFill(body) {
-    const api = getApi();
-    return api.post("/api/v3/mcp/campaign-horizon-fill", body);
-}
-export const campaignHorizonFillToolDefinitions = [
-    {
-        name: "fill_campaign_horizon",
-        description: "Audit or apply a bounded CampaignOffer horizon fill from Signal Discovery/source lead-list rows. Use audit first to get stateRevision, then apply with that stateRevision. Apply imports at most 300 eligible non-excluded source rows, starts bounded message preparation in approval mode, skips rows from excluded posts/authors, and does not start, launch, send, or directly write scheduledFor. Prepared/approved rows are intermediate only; report scheduled completion only after re-reading scheduler-owned scheduled cells with non-null scheduledFor.",
-        inputSchema: {
-            type: "object",
-            properties: {
-                action: {
-                    type: "string",
-                    enum: ["audit", "apply"],
-                    description: 'Use "audit" to inspect counts/receipt without writes. Use "apply" with the audit stateRevision to import/prep.',
-                },
-                campaignId: {
-                    type: "string",
-                    description: "CampaignOffer.id for the campaign to fill.",
-                },
-                tableId: {
-                    type: "string",
-                    description: "Optional workflow table id. Must match the campaign workflowTableId when provided.",
-                },
-                stateRevision: {
-                    type: "string",
-                    description: "Required for apply. Copy from the immediately preceding audit receipt.",
-                },
-                excludedPostIds: {
-                    type: "array",
-                    items: { type: "string" },
-                    maxItems: 100,
-                    description: "Exact SignalSearchPost ids to exclude from import/preparation.",
-                },
-                excludedPostUrls: {
-                    type: "array",
-                    items: { type: "string" },
-                    maxItems: 100,
-                    description: "Exact LinkedIn post URLs to exclude from import/preparation.",
-                },
-                excludedAuthorProfileUrls: {
-                    type: "array",
-                    items: { type: "string" },
-                    maxItems: 100,
-                    description: "Exact LinkedIn author profile URLs whose source rows should be excluded.",
-                },
-                excludedAuthorNames: {
-                    type: "array",
-                    items: { type: "string" },
-                    maxItems: 25,
-                    description: "Exact author names to exclude only when they resolve unambiguously inside campaign Signal Discovery posts.",
-                },
-                targetPreparedMessages: {
-                    type: "number",
-                    minimum: 1,
-                    maximum: 300,
-                    description: "Prepared/approved message target for the first pass. Backend caps this at 300.",
-                },
-                maxRowsToCheck: {
-                    type: "number",
-                    minimum: 1,
-                    maximum: 300,
-                    description: "Hard first-pass row cap. Backend caps import and prep at 300 rows.",
-                },
-                batchSize: {
-                    type: "number",
-                    minimum: 1,
-                    maximum: 100,
-                    description: "Preparation batch size. Backend caps newly checked rows at 100 per batch.",
-                },
-            },
-            required: ["action", "campaignId"],
-            additionalProperties: false,
-        },
-    },
-];
-export function fillCampaignHorizon(input) {
-    return postHorizonFill({
-        action: input.action,
-        campaignId: input.campaignId,
-        tableId: input.tableId,
-        stateRevision: input.stateRevision,
-        excludedPostIds: input.excludedPostIds,
-        excludedPostUrls: input.excludedPostUrls,
-        excludedAuthorProfileUrls: input.excludedAuthorProfileUrls,
-        excludedAuthorNames: input.excludedAuthorNames,
-        targetPreparedMessages: input.targetPreparedMessages,
-        maxRowsToCheck: input.maxRowsToCheck,
-        batchSize: input.batchSize,
-    });
-}

package/skills/research/config.json

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