@sellable/mcp 0.1.38-rc.1 → 0.1.38-rc.2

package/package.json

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

package/skills/create-campaign-v2/SKILL.md

@@ -773,439 +773,16 @@ Follow that prompt verbatim. It contains the full message-validation workflow, g
 
 Do NOT proceed to Step 4 (message review gate) without loading and following the generate-message subskill — message-validation.md must prove the full generate-messages workflow ran, and that workflow is defined in the subskill.
 
-## MANDATORY TOOL ORDER (read this BEFORE any tail step)
+## Tail (MANDATORY TOOL ORDER + Steps 13-16 + Threshold Trips + Hard Rules)
 
-Every tail run MUST call these tools in this exact order. The tail is
-**review-batch cascade-driven**: you kick off Enrich Prospect only for
-the imported review batch, and the workflow engine chains DNC Check →
-ICP Score → Passes Rubric → Generate Message automatically. Your job is
-to START the bounded cascade, WAIT for it to drain, OBSERVE the results,
-and stop for review.
-Do NOT manually run rubric-check, enrich, or message-generation
-tools — the cascade already does them.
+The full tail detail (~17k chars: MANDATORY TOOL ORDER, auto-execute-leads, validate-sample loop, auto-execute-messaging, awaiting-user-greenlight, threshold-trip logging, tail hard rules) lives in a dedicated on-demand subskill to keep this entry prompt fast to load.
 
-```text
-Step 13 — import review batch + kick bounded cascade
-  import_leads(targetLeadCount=importLimit)
-  wait_for_lead_list_ready
-  confirm_lead_list
-  get_rows_minimal                 # capture enrichCellIds
-  queue_cells(cellIds=<review-batch Enrich Prospect cells only>)  <-- starts bounded chain
-  wait_for_campaign_table_ready    # review-batch cascade drains here
-  update_campaign(currentStep=validate-sample)
-
-Step 14 — observe sample
-  get_rows_minimal                 # read passesRubric + message cell status per row
-  compute projectedPass
-  if OK: update_campaign(currentStep=auto-execute-messaging)
-  else:  diagnose brief-vs-list; if brief: update_campaign_brief + re-queue + wait
-  (check_rubric / bulk_enrich_with_prospeo are NOT called here —
-   cascade already did them. wait_for_rubric_results is OK as a
-   read-only observation helper if you need to block on completion.)
-
-Step 15 — observe messaging
-  get_rows_minimal                 # confirm passing rows have completed Generate Message cells
-  (rare) queue_cells on any pending Generate Message cells
-  token-contract spot check via get_rows
-  update_campaign(currentStep=awaiting-user-greenlight)
-  (generate_messages is NOT an MCP tool; messages come from the cascade)
-
-Step 16 — awaiting-user-greenlight
-  attach_recommended_sequence({ campaignId })  # tier-aware: premium/SN -> If Open Profile->INMAIL_OPEN, else INVITE->accepted->DM
-  re-surface watchUrl + review-batch orientation
-  STOP. DO NOT call start_campaign. DO NOT auto-advance currentStep.
-```
-
-**Prefer `attach_recommended_sequence` over `attach_sequence` in the
-autonomous tail.** The recommended tool takes only `campaignId` and
-delegates template selection to the backend's tier-aware selector
-(`selectTemplateForTiers`). `attach_sequence` requires you to
-hand-author a `version: 2` template with nodes, branches, and
-entryNodeId — that's error-prone mid-long-context (galley-off UAT
-`20260420T195732Z` failed because Claude hit "Invalid node type" and
-tried to debug via forbidden Bash/Glob calls). Use `attach_sequence`
-only when the caller explicitly needs a custom non-recommended cadence.
-
-Hard gates — if you find yourself about to violate any of these, stop
-first:
-
-- Do NOT use `update_cell` to write message bodies. The `Generate
-Message` column's http_request writes those cells via the cascade.
-  `update_cell` remains reachable for legitimate operator overrides
-  AFTER the tail hands off.
-- Do NOT call `check_rubric`, `enrich_with_prospeo`, or
-  `bulk_enrich_with_prospeo` in the tail. Those are direct-API
-  mutation tools that fetch data to the caller without writing to
-  the workflow table cells. Step 13's `queue_cells` already
-  triggers the column-level enrichment that populates those cells.
-  Running these tools in the tail produces duplicate cost with no
-  cell side effect.
-- `wait_for_rubric_results` is read-only and OK to use as an
-  observation helper when you need to block on rubric completion —
-  it does not mutate cells. Prefer `get_rows_minimal` +
-  `wait_for_campaign_table_ready` for the primary cascade-drain
-  path, but use `wait_for_rubric_results({ targetCount: cohortSize })`
-  when the table-level wait returns before rubric cells finish.
-- `start_campaign` is FORBIDDEN in the autonomous tail. It belongs only
-  in the Claude-greenlight path, AFTER the user signals "start". See
-  `references/final-handoff-contract.md`.
-- You MAY NOT call `start_campaign` without a prior successful
-  `attach_recommended_sequence` (or `attach_sequence` if a custom
-  cadence is explicitly required) in the same run.
-- You MAY NOT call `start_campaign` while ANY passing row has an
-  empty `Generate Message` cell. If you discover empty message cells in
-  the greenlight turn, ABORT greenlight and return to Step 15 first.
-- You MAY NOT call `attach_sequence` while ANY passing row has an
-  empty `Generate Message` cell. Before `attach_sequence`, call
-  `get_rows_minimal` and confirm every row where `passesRubric=true`
-  has a `completed` Generate Message cell with non-empty `result`. If
-  any are pending, call `queue_cells` on those generateMessageCellIds
-  and wait. If rows truly won't message, ESCALATE.
-- You MAY NOT advance past Step 13 without calling `queue_cells` on
-  the review-batch Enrich Prospect cells. Without it, every downstream
-  cell stays `pending` and the campaign ships empty.
-- You MAY NOT queue enrichment for rows outside the configured review
-  batch before the user approves expansion. Full-list enrichment/message
-  generation is a credit-spend decision and must happen after the user
-  has reviewed the sample.
-
-Load `core/auto-execute.yaml` exactly once at the start of Step 13. All
-subsequent steps read the already-parsed config. Do not re-load mid-run.
-Load each subskill prompt (`create-campaign-v2`, `research-sender`,
-`generate-messages`) at most once per run. A multi-call chunk sequence counts
-as one load. If a tool result already told you to load a prompt, load all
-chunks once and remember; do not restart the same prompt from offset 0 later.
-
-After every `update_campaign({ currentStep: ... })` in the tail, narrate
-what changed and orient the user to what the watch link will show next —
-reuse the v1 `create-campaign` watch-mode pattern verbatim.
-
-## Step 13: auto-execute-leads
-
-Entered on `CampaignOffer.currentStep === "auto-execute-leads"` (set by
-atomic mint).
-
-> Reminder: every provider search you run from this point forward — the
-> review-batch source rerun in Step 13, any expansion search after the
-> review batch, alternate-lane probes, account-based reruns, and operator
-> follow-ups — MUST include `campaignOfferId`. This applies to
-> `search_prospeo`, `search_sales_nav`, `search_apollo`,
-> `search_signals`, and any other provider search tool added later.
-> Campaignless searches after mint orphan results from the campaign UI.
->
-> **Lead-list vs campaign-table identity rule (do not confuse them):**
-> after the first `confirm_lead_list`, two workflow tables exist:
->
-> - the **lead-list** table (the original `sourceLeadListId` returned by
->   `import_leads`), and
-> - the **campaign workflow table** (`CampaignOffer.workflowTableId`,
->   also returned as `campaignTableId` from `confirm_lead_list`).
->
-> `confirm_lead_list` overwrites `CampaignOffer.selectedLeadListId` with
-> the campaign-table id. That means after the first confirm, the
-> campaign-table id is NOT a valid `sourceLeadListId` for any future
-> `import_leads` call.
->
-> When you scale up the import, `mode: "add"` requires the ORIGINAL
-> lead-list id (the one returned by the first `import_leads`), never the
-> campaign-table id. Passing the campaign-table id silently writes
-> straight into the campaign workflow table, bypassing the lead list
-> entirely; the lead list stays at its original size and the
-> campaign-builder `/leads` UI throws "Lead list not found" because it
-> expects `selectedLeadListId` to resolve as a lead list.
->
-> Capture the original `leadListId` from the FIRST `import_leads`
-> response and reuse it for every scale-up `import_leads(mode: "add")`
-> call on the same campaign. If the original id is unknown, query
-> for the lead-list table by name or skip the `mode: "add"` path; do
-> not pass the campaign-table id as `sourceLeadListId`.
-
-1. Load `core/auto-execute.yaml`. Capture `import.importLimit`,
-   `sample.sampleSize`, `sample.minProjectedPass`,
-   `sample.maxRevisionRounds`, `messaging.tokenContract`,
-   `messaging.critique.enabled`, `handoff.autoStart`,
-   `handoff.orientation`, `retry.sameToolSameError`,
-   `logging.logEveryThresholdTrip`.
-2. Resolve the approved source before importing. If there is no
-   `lead-source-intake.json`, keep the existing discovered-provider path:
-   `import_leads({ campaignOfferId, targetLeadCount: importLimit })`.
-   If a manifest exists, branch by `sourceType`:
-   - `supplied-linkedin-profiles`: revalidate file metadata and confirmation
-     token, confirm `load_csv_linkedin_leads` only after approval to batch the
-     supplied CSV into a Sellable lead list, persist the returned `leadListId`,
-     then call `confirm_lead_list({ sourceLeadListId: leadListId,
-targetLeadCount: importLimit })`. Do not call `import_leads` for this
-     branch; the lead list is the source, and `confirm_lead_list` imports the
-     bounded review batch into the campaign table.
-   - `existing-lead-list`: revalidate that the lead list still exists in the
-     same workspace, reuse it as `sourceLeadListId`, then call
-     `confirm_lead_list({ sourceLeadListId, targetLeadCount: importLimit })`.
-   - `supplied-domains`: reuse or confirm `load_csv_domains`, preserving
-     `domainFilterId`; run a campaign-associated Prospeo people search with
-     `campaignOfferId`, provider prompt preflight, and that `domainFilterId`;
-     then import with `targetLeadCount: importLimit`.
-     Never exceed `importLimit`. This is a review batch, not a full
-     campaign-scale import. If a source search/list contains more rows than
-     the cap, import only the first `importLimit` rows and leave the rest for
-     a later expansion step.
-     Persist or recover materialized IDs on resume: `leadListId`,
-     `domainFilterId`, `searchId`, `campaignTableId`, imported row IDs, and queued
-     cell IDs. If the source file changed after preview, or an existing lead list
-     is missing/wrong-workspace, escalate before materialization instead of
-     silently applying stale preview data. Retrying Step 13 must not duplicate
-     lead lists, searches, campaign rows, or queued cells.
-3. `wait_for_lead_list_ready` and `confirm_lead_list`.
-4. **Verify the table is set up properly before queuing.** Call
-   `get_rows_minimal({ tableId })` and confirm:
-   - `Enrich Prospect` column exists on the table and every imported
-     row has a corresponding cell with `status === "pending"`.
-   - `DNC Check`, `ICP Score`, `Passes Rubric`, and `Generate Message`
-     columns all exist too (the cascade depends on all of them).
-   - If any are missing, or the cell is in a non-`pending` terminal
-     state from an earlier run, ESCALATE with an explicit "table not
-     configured for autonomous tail" diagnosis. Do NOT attempt to
-     patch the table shape from the tail.
-5. **Kick off the bounded review-batch cascade.** `queue_cells({ tableId,
-cellIds: <pending enrichCellIds for the imported review batch only> })`.
-   You queue ONLY the review-batch `Enrich Prospect` cells; the cascade
-   auto-dispatches `DNC Check`, `ICP Score`, `Passes Rubric`, and (for rows
-   where `Passes Rubric === true`) `Generate Message` as each upstream
-   completes. Do not queue cells for any rows beyond `importLimit` before
-   user expansion approval.
-6. `wait_for_campaign_table_ready` — waits for the review-batch cascade to
-   drain.
-   If it times out with most cells still `pending`, ESCALATE: the
-   engine is blocked.
-7. If the import returns zero usable leads, ESCALATE per
-   `references/escalation-ladder.md` (hard fail).
-8. `update_campaign({ campaignId, currentStep: "validate-sample" })`.
-9. Orient user on the watch link (same pattern as every other step
-   change).
-
-**Do NOT call `check_rubric`, `wait_for_rubric_results`,
-`enrich_with_prospeo`, or `bulk_enrich_with_prospeo` in Step 13.**
-Those are direct-API tools that fetch enrichment/scoring data to the
-caller; they do not write to the workflow table cells. The cascade
-triggered by `queue_cells` runs the `Enrich Prospect` column's
-http_request, which writes the enrichment into the cell, which
-triggers the next column, and so on. Running the direct-API tools
-is duplicate work with no cell-population side effect.
-
-## Step 14: validate-sample (loop)
-
-Entered on `CampaignOffer.currentStep === "validate-sample"`. Full
-decision tree lives in `references/sample-validation-loop.md`.
-
-**Step 14 is pure observation.** The bounded review-batch cascade that Step
-13 kicked off (via `queue_cells` on Enrich Prospect) has already written ICP
-scores and Passes Rubric values back into the workflow table. Step 14 reads
-those review-batch cell results — it does NOT call `check_rubric`,
-`wait_for_rubric_results`, `bulk_enrich_with_prospeo`, or any other
-direct enrichment/scoring tool. All of that already happened in the
-cascade; running them again is wasted work and can overwrite the
-real cell results with unrelated data.
-
-Shape:
+Before any auto-execute or validate-sample step, **load the dedicated tail subskill verbatim**:
 
-```text
-get_rows_minimal({ tableId })
-passInSample = count of first sampleSize review-batch rows with passesRubric === true
-projectedPass = round(passInSample / sampleSize * importLimit)
-
-if projectedPass >= minProjectedPass:
-    advance to Step 15
-else:
-    diagnose brief-vs-list per sample-validation-loop.md
-    - brief: autonomous update_campaign_brief, then re-kick cascade
-             (queue_cells on enrichCellIds) and wait for the new
-             results
-    - list:  ESCALATE (no auto-revision of leads)
-    - unknown: ESCALATE
-    revisionRound += 1
-    if revisionRound > maxRevisionRounds:
-        ESCALATE
 ```
+mcp__sellable__get_subskill_prompt({ subskillName: "create-campaign-v2-tail" })
+```
+
+Follow that prompt verbatim. It contains the canonical MANDATORY TOOL ORDER (read this BEFORE any tail step), all Step 13-16 contracts, threshold-trip logging rules, and tail hard rules.
 
-Persisted counter rule: `revisionRound` persists across skill resume.
-Do NOT reset to 0 on resume — a stale resume must still respect the
-`maxRevisionRounds` cap.
-
-A "list problem" diagnosis NEVER triggers autonomous
-`update_campaign_brief`. Escalate instead.
-
-When the sample passes the projected-pass floor, call
-`update_campaign({ campaignId, currentStep: "auto-execute-messaging" })`
-and orient the user that messaging will complete for the review batch only.
-
-## Step 15: auto-execute-messaging
-
-Entered on `CampaignOffer.currentStep === "auto-execute-messaging"`.
-
-**Messages are produced by the `Generate Message` column cascade, not
-by a separate tool.** Do NOT call a `generate_messages` MCP tool —
-that tool does not exist; `generate-messages` is a subskill prompt
-loaded during live messaging drafts. In the autonomous tail, messages
-flow through the column pipeline: `Enrich Prospect` →
-`DNC Check` → `ICP Score` → `Passes Rubric` → `Generate Message`.
-Each column's http_request auto-fires when its upstream dependency
-completes AND passes gate (e.g. `Passes Rubric === true` before
-`Generate Message`). Your job in Step 15 is to WAIT for the review-batch
-cascade to reach `Generate Message` for rows that passed ICP, and verify
-the output — not to generate messages manually.
-
-**What Step 15 does:**
-
-1. `get_rows_minimal` to read `passesRubric` + `generateMessageCellId`
-   - the Generate Message cell's `status` and `result` per row.
-     Before queueing or waiting on Generate Message cells, confirm the
-     minted campaign brief still contains `{{...}}` in `## Approved Message
-Template`. If it does not, fail before the cascade runs. Do not repair
-     after mint; the template must be present during mint so Step 15 never
-     starts in freeform generation mode.
-2. For every row where `passesRubric === true`:
-   - The Generate Message cell should be `running` or `completed`
-     already (cascade auto-fired it). If it is still `pending`, queue
-     it explicitly: `queue_cells({ tableId, cellIds:
-<generateMessageCellIds> })`.
-3. `wait_for_campaign_table_ready` (or poll) until every passing
-   row's Generate Message cell is `completed`.
-4. Read the results back via `get_rows` (full) and sanity-check a
-   sample against the Phase 84 token contract: no unresolved
-   `{{tokens}}`, no invented proof, one sentence per line, etc.
-5. If the sample fails the token contract, diagnose brief-vs-list
-   (same revision loop as Step 14) and escalate if over
-   `maxRevisionRounds`.
-6. On success, `update_campaign({ campaignId, currentStep:
-"awaiting-user-greenlight" })`.
-
-**Do NOT hand-write message bodies via `update_cell`.** `update_cell`
-is reachable for legitimate operator overrides AFTER the tail hands
-off, but during autonomous tail the cascade owns the writes. If you
-find yourself drafting a message body and about to push it through
-`update_cell`, you have lost state — stop, read the cells, and let
-the pipeline finish.
-
-**What `attach_sequence` does (Step 16, not here):** binds the
-DM/InMail cadence template to the workflow table. Completely different
-job from messaging. Does NOT generate or write message text. A
-sequence with no `Generate Message` outputs would try to send empty
-strings, which is why Step 16 requires Step 15 to be complete.
-
-1. Observe the review-batch messages on the same sample that passed
-   validation.
-2. If `messaging.critique.enabled` is true (Plan 85-03), run the
-   bounded critique pass on the sample output per
-   `references/parallel-critique-protocol.md`. The pass runs on at
-   most `messaging.critique.sampleSize` rows, sends each row through
-   three parallel critics (targeting / copy / voice) that return
-   structured JSON, and merges the voices in a synthesis step that
-   enforces the Phase 84 token contract verbatim and re-runs the
-   finalizer pass. Any rewrite that invents proof or uses an
-   unsupported token falls back to the plain generated message. A
-   trip of `messaging.critique.budgetUsdCap` HALTS critique for the
-   remaining sample and continues the plain tail. Plan 85-02 reads
-   the flag but never flips it; critique stays off until the flag is
-   deliberately enabled.
-3. If `messaging.critique.opus.enabled` is also true, route the
-   highest-value subset through the Opus / craft-message path per
-   `references/thomas-variant-selection.md`. Opus is capped by
-   `messaging.critique.opus.maxMessagesPerPass` and
-   `messaging.critique.opus.budgetUsdCap`; tripping either cap keeps
-   the remaining rows on the non-Opus synthesizer. Opus is bound by
-   the same token contract as every other rewrite path.
-4. Check `messaging.tokenContract`. When `strict`, reject any sample
-   message that contains unresolved or unsupported tokens (including
-   any critique rewrite that tried to introduce one).
-5. If the sample passes the token contract (and critique when enabled),
-   stop at the review-batch handoff. Do NOT scale to the full source list
-   before explicit user expansion approval.
-6. If the sample fails the token contract or critique, diagnose +
-   loop the same way Step 14 does (brief-vs-list), subject to the same
-   `maxRevisionRounds` cap.
-7. On success, `update_campaign({ campaignId, currentStep:
-"awaiting-user-greenlight" })` and orient the user.
-
-Critique failure modes NEVER escalate. A critic timeout, a total
-timeout, a budget trip, a fake-proof rejection, or an unsupported-
-token rejection all fall back to the plain generated message for that
-row. Step 15 does not stall on critique.
-
-## Step 16: awaiting-user-greenlight
-
-Entered on `CampaignOffer.currentStep === "awaiting-user-greenlight"`.
-Full contract lives in `references/final-handoff-contract.md`.
-
-Shape:
-
-1. `attach_sequence` (bind the committed sequence to the campaign).
-2. Re-surface the `watchUrl` using `references/watch-link-handoff.md`.
-3. Surface the `handoff.orientation` string from `auto-execute.yaml`
-   alongside the link.
-4. STOP. Do NOT call `start_campaign`. Do NOT auto-advance
-   `currentStep`. The autonomous tail ends here.
-5. Make the credit boundary explicit in the handoff: only the first review
-   batch has been enriched/messaged; expanding to more leads requires a
-   separate user instruction.
-
-Two equally valid greenlight channels take Step 16 into a running
-campaign:
-
-- **UI path** — user clicks "Approve all" and "Start Campaign" in the
-  watch-link UI. The skill stays idle. On the next resume, it observes
-  the running state and shifts to a "campaign is live" confirmation.
-- **Claude greenlight path** — user replies with an affirmative ("yeah
-  start" / "looks good, start" / "ship it"). The skill then performs,
-  in order: (a) bulk-approve queued messages via the EXISTING endpoint
-  `POST /api/v3/workflow-tables/cells/approve-batch` (do NOT invent a
-  new tool/endpoint), (b) `start_campaign({ campaignId })`, (c)
-  `update_campaign({ campaignId, currentStep: "running" })`, (d)
-  re-surface `watchUrl` plus a "campaign is live" confirmation.
-
-A Claude greenlight on an already-running campaign is a no-op
-confirmation, NOT a duplicate start. Detect via `get_campaign` before
-calling any mutating tool; if the campaign is already running, skip
-approve-batch / start_campaign / update_campaign and just confirm.
-
-Workspace/sender mismatch at greenlight time aborts the start with the
-same invariant Phase 84 enforces.
-
-## Threshold Trips and Logging
-
-When `logging.logEveryThresholdTrip === true` (default), log every
-threshold trip: `projectedPass` computation, retry cap, revision cap,
-hard-fail. These logs drive `auto-execute.yaml` tuning after 3-5 real
-runs.
-
-## Tail Hard Rules
-
-- Review-batch sourcing/import happens in Step 13, not during atomic mint.
-- Full-list expansion is not part of the default tail. It requires user
-  approval after the review batch.
-  Import must never exceed `importLimit`.
-- The tail NEVER calls `start_campaign` on its own.
-- The tail NEVER auto-revises leads. Brief revision is autonomous; lead
-  revision is always operator-gated.
-- `revisionRound` persists across resume — no silent reset.
-- The bulk-approve action in the Claude greenlight path uses the
-  existing `POST /api/v3/workflow-tables/cells/approve-batch` endpoint
-  — do NOT create a new tool or endpoint for this.
-- Threshold trips are logged for calibration.
-
-</autonomous_tail>
-
-<references_index>
-
-| File                                       | Load when                                                              |
-| ------------------------------------------ | ---------------------------------------------------------------------- |
-| `references/approval-gate-framing.md`      | Phase 85 commit gate, before showing the approval packet               |
-| `references/watch-link-handoff.md`         | Atomic mint + every tail resume, before surfacing watchUrl             |
-| `references/sample-validation-loop.md`     | Step 14, before enriching + scoring the sample                         |
-| `references/escalation-ladder.md`          | Any tail step that needs to decide retry / revise / escalate           |
-| `references/final-handoff-contract.md`     | Step 16, and every Claude greenlight turn                              |
-| `references/parallel-critique-protocol.md` | Step 15 when `messaging.critique.enabled` is true                      |
-| `references/thomas-variant-selection.md`   | Step 15 when `messaging.critique.opus.enabled` is true                 |
-| `references/thomas-revision-filters.md`    | Any critique rewrite, before persisting                                |
-| `core/auto-execute.yaml`                   | Start of Step 13, load once; all tail steps read parsed values         |
-| `core/auto-execute.README.md`              | When tuning `auto-execute.yaml` knobs or reviewing threshold-trip logs |
-
-</references_index>
+Do NOT invoke any tail tool (auto_execute_leads, validate_sample, auto_execute_messaging, etc.) without first loading this subskill — the tool order and the threshold-trip checks live there.

package/skills/create-campaign-v2-tail/SKILL.md

@@ -0,0 +1,446 @@
+---
+name: create-campaign-v2-tail
+description: Tail steps (13-16) + MANDATORY TOOL ORDER + Threshold Trips + Tail Hard Rules for create-campaign-v2. Loaded on-demand via get_subskill_prompt before any auto-execute or validate-sample step. Internal subskill.
+visibility: internal
+---
+
+# create-campaign-v2 Tail (Steps 13-16 + Tool Ordering + Hard Rules)
+
+This is the tail detail extracted from the main create-campaign-v2 SKILL.md to keep the entry prompt slim. The agent loads this on-demand BEFORE entering the auto-execute or validate-sample steps. Follow this verbatim.
+
+## MANDATORY TOOL ORDER (read this BEFORE any tail step)
+
+Every tail run MUST call these tools in this exact order. The tail is
+**review-batch cascade-driven**: you kick off Enrich Prospect only for
+the imported review batch, and the workflow engine chains DNC Check →
+ICP Score → Passes Rubric → Generate Message automatically. Your job is
+to START the bounded cascade, WAIT for it to drain, OBSERVE the results,
+and stop for review.
+Do NOT manually run rubric-check, enrich, or message-generation
+tools — the cascade already does them.
+
+```text
+Step 13 — import review batch + kick bounded cascade
+  import_leads(targetLeadCount=importLimit)
+  wait_for_lead_list_ready
+  confirm_lead_list
+  get_rows_minimal                 # capture enrichCellIds
+  queue_cells(cellIds=<review-batch Enrich Prospect cells only>)  <-- starts bounded chain
+  wait_for_campaign_table_ready    # review-batch cascade drains here
+  update_campaign(currentStep=validate-sample)
+
+Step 14 — observe sample
+  get_rows_minimal                 # read passesRubric + message cell status per row
+  compute projectedPass
+  if OK: update_campaign(currentStep=auto-execute-messaging)
+  else:  diagnose brief-vs-list; if brief: update_campaign_brief + re-queue + wait
+  (check_rubric / bulk_enrich_with_prospeo are NOT called here —
+   cascade already did them. wait_for_rubric_results is OK as a
+   read-only observation helper if you need to block on completion.)
+
+Step 15 — observe messaging
+  get_rows_minimal                 # confirm passing rows have completed Generate Message cells
+  (rare) queue_cells on any pending Generate Message cells
+  token-contract spot check via get_rows
+  update_campaign(currentStep=awaiting-user-greenlight)
+  (generate_messages is NOT an MCP tool; messages come from the cascade)
+
+Step 16 — awaiting-user-greenlight
+  attach_recommended_sequence({ campaignId })  # tier-aware: premium/SN -> If Open Profile->INMAIL_OPEN, else INVITE->accepted->DM
+  re-surface watchUrl + review-batch orientation
+  STOP. DO NOT call start_campaign. DO NOT auto-advance currentStep.
+```
+
+**Prefer `attach_recommended_sequence` over `attach_sequence` in the
+autonomous tail.** The recommended tool takes only `campaignId` and
+delegates template selection to the backend's tier-aware selector
+(`selectTemplateForTiers`). `attach_sequence` requires you to
+hand-author a `version: 2` template with nodes, branches, and
+entryNodeId — that's error-prone mid-long-context (galley-off UAT
+`20260420T195732Z` failed because Claude hit "Invalid node type" and
+tried to debug via forbidden Bash/Glob calls). Use `attach_sequence`
+only when the caller explicitly needs a custom non-recommended cadence.
+
+Hard gates — if you find yourself about to violate any of these, stop
+first:
+
+- Do NOT use `update_cell` to write message bodies. The `Generate
+Message` column's http_request writes those cells via the cascade.
+  `update_cell` remains reachable for legitimate operator overrides
+  AFTER the tail hands off.
+- Do NOT call `check_rubric`, `enrich_with_prospeo`, or
+  `bulk_enrich_with_prospeo` in the tail. Those are direct-API
+  mutation tools that fetch data to the caller without writing to
+  the workflow table cells. Step 13's `queue_cells` already
+  triggers the column-level enrichment that populates those cells.
+  Running these tools in the tail produces duplicate cost with no
+  cell side effect.
+- `wait_for_rubric_results` is read-only and OK to use as an
+  observation helper when you need to block on rubric completion —
+  it does not mutate cells. Prefer `get_rows_minimal` +
+  `wait_for_campaign_table_ready` for the primary cascade-drain
+  path, but use `wait_for_rubric_results({ targetCount: cohortSize })`
+  when the table-level wait returns before rubric cells finish.
+- `start_campaign` is FORBIDDEN in the autonomous tail. It belongs only
+  in the Claude-greenlight path, AFTER the user signals "start". See
+  `references/final-handoff-contract.md`.
+- You MAY NOT call `start_campaign` without a prior successful
+  `attach_recommended_sequence` (or `attach_sequence` if a custom
+  cadence is explicitly required) in the same run.
+- You MAY NOT call `start_campaign` while ANY passing row has an
+  empty `Generate Message` cell. If you discover empty message cells in
+  the greenlight turn, ABORT greenlight and return to Step 15 first.
+- You MAY NOT call `attach_sequence` while ANY passing row has an
+  empty `Generate Message` cell. Before `attach_sequence`, call
+  `get_rows_minimal` and confirm every row where `passesRubric=true`
+  has a `completed` Generate Message cell with non-empty `result`. If
+  any are pending, call `queue_cells` on those generateMessageCellIds
+  and wait. If rows truly won't message, ESCALATE.
+- You MAY NOT advance past Step 13 without calling `queue_cells` on
+  the review-batch Enrich Prospect cells. Without it, every downstream
+  cell stays `pending` and the campaign ships empty.
+- You MAY NOT queue enrichment for rows outside the configured review
+  batch before the user approves expansion. Full-list enrichment/message
+  generation is a credit-spend decision and must happen after the user
+  has reviewed the sample.
+
+Load `core/auto-execute.yaml` exactly once at the start of Step 13. All
+subsequent steps read the already-parsed config. Do not re-load mid-run.
+Load each subskill prompt (`create-campaign-v2`, `research-sender`,
+`generate-messages`) at most once per run. A multi-call chunk sequence counts
+as one load. If a tool result already told you to load a prompt, load all
+chunks once and remember; do not restart the same prompt from offset 0 later.
+
+After every `update_campaign({ currentStep: ... })` in the tail, narrate
+what changed and orient the user to what the watch link will show next —
+reuse the v1 `create-campaign` watch-mode pattern verbatim.
+
+## Step 13: auto-execute-leads
+
+Entered on `CampaignOffer.currentStep === "auto-execute-leads"` (set by
+atomic mint).
+
+> Reminder: every provider search you run from this point forward — the
+> review-batch source rerun in Step 13, any expansion search after the
+> review batch, alternate-lane probes, account-based reruns, and operator
+> follow-ups — MUST include `campaignOfferId`. This applies to
+> `search_prospeo`, `search_sales_nav`, `search_apollo`,
+> `search_signals`, and any other provider search tool added later.
+> Campaignless searches after mint orphan results from the campaign UI.
+>
+> **Lead-list vs campaign-table identity rule (do not confuse them):**
+> after the first `confirm_lead_list`, two workflow tables exist:
+>
+> - the **lead-list** table (the original `sourceLeadListId` returned by
+>   `import_leads`), and
+> - the **campaign workflow table** (`CampaignOffer.workflowTableId`,
+>   also returned as `campaignTableId` from `confirm_lead_list`).
+>
+> `confirm_lead_list` overwrites `CampaignOffer.selectedLeadListId` with
+> the campaign-table id. That means after the first confirm, the
+> campaign-table id is NOT a valid `sourceLeadListId` for any future
+> `import_leads` call.
+>
+> When you scale up the import, `mode: "add"` requires the ORIGINAL
+> lead-list id (the one returned by the first `import_leads`), never the
+> campaign-table id. Passing the campaign-table id silently writes
+> straight into the campaign workflow table, bypassing the lead list
+> entirely; the lead list stays at its original size and the
+> campaign-builder `/leads` UI throws "Lead list not found" because it
+> expects `selectedLeadListId` to resolve as a lead list.
+>
+> Capture the original `leadListId` from the FIRST `import_leads`
+> response and reuse it for every scale-up `import_leads(mode: "add")`
+> call on the same campaign. If the original id is unknown, query
+> for the lead-list table by name or skip the `mode: "add"` path; do
+> not pass the campaign-table id as `sourceLeadListId`.
+
+1. Load `core/auto-execute.yaml`. Capture `import.importLimit`,
+   `sample.sampleSize`, `sample.minProjectedPass`,
+   `sample.maxRevisionRounds`, `messaging.tokenContract`,
+   `messaging.critique.enabled`, `handoff.autoStart`,
+   `handoff.orientation`, `retry.sameToolSameError`,
+   `logging.logEveryThresholdTrip`.
+2. Resolve the approved source before importing. If there is no
+   `lead-source-intake.json`, keep the existing discovered-provider path:
+   `import_leads({ campaignOfferId, targetLeadCount: importLimit })`.
+   If a manifest exists, branch by `sourceType`:
+   - `supplied-linkedin-profiles`: revalidate file metadata and confirmation
+     token, confirm `load_csv_linkedin_leads` only after approval to batch the
+     supplied CSV into a Sellable lead list, persist the returned `leadListId`,
+     then call `confirm_lead_list({ sourceLeadListId: leadListId,
+targetLeadCount: importLimit })`. Do not call `import_leads` for this
+     branch; the lead list is the source, and `confirm_lead_list` imports the
+     bounded review batch into the campaign table.
+   - `existing-lead-list`: revalidate that the lead list still exists in the
+     same workspace, reuse it as `sourceLeadListId`, then call
+     `confirm_lead_list({ sourceLeadListId, targetLeadCount: importLimit })`.
+   - `supplied-domains`: reuse or confirm `load_csv_domains`, preserving
+     `domainFilterId`; run a campaign-associated Prospeo people search with
+     `campaignOfferId`, provider prompt preflight, and that `domainFilterId`;
+     then import with `targetLeadCount: importLimit`.
+     Never exceed `importLimit`. This is a review batch, not a full
+     campaign-scale import. If a source search/list contains more rows than
+     the cap, import only the first `importLimit` rows and leave the rest for
+     a later expansion step.
+     Persist or recover materialized IDs on resume: `leadListId`,
+     `domainFilterId`, `searchId`, `campaignTableId`, imported row IDs, and queued
+     cell IDs. If the source file changed after preview, or an existing lead list
+     is missing/wrong-workspace, escalate before materialization instead of
+     silently applying stale preview data. Retrying Step 13 must not duplicate
+     lead lists, searches, campaign rows, or queued cells.
+3. `wait_for_lead_list_ready` and `confirm_lead_list`.
+4. **Verify the table is set up properly before queuing.** Call
+   `get_rows_minimal({ tableId })` and confirm:
+   - `Enrich Prospect` column exists on the table and every imported
+     row has a corresponding cell with `status === "pending"`.
+   - `DNC Check`, `ICP Score`, `Passes Rubric`, and `Generate Message`
+     columns all exist too (the cascade depends on all of them).
+   - If any are missing, or the cell is in a non-`pending` terminal
+     state from an earlier run, ESCALATE with an explicit "table not
+     configured for autonomous tail" diagnosis. Do NOT attempt to
+     patch the table shape from the tail.
+5. **Kick off the bounded review-batch cascade.** `queue_cells({ tableId,
+cellIds: <pending enrichCellIds for the imported review batch only> })`.
+   You queue ONLY the review-batch `Enrich Prospect` cells; the cascade
+   auto-dispatches `DNC Check`, `ICP Score`, `Passes Rubric`, and (for rows
+   where `Passes Rubric === true`) `Generate Message` as each upstream
+   completes. Do not queue cells for any rows beyond `importLimit` before
+   user expansion approval.
+6. `wait_for_campaign_table_ready` — waits for the review-batch cascade to
+   drain.
+   If it times out with most cells still `pending`, ESCALATE: the
+   engine is blocked.
+7. If the import returns zero usable leads, ESCALATE per
+   `references/escalation-ladder.md` (hard fail).
+8. `update_campaign({ campaignId, currentStep: "validate-sample" })`.
+9. Orient user on the watch link (same pattern as every other step
+   change).
+
+**Do NOT call `check_rubric`, `wait_for_rubric_results`,
+`enrich_with_prospeo`, or `bulk_enrich_with_prospeo` in Step 13.**
+Those are direct-API tools that fetch enrichment/scoring data to the
+caller; they do not write to the workflow table cells. The cascade
+triggered by `queue_cells` runs the `Enrich Prospect` column's
+http_request, which writes the enrichment into the cell, which
+triggers the next column, and so on. Running the direct-API tools
+is duplicate work with no cell-population side effect.
+
+## Step 14: validate-sample (loop)
+
+Entered on `CampaignOffer.currentStep === "validate-sample"`. Full
+decision tree lives in `references/sample-validation-loop.md`.
+
+**Step 14 is pure observation.** The bounded review-batch cascade that Step
+13 kicked off (via `queue_cells` on Enrich Prospect) has already written ICP
+scores and Passes Rubric values back into the workflow table. Step 14 reads
+those review-batch cell results — it does NOT call `check_rubric`,
+`wait_for_rubric_results`, `bulk_enrich_with_prospeo`, or any other
+direct enrichment/scoring tool. All of that already happened in the
+cascade; running them again is wasted work and can overwrite the
+real cell results with unrelated data.
+
+Shape:
+
+```text
+get_rows_minimal({ tableId })
+passInSample = count of first sampleSize review-batch rows with passesRubric === true
+projectedPass = round(passInSample / sampleSize * importLimit)
+
+if projectedPass >= minProjectedPass:
+    advance to Step 15
+else:
+    diagnose brief-vs-list per sample-validation-loop.md
+    - brief: autonomous update_campaign_brief, then re-kick cascade
+             (queue_cells on enrichCellIds) and wait for the new
+             results
+    - list:  ESCALATE (no auto-revision of leads)
+    - unknown: ESCALATE
+    revisionRound += 1
+    if revisionRound > maxRevisionRounds:
+        ESCALATE
+```
+
+Persisted counter rule: `revisionRound` persists across skill resume.
+Do NOT reset to 0 on resume — a stale resume must still respect the
+`maxRevisionRounds` cap.
+
+A "list problem" diagnosis NEVER triggers autonomous
+`update_campaign_brief`. Escalate instead.
+
+When the sample passes the projected-pass floor, call
+`update_campaign({ campaignId, currentStep: "auto-execute-messaging" })`
+and orient the user that messaging will complete for the review batch only.
+
+## Step 15: auto-execute-messaging
+
+Entered on `CampaignOffer.currentStep === "auto-execute-messaging"`.
+
+**Messages are produced by the `Generate Message` column cascade, not
+by a separate tool.** Do NOT call a `generate_messages` MCP tool —
+that tool does not exist; `generate-messages` is a subskill prompt
+loaded during live messaging drafts. In the autonomous tail, messages
+flow through the column pipeline: `Enrich Prospect` →
+`DNC Check` → `ICP Score` → `Passes Rubric` → `Generate Message`.
+Each column's http_request auto-fires when its upstream dependency
+completes AND passes gate (e.g. `Passes Rubric === true` before
+`Generate Message`). Your job in Step 15 is to WAIT for the review-batch
+cascade to reach `Generate Message` for rows that passed ICP, and verify
+the output — not to generate messages manually.
+
+**What Step 15 does:**
+
+1. `get_rows_minimal` to read `passesRubric` + `generateMessageCellId`
+   - the Generate Message cell's `status` and `result` per row.
+     Before queueing or waiting on Generate Message cells, confirm the
+     minted campaign brief still contains `{{...}}` in `## Approved Message
+Template`. If it does not, fail before the cascade runs. Do not repair
+     after mint; the template must be present during mint so Step 15 never
+     starts in freeform generation mode.
+2. For every row where `passesRubric === true`:
+   - The Generate Message cell should be `running` or `completed`
+     already (cascade auto-fired it). If it is still `pending`, queue
+     it explicitly: `queue_cells({ tableId, cellIds:
+<generateMessageCellIds> })`.
+3. `wait_for_campaign_table_ready` (or poll) until every passing
+   row's Generate Message cell is `completed`.
+4. Read the results back via `get_rows` (full) and sanity-check a
+   sample against the Phase 84 token contract: no unresolved
+   `{{tokens}}`, no invented proof, one sentence per line, etc.
+5. If the sample fails the token contract, diagnose brief-vs-list
+   (same revision loop as Step 14) and escalate if over
+   `maxRevisionRounds`.
+6. On success, `update_campaign({ campaignId, currentStep:
+"awaiting-user-greenlight" })`.
+
+**Do NOT hand-write message bodies via `update_cell`.** `update_cell`
+is reachable for legitimate operator overrides AFTER the tail hands
+off, but during autonomous tail the cascade owns the writes. If you
+find yourself drafting a message body and about to push it through
+`update_cell`, you have lost state — stop, read the cells, and let
+the pipeline finish.
+
+**What `attach_sequence` does (Step 16, not here):** binds the
+DM/InMail cadence template to the workflow table. Completely different
+job from messaging. Does NOT generate or write message text. A
+sequence with no `Generate Message` outputs would try to send empty
+strings, which is why Step 16 requires Step 15 to be complete.
+
+1. Observe the review-batch messages on the same sample that passed
+   validation.
+2. If `messaging.critique.enabled` is true (Plan 85-03), run the
+   bounded critique pass on the sample output per
+   `references/parallel-critique-protocol.md`. The pass runs on at
+   most `messaging.critique.sampleSize` rows, sends each row through
+   three parallel critics (targeting / copy / voice) that return
+   structured JSON, and merges the voices in a synthesis step that
+   enforces the Phase 84 token contract verbatim and re-runs the
+   finalizer pass. Any rewrite that invents proof or uses an
+   unsupported token falls back to the plain generated message. A
+   trip of `messaging.critique.budgetUsdCap` HALTS critique for the
+   remaining sample and continues the plain tail. Plan 85-02 reads
+   the flag but never flips it; critique stays off until the flag is
+   deliberately enabled.
+3. If `messaging.critique.opus.enabled` is also true, route the
+   highest-value subset through the Opus / craft-message path per
+   `references/thomas-variant-selection.md`. Opus is capped by
+   `messaging.critique.opus.maxMessagesPerPass` and
+   `messaging.critique.opus.budgetUsdCap`; tripping either cap keeps
+   the remaining rows on the non-Opus synthesizer. Opus is bound by
+   the same token contract as every other rewrite path.
+4. Check `messaging.tokenContract`. When `strict`, reject any sample
+   message that contains unresolved or unsupported tokens (including
+   any critique rewrite that tried to introduce one).
+5. If the sample passes the token contract (and critique when enabled),
+   stop at the review-batch handoff. Do NOT scale to the full source list
+   before explicit user expansion approval.
+6. If the sample fails the token contract or critique, diagnose +
+   loop the same way Step 14 does (brief-vs-list), subject to the same
+   `maxRevisionRounds` cap.
+7. On success, `update_campaign({ campaignId, currentStep:
+"awaiting-user-greenlight" })` and orient the user.
+
+Critique failure modes NEVER escalate. A critic timeout, a total
+timeout, a budget trip, a fake-proof rejection, or an unsupported-
+token rejection all fall back to the plain generated message for that
+row. Step 15 does not stall on critique.
+
+## Step 16: awaiting-user-greenlight
+
+Entered on `CampaignOffer.currentStep === "awaiting-user-greenlight"`.
+Full contract lives in `references/final-handoff-contract.md`.
+
+Shape:
+
+1. `attach_sequence` (bind the committed sequence to the campaign).
+2. Re-surface the `watchUrl` using `references/watch-link-handoff.md`.
+3. Surface the `handoff.orientation` string from `auto-execute.yaml`
+   alongside the link.
+4. STOP. Do NOT call `start_campaign`. Do NOT auto-advance
+   `currentStep`. The autonomous tail ends here.
+5. Make the credit boundary explicit in the handoff: only the first review
+   batch has been enriched/messaged; expanding to more leads requires a
+   separate user instruction.
+
+Two equally valid greenlight channels take Step 16 into a running
+campaign:
+
+- **UI path** — user clicks "Approve all" and "Start Campaign" in the
+  watch-link UI. The skill stays idle. On the next resume, it observes
+  the running state and shifts to a "campaign is live" confirmation.
+- **Claude greenlight path** — user replies with an affirmative ("yeah
+  start" / "looks good, start" / "ship it"). The skill then performs,
+  in order: (a) bulk-approve queued messages via the EXISTING endpoint
+  `POST /api/v3/workflow-tables/cells/approve-batch` (do NOT invent a
+  new tool/endpoint), (b) `start_campaign({ campaignId })`, (c)
+  `update_campaign({ campaignId, currentStep: "running" })`, (d)
+  re-surface `watchUrl` plus a "campaign is live" confirmation.
+
+A Claude greenlight on an already-running campaign is a no-op
+confirmation, NOT a duplicate start. Detect via `get_campaign` before
+calling any mutating tool; if the campaign is already running, skip
+approve-batch / start_campaign / update_campaign and just confirm.
+
+Workspace/sender mismatch at greenlight time aborts the start with the
+same invariant Phase 84 enforces.
+
+## Threshold Trips and Logging
+
+When `logging.logEveryThresholdTrip === true` (default), log every
+threshold trip: `projectedPass` computation, retry cap, revision cap,
+hard-fail. These logs drive `auto-execute.yaml` tuning after 3-5 real
+runs.
+
+## Tail Hard Rules
+
+- Review-batch sourcing/import happens in Step 13, not during atomic mint.
+- Full-list expansion is not part of the default tail. It requires user
+  approval after the review batch.
+  Import must never exceed `importLimit`.
+- The tail NEVER calls `start_campaign` on its own.
+- The tail NEVER auto-revises leads. Brief revision is autonomous; lead
+  revision is always operator-gated.
+- `revisionRound` persists across resume — no silent reset.
+- The bulk-approve action in the Claude greenlight path uses the
+  existing `POST /api/v3/workflow-tables/cells/approve-batch` endpoint
+  — do NOT create a new tool or endpoint for this.
+- Threshold trips are logged for calibration.
+
+</autonomous_tail>
+
+<references_index>
+
+| File                                       | Load when                                                              |
+| ------------------------------------------ | ---------------------------------------------------------------------- |
+| `references/approval-gate-framing.md`      | Phase 85 commit gate, before showing the approval packet               |
+| `references/watch-link-handoff.md`         | Atomic mint + every tail resume, before surfacing watchUrl             |
+| `references/sample-validation-loop.md`     | Step 14, before enriching + scoring the sample                         |
+| `references/escalation-ladder.md`          | Any tail step that needs to decide retry / revise / escalate           |
+| `references/final-handoff-contract.md`     | Step 16, and every Claude greenlight turn                              |
+| `references/parallel-critique-protocol.md` | Step 15 when `messaging.critique.enabled` is true                      |
+| `references/thomas-variant-selection.md`   | Step 15 when `messaging.critique.opus.enabled` is true                 |
+| `references/thomas-revision-filters.md`    | Any critique rewrite, before persisting                                |
+| `core/auto-execute.yaml`                   | Start of Step 13, load once; all tail steps read parsed values         |
+| `core/auto-execute.README.md`              | When tuning `auto-execute.yaml` knobs or reviewing threshold-trip logs |
+
+</references_index>