@sellable/mcp 0.1.37 → 0.1.38-rc.2

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

@@ -761,1265 +761,28 @@ Do not:
 
 ## Step 3: Generate Message
 
-Read `brief.md`, `lead-review.md`, `lead-sample.json`, optional
-`lead-filter.md`, optional `message-prep.md`, and optional
-`message-candidate-drafts.md`.
+The full Step 3 detail (~45k chars: message-validation workflow, gold-standard rules, proof inventory, candidate generation, finalizer pass, message-review-decision contract, A+B+C subject shape, token-fill rules, etc.) lives in a dedicated on-demand subskill to keep this entry prompt fast to load.
 
-This branch can run in parallel with Step 2 once `lead-review.md` and
-`lead-sample.json` exist. If `lead-filter.md` is not ready yet, draft from the
-lead-review message handoff rows, then reconcile after the filter lands.
+When you reach Step 3, **load the dedicated subskill verbatim**:
 
-Write:
+```
+mcp__sellable__get_subskill_prompt({ subskillName: "create-campaign-v2-generate-message" })
+```
 
-- `message-validation.md`
-
-Run the `generate-messages` skill in caller-declared `DRY MODE`. Its SKILL.md
-holds the full drafting contract (retrieval, proof inventory, candidates,
-finalizer pass, voice rules, safety). This step only covers orchestration.
-This is not optional: before any write to `message-validation.md`,
-`message-review.md`, `approval-packet.md`, or a commit-gate question, the
-current run must load the full `generate-messages` prompt. In hosted/from-
-scratch runs, load it with chunked `get_subskill_prompt({ subskillName:
-"generate-messages", offset, limit })` calls so every tool result stays small
-enough for the streamed harness. Start with `offset: 0`; the MCP will apply a
-portable default limit when omitted. Keep calling with `offset: nextOffset`
-until `hasMore` is false.
-In Codex-hosted runs, this is a quality gate, not just provenance: if the
-model cannot retrieve the complete prompt or cannot follow the required
-gold-standard deliberation flow, stop at `message-review` and ask for
-`revise-messaging`. Do not mint the campaign to compensate for weak copy.
-Do not hand-write `message-validation.md` from `message-prep.md` or
-`message-candidate-drafts.md`. Those files are planning inputs only; the final
-message-validation artifact must come from the actual `generate-messages`
-prompt path (`get_message_prompt` / `generate-messages`).
-
-Orchestration requirements:
-
-- start once real leads exist: `brief.md`, `lead-review.md`, and
-  `lead-sample.json` are enough to run generate-message
-- use only the find-leads message handoff rows as basis examples, e.g.
-  "prospects 1, 5, and 6 are solid enough to think from"
-- if `lead-filter.md` is ready, use it; if it arrives after message drafting,
-  reconcile before approval and rerun or revise messaging if the selected
-  winner depended on rows that fail the final filter
-- never write `message-validation.md`, render a message review, render an
-  approval packet, or ask the commit gate until 100% of the real
-  `generate-messages` prompt has been read
-- before `message-review` can recommend `approve-message`, verify
-  `message-validation.md` contains the full generate-messages shape:
-  `Gold Standard Strategy Map`, `Proof Inventory`, `Token Fill Rules`,
-  `Token Adherence Table`, `Angle Drafts`, `Kill / Combine Review`,
-  `Finalists`, `Finalizer Pass`, `Gold-Standard Quality Gate`,
-  `Skeptical Prospect Review`, `Winner Gate`, and a raw sendable
-  `Selected Winner`. If any are missing, recommend `revise-messaging` and do
-  not continue to approval or mint.
-- pass no `campaignId`
-- read only `brief.md`, `lead-review.md`, `lead-sample.json`, optional
-  `lead-filter.md`, and the `gold-standard-*` references. If
-  `message-prep.md` exists, use it as a
-  planning cache instead of redoing the same element inventory from scratch. If
-  `message-candidate-drafts.md` exists, use it as provisional draft input only
-  after checking its basis rows against the completed `lead-filter.md`, when
-  available.
-- generate 2-3 sample messages inline
-- start output with `Mode: DRY MODE (no DB mutation)`
-- treat the archived examples as the **quality bar**, not a paste source;
-  write messages that could plausibly belong in the archive for this motion
-- exact-template preservation only applies when the archived winner is the
-  same company as the brief
-- draft 3 internal candidates and run a Finalizer Pass that combines the
-  best opener, proof sentence, bridge, and CTA across them into one winner
-- if all finalists use the same first substantive line, treat the opener
-  test as failed; compare materially different opener jobs before selecting
-  a winner, or route to `revise-message`
-- the Finalizer Pass must block adjacent repeated copy. Do not let a pain
-  line and mechanism line reuse the same noun stack unless the second line
-  adds plainly new buyer value. Merge, translate, bullet, or cut instead.
-- the selected winner subject/body must not contain semicolons.
-- the selected winner subject must not be generic category copy like
-  `first LinkedIn campaign`, `quick question`, `outbound`, or `intro`. Prefer the
-  original gold-standard A + B + C subject shape: a concrete row/company token
-  plus a concrete workflow/object plus the offer/result, for example
-  `{{company}} + LinkedIn outbound + Claude/Codex` or
-  `{{source_post_topic}} + active leads + first message test`. Keep it short,
-  buyer-native, and free of abstract category nouns.
-- A + B + C is a quality shape, not permission to stuff tokens into the
-  subject. The subject must pique buyer interest and name a buyer-relevant
-  problem, workflow, or useful artifact. Do not use sender names, founder names,
-  "Austin's review", "founder call", "demo", "quick call", or similar
-  sender-centered language in the subject. Do not use a row token in the subject
-  unless the filled version is natural, lowercase/common-word where appropriate,
-  and more interesting than the non-tokenized version.
-- the selected winner must not contain sender-intro fragments like
-  `Usama here`, `derm here`, `board-cert derm here`, `[credential] here`,
-  or `[role] at [company] here`.
-- the selected winner must not use generic signal tokens such as
-  `{{recentSignal}}`, `{{recent_signal}}`, or `{{recent_signal_quote}}`.
-  Row personalization must use concrete enriched-row fields such as
-  `{{post_context}}`, `{{comment_summary}}`, `{{profile_summary}}`,
-  `{{source_post_topic}}`, `{{headline}}`, or `{{row_proof_note}}`, and it
-  must avoid source-citation phrases like `caught my eye`.
-- do not default to founder-to-founder, MD-to-MD, doctor-to-doctor,
-  peer-call, compare-notes, or similar identity-call CTA framing unless
-  the user explicitly selected that route or the brief makes it the
-  approved offer. Even then, the CTA must name the useful return artifact,
-  preview, teardown, or working session.
-- if the message is selling or introducing a product, the selected winner
-  must make the product plain before asking for time, but the opener must
-  not sound like homepage copy. A line shaped like `[Product] is a
-[category] platform -- feature, feature, feature` is blocked when it reads
-  like product copy instead of a human note. For command-native products,
-  describe the buyer job (`launch a LinkedIn campaign from Claude/Codex`)
-  before category nouns like `platform` or `MCP`.
-- pass the Thomas revision filters before writing findings
-- immediately after `message-validation.md` is confirmed and reconciled with
-  `lead-filter.md`, write `message-review.md` and render the slim chat version
-  inline starting with `Status: message-review` as the first visible line. Do
-  not put a markdown heading, preface, or summary before that status line.
-  This is a customer checkpoint optimized for fast approve / revise judgment.
-- Chat-vs-file split (this is the rule the user pinned):
-  - `message-review.md` (the file) keeps the full detail: `Status:
-message-review`, `Subject:`, `Tokenized template:`, `Sample prospect fill:` + `Token fill basis:`, `Rendered examples:`, `Good token fill:`,
-    `Good omit:`, `Bad token fill:`, `Why bad:`, `Fallback if missing:`,
-    `Token notes:`, `My take:`, `Suggested adjustment:`, `Question:
-approve-message or revise-messaging?`, `Recommendation:
-approve-message|revise-messaging`. The detailed gold-standard/rule audit
-    stays in `message-validation.md`. Both files are unchanged in scope and
-    are still required.
-  - The chat rendering shows ONLY: `Status: message-review`, `Subject:`,
-    `Tokenized template:`, `Sample prospect fill:` (with `Token fill basis:`),
-    `My take:`, `Suggested adjustment:`, `Question: approve-message or
-revise-messaging?`, `Recommendation:`. Then `Open artifacts:` links to
-    `message-review.md` and `message-validation.md` so the user can read the
-    full token guidance, good/omit/bad examples, and fallbacks if they want
-    to before deciding.
-  - Do NOT inline `Rendered examples:`, `Good token fill:`, `Good omit:`,
-    `Bad token fill:`, `Why bad:`, `Fallback if missing:`, or `Token notes:`
-    in chat. Those exist in the file and are linked. Keeping them out of
-    chat is what makes the gate easy to approve or revise on.
-- Never ask the message approval question until the slim chat review is fully
-  visible. A summary like `Message review is ready` or `the draft avoids a
-generic pitch` is not enough. The user must see the actual subject, the
-  actual tokenized message template, one filled sample prospect version with
-  its token fill basis, your take, and the suggested adjustment before any
-  `approve-message` / `revise-messaging` question appears. If you catch
-  yourself wanting to offer `show me message` as a choice, stop: render the
-  slim chat review first, then ask only `approve-message` or
-  `revise-messaging`. Include `Open artifacts:` links to `message-review.md`
-  and `message-validation.md` before the approval question.
-- `My take:` and `Suggested adjustment:` are mandatory customer-facing decision
-  fields, not optional summary text. They must appear after `Token notes:` and
-  before the question in every rendered message review. They must each be
-  non-empty, specific to the current message, and useful for one last manual
-  feedback pass. Never render a message review that jumps straight from token
-  notes to `Question:` or `Recommendation:`.
-- `Tokenized template:` in `message-review.md` must be a tokenized template with supported
-  enriched-row tokens such as `{{first_name}}`, `{{company}}`,
-  `{{workflow_context}}`, `{{headline}}`, `{{source_post_topic}}`, or
-  `{{row_proof_note}}`. It must not be a one-row-only raw sample. It must
-  include at least one literal `{{...}}` token. Keep only tokens that future
-  enriched rows can actually fill or safely omit. If you cannot produce a
-  tokenized template from supported enriched-row fields, stop with
-  `Recommendation: revise-messaging`.
-- `Sample prospect fill:` must render the same template for one named sample
-  prospect from `lead-sample.json` or the selected row used in
-  `message-validation.md`. It must show the complete subject and body the
-  prospect would receive, plus a one-line `Token fill basis:` naming which row
-  fields filled each token. This is the user-facing proof that the template
-  works. Do not ask for approval if the user cannot compare the template to a
-  concrete filled message.
-- `{{profile_signal}}` is never a supported customer-facing token. It is an
-  internal enrichment label and must not appear in `Subject:`, `Tokenized
-template:`, `Sample prospect fill:`, rendered examples, `Token notes:`,
-  `message-validation.md` selected copy, or `approval-packet.md`. If a
-  profile-derived signal matters, translate it into a buyer-readable derived
-  token with a clear fill rule, such as `{{workflow_context}}` or
-  `{{row_proof_note}}`; otherwise omit the line.
-- `Rendered examples:` must include at least one `Good token fill:` rendered
-  message where the row has a clean signal and one `Good omit:` rendered message
-  where an optional token line is omitted instead of forced. Each example must
-  be a complete rendered subject + body, not a bullet list of token names or a
-  single bridge-line fragment. Do not use bracketed instructions, deferred row
-  notes, or phrases like `approve the selected winner above`.
-- `Bad token fill:` must show at least one realistic wrong fill for the current
-  campaign, followed by `Why bad:`. This teaches the user and the live campaign
-  runtime what not to do. Examples: overclaiming signal intent (`you are
-evaluating Clay` when the only evidence is a post reaction), using forbidden
-  phrasing (`you engaged with content...` when the approved voice is `raised
-  your hand in a conversation around...`), forcing a weak optional token,
-  lowercasing proper nouns, or making row signal sound like AI mail merge.
-- `Fallback if missing:` is required for every token in the template. Each
-  fallback must say exactly what to do when the row lacks clean data: use a
-  safe segment-level phrase, omit the sentence/line, or route to
-  `revise-messaging` if omission would break the message. It must include a
-  concrete example of the fallback behavior, such as `omit the noticed... line`,
-  `use "operators"`, or `use "your outbound workflow"`. Never leave a token
-  with "N/A", "unknown", empty braces, bracketed instructions, or a generic
-  fill that sounds robotic or creepy.
-- rendered examples may only use token values that exist in `lead-sample.json`,
-  `lead-review.md`, `lead-filter.md`, or the selected winner's documented
-  supported-token plan. Do not invent example values to make the template look
-  better. If a token is absent, weak, or not a supported enriched-row field,
-  show the `Good omit:` version instead of filling it.
-- token casing must look intentional. Keep proper nouns, recipient names,
-  company names, product names, acronyms, and the pronoun `I` capitalized in
-  both the template examples and rendered output. Casual lowercase is allowed
-  only for static common words when the chosen message voice uses it. Do not
-  lowercase token values or invent transform syntax like `{{company_lower}}`,
-  `{{first_name | lower}}`, or bracketed casing instructions.
-- Token usage must be intelligent, not decorative. If a tokenized opener reads
-  like mail merge (`Reaching out because {{reporting_context}} sits in...`,
-  `your {{role_context}} work`, `saw your {{topic}}`, or similar), rewrite the
-  base line so the token either sounds like a natural noun phrase or is omitted.
-  Prefer row-derived tokens that change the reply reason; otherwise use a clean
-  segment-level line and document why the row token is omitted.
-- founder/sender names should not be used as the hook. Mention a founder name
-  only when the buyer already has a reason to care about that person or when the
-  user explicitly wants named-founder branding. In normal first-touch copy,
-  frame the CTA around the useful return artifact (`map one reporting problem`,
-  `review one dashboard`, `pressure-test one workflow`) instead of "call with
-  Austin" or another founder-name CTA.
-- message-review hard-fail preflight: before rendering `Status: message-review`,
-  scan the subject, tokenized template, good-fill example, good-omit example,
-  `My take`, `Suggested adjustment`, and recommendation. If any of them contain
-  `felt close enough to send`, `close enough to send`,
-  `thought this was relevant enough`, `seemed close
-enough`, `{{profile_signal}}`, `profile signal`, `is why I thought this might
-  be relevant`, `Austin's`, a sender/founder name in the subject, a one-row raw
-  sample under `Tokenized template:`, rendered examples without full copy, a
-  mail-merge-sounding tokenized opener, missing or empty `My take:`, missing or
-  empty `Suggested adjustment:`, `My take:` that only says `looks good`,
-  `strong`, or `approved`, `Suggested adjustment:` that only says `none`, or no
-  literal `{{...}}` token in `Tokenized template:`, revise the message before
-  showing it. Do not output
-  `Recommendation: approve-message` when any hard-fail preflight item is
-  present.
-- `My take` must be 1-3 short bullets or sentences, focused on what a founder
-  needs to decide: approve as-is, revise once, make it shorter, make it more
-  specific, change proof, change CTA, or preserve the current length because
-  cutting would remove reply reason. If a shorter version is recommended,
-  `Suggested adjustment` must say exactly what to remove or compress. Do not
-  include a long `What works`, `Gold-standard/rule check`, or internal checklist
-  in this checkpoint.
-- `Suggested adjustment` must give the founder a concrete final-edit option even
-  when the recommendation is `approve-message`. Use a useful shape like
-  `Approve as-is, or revise once to [specific edit] if you want [effect]`. It
-  must invite the user to give manual feedback before minting, for example:
-  `Reply revise-messaging with the exact line change, proof change, CTA change,
-or tone feedback you want before I build the approval packet.` Do not write
-  `none`.
-- if the message is merely plausible, generic, template-shaped, or weaker than
-  the loaded gold-standard examples, set `Recommendation: revise-messaging`.
-  The next Codex UAT goal is to prove message quality before mint, so no
-  approval packet or campaign mutation should happen just because the mechanics
-  are working.
-- immediately after rendering `message-review.md`, use the structured question
-  gate with exactly two choices, in this order: `approve-message`,
-  `revise-messaging`. Stop after the question. Do not write `approval-packet.md`,
-  `customer-roleplay.md`, or a commit-gate question until
-  `message-review-decision.md` contains `approve-message`.
-- if the selected winner or PS uses named customer/logo proof, quantified proof,
-  team credentials, or investor/accelerator proof that is not explicitly
-  supported by `brief.md`, `lead-review.md`, `lead-sample.json`, or loaded
-  reference material, the review must set `Recommendation: revise-messaging`.
-  Do not approve speculative credibility claims.
-- if the selected winner or PS uses vague proof wrappers like `spoken publicly
-about`, `publicly talked about`, `trusted by`, `worked with`, `used by`, or
-  bare customer-logo lists without naming a concrete buyer-relevant result,
-  mechanism, or risk reducer, the review must set `Recommendation:
-revise-messaging`. Supported logos are not automatically body-worthy proof.
-  Translate to a concrete proof line or omit the proof from the message.
-- if customer/logo proof is useful mainly for credibility, prefer a concise PS
-  over interrupting the body. The PS must name what the customers used the
-  product/service for, not just list logos. If the body already carries buyer
-  pain, mechanism, and CTA clearly, adding concrete social proof in the PS is
-  allowed when it lowers vendor risk.
-- the selected winner or PS must not use internal labels like `p.s. relevant
-proof:`, `p.s. useful proof:`, `p.s. proof:`, or `p.s. social proof:`.
-  Rewrite as a natural aside before asking the user to approve.
-- if the user chooses `revise-messaging`, write `message-review-decision.md`
-  with `revise-messaging`, preserve upstream artifacts, delete/regenerate
-  only `message-validation.md`, `message-review.md`,
-  `message-review-decision.md`, `customer-roleplay.md`, and
-  `approval-packet.md`, then rerun this message step.
-- after `message-review-decision.md` contains `approve-message`, write
-  `approval-packet.md` in customer-facing order and render the same approval
-  packet inline before the commit gate. The approval packet and six-choice
-  commit question must appear in the same customer-visible turn. Do not emit a
-  standalone commit-gate question. Include a clear `## Message Review` section
-  inside the approval packet before `## Approved Message Template`. It should
-  summarize the customer checkpoint from `message-review.md` and preserve the
-  same literal `My take:`, `Suggested adjustment:`, `Good token fill:`,
-  `Good omit:`, `Bad token fill:`, `Why bad:`, `Fallback if missing:`,
-  `Token fill basis:`, and `Recommendation:` labels.
-  Include `Open artifacts:` links to `approval-packet.md`,
-  `message-review.md`, `lead-review.md`, and `brief.md` before the commit-gate
-  question.
-- if `message-validation.md` contains an extractable `Selected Winner`, use
-  that exact winner as the `## Approved Message Template` in
-  `approval-packet.md` and in the campaign brief passed to `create_campaign`.
-  Only substitute concrete enriched-prospect-row `{{tokens}}`; do not rewrite
-  the copy inline at approval time. Do not use abstract slot tokens like
-  `{{hookLine}}`, `{{painLine}}`, `{{productLine}}`, `{{closeLine}}`, or
-  `{{psLine}}`, and do not use `{{recent_signal_quote}}`; use fields that exist
-  on the enriched prospect row instead.
-- the live body under `## Approved Message Template` must be sender-ready copy.
-  Bracketed text in the body is allowed only when it is a fully-specified
-  AI-native token (`[ALL_CAPS_NAME — Intent. DO: ... DON'T: ... FALLBACK:
-omit the line.]` — see
-  `mcp/sellable/skills/create-campaign/references/ai-native-tokens.md` for the
-  contract). Bracketed instruction placeholders that lack a contract are
-  BLOCKED — including `[ROW BRIDGE ...]`, `[insert ...]`, `[generated ...]`,
-  and any prose that defers per-row composition to a later step without
-  giving the model the rules. Either upgrade the placeholder to a full
-  AI-native token (Intent / DO / DON'T / FALLBACK), put the per-row rules in
-  `## Token Fill Rules` with concrete enriched-row fields, or route to
-  `revise-messaging`.
-- `approval-packet.md` and the live campaign brief passed to `create_campaign`
-  must include `## Approved Message Template`, `## Token Fill Rules`, and
-  `## Token Fill Examples`. `## Token Fill Examples` must copy the approved
-  examples from `message-review.md` / `message-validation.md`, including
-  `Good token fill:`, `Good omit:`, `Bad token fill:`, `Why bad:`,
-  `Fallback if missing:`, and `Token fill basis:`. Do not call
-  `create_campaign` if these sections are missing from the campaign brief.
-- `message-validation.md` must not call the winner a canonical template or
-  hide per-row generation in bracketed body text. `## Selected Winner` must
-  be a real sendable message that could be approved as-is.
-- block awkward bridge phrasing like `felt close enough to send this`,
-  `thought this was relevant enough`, or `seemed close enough`. Replace with a
-  crisp row-backed bridge using a buyer-readable row-derived token, such as
-  `That {{workflow_context}} work is where teams usually need cleaner reporting
-ownership.` If the signal is weak or absent, omit the bridge line entirely.
-- if subject, tokenized template, or rendered examples do not meet the bar,
-  `message-review.md` must recommend `revise-messaging`, not `approve-message`.
+Follow that prompt verbatim. It contains the full message-validation workflow, gold-standard rules, proof inventory, candidate generation, finalizer pass, message-review-decision contract, and all token-fill rules (A+B+C subject shape, Good/Bad token-fill examples, fallback-if-missing logic, tokenized templates).
 
-Do not:
+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.
 
-- call `get_campaign`
-- call `get_rows`
-- call `update_cell`
-- call `update_campaign_brief`
-- fetch fresh web or LinkedIn research
-- mutate DB-backed campaign state
+## Tail (MANDATORY TOOL ORDER + Steps 13-16 + Threshold Trips + Hard Rules)
 
-`message-validation.md` must contain:
-
-- `Status`
-- `Mode`
-- `Template Used`
-- `Primary Example`
-- `Secondary Influence`
-- `Lead Sample Basis`
-- `Strongest Reply Reason`
-- `Pre-Draft Buyer-Role Analysis`
-- `Campaign Element Pool`
-- `Gold Standard Strategy Map`
-- `Current Campaign Translation`
-- `Element Scoring`
-- `Proof Inventory`
-- `Token Fill Rules`
-- `Token Adherence Table`
-- `Angle Drafts`
-- `Kill / Combine Review`
-- `Finalists`
-- `Candidate Messages`
-- `Finalizer Pass`
-- `Gold-Standard Quality Gate`
-- `Skeptical Prospect Review`
-- `Winner Gate`
-- `Selected Winner`
-- `Findings`
-- `Recommendation`
+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.
 
-`approval-packet.md` must contain:
-
-- campaign direction
-- lead source and sample
-- filters and rubrics
-- selected message(s)
-- `## Message Review` with literal `My take:`, `Suggested adjustment:`, and
-  `Recommendation:` (`approve-message` or `revise-messaging`). If the message
-  is only okay, say so plainly so the user can choose `revise-messaging` at the
-  commit gate.
-- `## Approved Message Template`; when `message-validation.md` has a selected
-  winner, this section must preserve that selected winner rather than a newly
-  drafted approval-template variant
-- risks / caveats
-- next action: the six-choice commit gate
-
-`message-review.md` must contain:
-
-- `Status: message-review`
-- `Subject:` using the approved tokenized A + B + C subject shape
-- `Tokenized template:` followed by the tokenized approved message template
-- `Sample prospect fill:` with one concrete sample prospect's complete rendered
-  subject + body and a `Token fill basis:` line
-- `Rendered examples:`
-- `Good token fill:` with a complete concrete rendered subject + body
-- `Good omit:` with a complete concrete rendered subject + body where optional
-  row signal is omitted cleanly
-- `Bad token fill:` with a realistic wrong fill for the current campaign
-- `Why bad:` explaining the exact overclaim, unsupported token, weak signal,
-  casing mistake, or mail-merge phrasing that makes the bad fill unacceptable
-- `Fallback if missing:` with one concrete fallback or omit example for every
-  token in the template
-- `Token notes:` naming which tokens are safe to fill, which optional token line
-  should be omitted when absent, and whether the message uses standard sentence
-  case or casual lowercase static words
-- `My take:`
-- `Suggested adjustment:` with a concrete final-edit option and explicit
-  invitation to give manual feedback before approval
-- `Question: approve-message or revise-messaging?`
-- `Recommendation:` exactly `approve-message` or `revise-messaging`
-- The two-choice structured question gate immediately after the rendered review
-
-`message-review-decision.md` must contain exactly one selected route:
-`approve-message` or `revise-messaging`. It does not authorize DB mutation.
-
-If token sourcing is weak, revise token fill rules or route back to
-`revise-filter` or `revise-message` instead of guessing.
-
-</step_contracts>
-
-<resume_rules>
-
-Phase 84 validation resume:
-
-- No `brief-v1.md` / `brief.md` present -> run `create-campaign-brief`
-- `brief-v1.md` present but no `brief.md` -> copy `brief-v1.md` to `brief.md`,
-  then run `find leads`
-- Only `brief.md` present -> compatibility resume: run `find leads`
-- `lead-review.md` + `lead-sample.json` present, but no `lead-filter.md` and
-  no `message-validation.md` -> run `filter leads` and `generate message`
-  from the same find-leads basis; do not ask the user between them when
-  lead-review is confirmed
-- `lead-review.md` + `lead-sample.json` present, but no `lead-filter.md` -> run
-  `filter leads`
-- `lead-review.md` + `lead-sample.json` present, but no
-  `message-validation.md` -> run `generate message`
-- `lead-filter.md` + `message-validation.md` present -> reconcile message
-  basis rows against the final filter, then write/render `message-review.md`
-  and ask the two-choice message review gate
-- `message-validation.md` present but no `message-review-decision.md` -> write
-  `message-review.md`, render it inline starting with `Status:
-message-review`, then ask `approve-message` vs `revise-messaging`
-- `message-review-decision.md` contains `revise-messaging` -> preserve
-  upstream artifacts; delete only `message-validation.md`,
-  `message-review.md`, `message-review-decision.md`,
-  `customer-roleplay.md`, and `approval-packet.md`; rerun `generate message`
-- `message-review-decision.md` contains `approve-message` but no
-  `approval-packet.md` -> write `approval-packet.md`, render that packet inline
-  starting with `Status: approval-packet`, then ask the six-choice commit gate
-  in the same turn
-- `message-validation.md` + `message-review-decision.md` +
-  `approval-packet.md` present -> validation complete,
-  render `approval-packet.md` inline starting with `Status: approval-packet`,
-  then ask the six-choice commit gate in the same turn
-- `lead-review.md` without `lead-sample.json`, or vice versa -> stop with a
-  contract violation
-- `lead-filter.md` without upstream lead artifacts -> stop with a contract violation
-
-Phase 85 commit-gate + atomic-mint resume:
-
-- All validation artifacts present and `message-review-decision.md` contains
-  `approve-message` but no `approval-packet.md` yet -> write the approval
-  packet, render it inline, then show the commit gate in the same turn (see
-  `<commit_gate>` below)
-- `approval-packet.md` present but no `commit-gate-decision.md` -> show the
-  approval packet inline and then the commit gate in the same turn; an existing
-  positive `customer-roleplay.md` is advisory only
-- `commit-gate-decision.md` is a revision choice or `abort` -> route without
-  DB mutation
-- `commit-gate-decision.md` contains `approve` and no `CampaignOffer` minted
-  yet -> run atomic mint
-- `CampaignOffer` exists and `currentStep = "auto-execute-leads"` -> resume
-  via `create_campaign({ campaignId })` to re-fetch state + `watchUrl`,
-  re-surface the watch link using `references/watch-link-handoff.md`, and
-  continue into the autonomous tail at Step 13
-
-Phase 85 autonomous-tail resume (Plan 85-02):
-
-- `CampaignOffer.currentStep === "auto-execute-leads"` -> run Step 13
-  (import) then advance to `validate-sample`
-- `CampaignOffer.currentStep === "validate-sample"` -> run Step 14 sample
-  validation loop. Read the persisted `revisionRound` counter and do NOT
-  reset it to 0 on resume
-- `CampaignOffer.currentStep === "auto-execute-messaging"` -> run Step 15
-  messaging scale-up
-- `CampaignOffer.currentStep === "awaiting-user-greenlight"` -> Step 16:
-  re-surface `watchUrl` + `handoff.orientation` and STOP. Do not call
-  `start_campaign` on resume. Wait for UI start or a Claude greenlight
-  turn
-- `CampaignOffer.currentStep === "running"` -> campaign is live. Surface
-  a "campaign is live" confirmation + `watchUrl`. Do not re-start
-
-On every tail resume, re-surface the `watchUrl` and the current step's
-orientation string (v1 create-campaign watch-mode pattern). Load the
-relevant reference for the active step:
-
-- Step 14 -> `references/sample-validation-loop.md`
-- any escalation path -> `references/escalation-ladder.md`
-- Step 16 -> `references/final-handoff-contract.md`
-
-</resume_rules>
-
-<commit_gate>
-
-After Phase 84 artifacts are complete, show the user a commit gate before any
-DB mutation. Load `references/approval-gate-framing.md` for the full
-framing — especially the approval packet ordering and per-choice draft
-directory effects.
-
-Preconditions (block the gate when missing):
-
-- `brief-v1.md` should exist for from-scratch runs
-- `brief.md` must exist
-- `lead-review.md` must exist
-- `lead-sample.json` must exist
-- `lead-filter.md` must exist
-- `message-validation.md` must exist
-- `message-review.md` must exist
-- `message-review-decision.md` must exist and contain `approve-message`
-- `approval-packet.md` must be written before asking for a commit decision
-- `rubric.json` is optional but strongly preferred
-
-Anchor validation (block `approve` when empty):
-
-- `brief.md` has a non-empty `## Message Thesis`
-- `lead-review.md` status is `confirmed`
-- `lead-sample.json` parses and contains at least one row
-- `lead-filter.md` has `Decision`, `Who We'll Keep`, `Who We'll Exclude`,
-  `Pass Rate`, `Recommendation`, and `Implementation Details`
-- `message-validation.md` has `Status: confirmed`, `Mode: DRY MODE (no DB
-mutation)`, a `Selected Winner`, and a non-empty `Token Adherence Table`
-- `message-review.md` has `Status: message-review`, `Subject:`,
-  `Tokenized template:` with at least one literal `{{...}}` token,
-  `Sample prospect fill:` with a complete rendered subject + body and
-  `Token fill basis:`, `Rendered examples:`, `Good token fill:` with a complete
-  rendered subject + body, `Good omit:` with a complete rendered subject + body,
-  `Bad token fill:`, `Why bad:`, `Fallback if missing:`, `Token notes:`,
-  `My take:`, `Suggested adjustment:`, `Question:
-approve-message or revise-messaging?`, and
-  `Recommendation: approve-message`
-- `message-review-decision.md` is exactly `approve-message`
-
-Present the approval packet in user-facing order: brief, lead sample, lead
-filter, message validation. Do not dump raw JSON or opaque validation
-anchors at the user.
-
-When rendering the approval packet inline, start it with exactly
-`Status: approval-packet`. Write the same content to `approval-packet.md`
-before showing the gate. The same assistant turn must then use the structured
-question gate with the six commit choices below. In Claude Code, call
-`AskUserQuestion`; in Codex, call `request_user_input` when available. A
-commit-gate question without the inline `Status: approval-packet` packet is
-invalid UX. If a
-customer roleplay is performed, write `customer-roleplay.md` before the final
-choice. A roleplay result that says "looks good", "approve", or equivalent is
-only critique; it does not satisfy the gate. Write `commit-gate-decision.md`
-only after the user/operator makes one explicit choice.
-
-Use the structured question gate with exactly these 6 choices, in this order:
+Before any auto-execute or validate-sample step, **load the dedicated tail subskill verbatim**:
 
-```text
-approve
-revise-brief
-revise-leads
-revise-rubric
-revise-messaging
-abort
 ```
-
-Do not collapse, reorder, or add choices. Do not auto-select.
-
-If the host UI caps options per question, preserve the same six routes with a
-two-question gate: Q1 = `approve`, `revise`, `abort`; Q2 =
-`revise-brief`, `revise-leads`, `revise-rubric`, `revise-messaging`. Do not
-tell the customer this is because of schema/tool limits. In the split form,
-`revise` is only the parent choice for the second question, not a new route.
-
-</commit_gate>
-
-<sender_resolution>
-
-Before atomic mint, the skill needs a concrete sender identity. Resolve
-it in this order — stop at the first step that yields a confirmed
-sender, and NEVER invent / guess / brute-force LinkedIn URLs:
-
-1. **If the fixture/caller provides `senderIdentity.senderId`**, use it
-   directly. Call `get_sender({ senderId })` to confirm it exists in
-   the active workspace, then call `enrich_sender({ senderId })` ONCE
-   to populate `companySnapshot` + `proofDigest`. Do not call
-   `list_senders`, do not guess alternate URLs.
-2. **Else if the fixture/caller provides a confirmed
-   `senderIdentity.linkedinUrl`**, call `enrich_sender({ linkedinUrl
-})` ONCE. If it errors, DO NOT retry with a variation of the URL.
-   Fall through to step 3.
-3. **Else if the caller provides `senderIdentity.name` +
-   `companyDomain` (or workspace context), do ONE `WebSearch` pass**
-   for the authoritative LinkedIn profile URL ("`{name}` `{company}`
-   linkedin"). Use ONLY a URL that appears verbatim in a web search
-   result. Never synthesize a URL from the name. If WebSearch returns
-   no clean match, escalate to step 4.
-4. **Else escalate.** Print the available sender context and ask the
-   user to resolve (senderId or confirmed linkedinUrl). Do not proceed
-   with atomic mint.
-
-Hard rules:
-
-- At most ONE `enrich_sender` retry per run, only when the first
-  response was a transient (5xx) error. Do not retry on 400/404 by
-  changing the URL.
-- At most ONE `WebSearch` pass per run for sender resolution.
-- NEVER call `enrich_sender` on a lead's LinkedIn URL. `enrich_sender`
-  is for the single sender entity only. Lead enrichment happens via
-  the Enrich Prospect column in the workflow table.
-- If the fixture's `mustMatchWorkspaceSender` flag is true and the
-  resolved sender isn't in the active workspace, ABORT the run with an
-  explicit mismatch error.
-
-</sender_resolution>
-
-<atomic_mint>
-
-Only run this sequence when the user picks `approve`. Load
-`references/watch-link-handoff.md` before starting; it owns the watch-link
-surfacing protocol and the partial-mint recovery rules.
-
-Exact sequence:
-
-1. Read `brief.md` and `rubric.json` from the draft directory.
-2. Validate anchors one more time. An empty anchor blocks the approve path.
-   The brief must include an `## Approved Message Template` section with
-   the exact live message template and at least one supported `{{token}}`
-   such as `{{first_name}}`. Rendered examples are not enough. The
-   Generate Message column switches to template mode only when
-   `campaignBrief.content` contains `{{...}}`; without this marker it will
-   use full-generation mode and may rewrite the approved message.
-   The live template body must contain only sender-ready copy plus supported
-   tokens. Two token shapes are allowed:
-   - `{{snake_case}}` field-substitution tokens for atomic values that drop
-     directly into a fixed slot (greeting, subject, company name).
-   - `[ALL_CAPS_NAME — Intent. DO: ... DON'T: ... FALLBACK: omit the line.]`
-     AI-native tokens for personalization sentences. The bracket carries
-     the contract inline; the model writes a sentence (or omits the line)
-     per the inline rules. Full spec:
-     `mcp/sellable/skills/create-campaign/references/ai-native-tokens.md`.
-     No other bracketed placeholders are allowed — bracketed prose without an
-     explicit Intent / DO / DON'T / FALLBACK contract (e.g., `[ROW BRIDGE]`,
-     `[insert ...]`, `[generated ...]`) is BLOCKED because it leaves the
-     per-row generation under-specified.
-     Include `## Token Fill Rules` for every token in the template. Field
-     tokens may be row fields such as `{{first_name}}`, `{{company}}`,
-     `{{role}}`, `{{headline}}`, `{{profile_summary}}`, `{{post_context}}`,
-     `{{comment_summary}}`, `{{source_post_topic}}`, or `{{row_proof_note}}`
-     when those exact fields are supported by the row/enrichment data. AI-native
-     tokens are listed in the rules table by name and type with a pointer back
-     to the inline contract (the rules themselves live inside the bracket — do
-     not duplicate them in the table). Do not document static sender identity,
-     product name, proof points, casing style, `{{recent_signal_quote}}`, or
-     abstract slot tokens such as `{{hookLine}}`, `{{painLine}}`,
-     `{{productLine}}`, `{{closeLine}}`, or `{{psLine}}` — those are abstract
-     slots without a contract; convert them to AI-native bracket tokens with
-     real Intent / DO / DON'T / FALLBACK clauses, or cut them.
-     Include `## Token Fill Examples` copied from the approved message review and
-     validation artifacts. It must preserve `Good token fill:`, `Good omit:`,
-     `Bad token fill:`, `Why bad:`, `Fallback if missing:`, and
-     `Token fill basis:` so the minted campaign brief teaches future row
-     generation how to fill tokens, what fills are blocked, and what to do when
-     row data is missing. If the brief does not contain `## Token Fill Rules` and
-     `## Token Fill Examples`, do not call `create_campaign`; route back to
-     message review or approval packet generation.
-3. Call `bootstrap_create_campaign({ flowVersion: "v2" })`. Respect
-   `safeToProceed`; on blocking errors, surface and stop.
-4. Call
-   `create_campaign({ campaignBrief, currentStep: "auto-execute-leads" })`.
-   The `campaignBrief` argument must preserve the approved message
-   template section verbatim, including the `{{tokens}}`.
-   If the brief has no supported `{{token}}`, do not call
-   `create_campaign`. Fail the approve path and ask for a corrected
-   template, unless the user explicitly approved freeform AI-generated
-   messages and the tool call sets `messageGenerationMode:
-"ai-generated"`.
-   Include `senderIds` when a workspace sender is available. If the
-   customer-named sender is not configured in the current UAT workspace,
-   use an available workspace sender for the rehearsal and state that
-   mismatch in the final runtime notes. Do not silently mint without a
-   sender because sequence selection depends on sender tier/settings.
-   Capture `{ campaignId, watchUrl }` from the response.
-   - If the call errors, surface the error and stop. No rollback needed; no
-     campaign exists.
-   - If the response is missing `watchUrl`, treat it as a recoverable
-     failure. Stop before `save_rubrics`. Do not print a watch link.
-     Surface the contract violation explicitly — a missing `watchUrl` is a
-     plumbing bug, not a silent skip.
-5. Call `save_rubrics({ campaignOfferId: campaignId, rubric })` using the
-   payload derived from `rubric.json` (or from `lead-filter.md` if
-   `rubric.json` is absent).
-   - If this call fails after `create_campaign` succeeded, either rollback
-     the `CampaignOffer` row, or mark an explicit recoverable failure state
-     so the user can retry. Never leave a silent partial campaign. Do NOT
-     print the watch link during this recovery window.
-6. Flip the brief status in the draft to `committed`. Move the draft
-   directory from
-   `.sellable/create-campaign-v2/drafts/{workspace-slug}/{campaign-slug}/`
-   to
-   `.sellable/create-campaign-v2/drafts/{workspace-slug}/.committed/{campaign-slug}/`.
-7. Surface the `watchUrl` using the exact block defined in
-   `references/watch-link-handoff.md`. Only print after both
-   `create_campaign` AND `save_rubrics` have succeeded.
-8. Hand off to the autonomous tail (Plan 85-02). Do not run Step 13 lead
-   import here.
-
-If the approved lead source exists only as a provider lane in
-`lead-review.md` (for example a Sales Navigator filter/search URL) and no
-live `searchId` or `sourceLeadListId` is present, recreate the approved
-source by calling the matching provider search tool first, then import from
-the returned id. This is replaying the approved lane, not inventing a new
-source. Do not skip import/messages on that basis.
-
-Do NOT call `import_leads` during atomic mint. Full lead sourcing and import
-happen in Plan 85-02 Step 13 after mint.
-
-</atomic_mint>
-
-<revision_routing>
-
-When the user picks a revision choice, do not mint a campaign. Do not print
-a watch link. Route back to the relevant upstream step and reset the draft
-directory per `references/approval-gate-framing.md`:
-
-- `revise-brief` -> back to Phase 83 or Phase 84 depending on what changed.
-  Preserve `brief.md`; delete all downstream artifacts.
-- `revise-leads` -> back to Phase 84 `find leads`. Preserve `brief.md`;
-  delete lead and downstream artifacts.
-- `revise-rubric` -> back to Phase 84 `filter leads`. Preserve `brief.md`,
-  `lead-review.md`, `lead-sample.json`; delete `lead-filter.md`,
-  `message-validation.md`, and `rubric.json`.
-- `revise-messaging` -> back to Phase 84 `generate message`. Preserve
-  upstream artifacts; delete only `message-validation.md`,
-  `message-review.md`, `message-review-decision.md`,
-  `customer-roleplay.md`, and `approval-packet.md`.
-- `abort` -> move the draft directory to
-  `.sellable/create-campaign-v2/drafts/{workspace-slug}/.aborted/{campaign-slug}-{timestamp}/`.
-  No DB rows touched.
-
-Revisions must produce zero DB rows.
-
-</revision_routing>
-
-<boundaries>
-
-Phase 84 (pre-commit-gate) boundary:
-
-Do not create live campaign state during validation. Specifically, do not:
-
-- mint a campaign
-- import leads
-- persist selected lead lists
-- attach downstream assets
-- save remote rubric state
-- move the user into a live execution step
-
-Phase 85 (commit-gate and beyond) boundary:
-
-- The commit gate is the only place in this skill where DB mutation is
-  authorized. Do not call `create_campaign`, `save_rubrics`,
-  `update_campaign`, or any other mutating tool before the user picks
-  `approve`.
-- Revision choices and `abort` must never call a mutating tool.
-- `import_leads` is not part of atomic mint. Defer it to Plan 85-02 Step 13.
-- Never print the `watchUrl` until both `create_campaign` and `save_rubrics`
-  have succeeded.
-- Never fabricate or reconstruct the `watchUrl` — capture it from the
-  `create_campaign` response.
-- Once a campaign has been minted, every provider search and every
-  provider-import call from this skill MUST include the minted
-  `campaignOfferId`. This is universal — Prospeo, Sales Nav, Apollo,
-  Signal Discovery, and any future provider. The only place a
-  campaignless search is correct is the pre-mint Phase 84 `find leads`
-  discovery sample. Post-mint expansion, scale-up imports, alternate
-  lane explorations, account-based reruns, signal-monitor lanes, and
-  operator-driven follow-up searches all persist to the campaign and
-  must carry `campaignOfferId`. A search without `campaignOfferId`
-  after mint orphans the search from the campaign UI's Contact
-  Search panel and the campaign's `Searches` history, even when the
-  search produced rows that later get imported. If the search
-  helper enforces a `confirmed: true` gate, pass that with
-  `campaignOfferId` rather than dropping it.
-
-</boundaries>
-
-<autonomous_tail>
-
-The review-batch tail runs AFTER the atomic mint succeeds. It is driven by
-`core/auto-execute.yaml` and progresses through four steps — Step 13
-(import review batch), Step 14 (validate-sample), Step 15
-(auto-execute-messaging for the review batch), Step 16
-(awaiting-user-greenlight) — before stopping and waiting for a user
-greenlight.
-
-Cost boundary: the commit gate approves creating a campaign and producing a
-real review batch. It does NOT approve spending enrichment/message credits on
-hundreds of leads. Two separate scales apply post-mint and they MUST be kept
-distinct in your head:
-
-- **Import scale** (how many rows land in the campaign table). Defaults to
-  `import.importLimit` (25). The user MAY explicitly raise this at or before
-  mint with phrasing like "import all of them", "pull the full search", "all
-  ~2,000 from this lane", or a numeric target. When the user has stated the
-  full-scale import intent, pass that count as `targetLeadCount` so the table
-  carries the full pool. Importing rows is cheap (no enrichment runs yet);
-  storing them up front lets the user kick remaining enrichment manually
-  without re-importing later.
-- **Cascade scale** (how many rows get enriched/scored/messaged before user
-  approval). ALWAYS stays at the configured review batch (`sample.sampleSize`
-  or `import.importLimit` — default 25) until the user explicitly approves the
-  sample. This is the cost gate. Even when the user said "import all", you
-  queue Enrich Prospect cells for only the first review-batch rows. The
-  remaining rows sit `pending` in the table for the user to kick manually
-  after they've eyeballed the sample.
-
-A pre-stated full-import intent is NOT a pre-approval to cascade everything.
-Re-confirm before queueing enrichment beyond the review batch.
-
-If the source lane contains hundreds of leads and the user has not stated a
-full-import intent, leave the rest untouched in the source — do not import
-beyond `importLimit` until the user asks to expand.
-
-## 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.
+mcp__sellable__get_subskill_prompt({ subskillName: "create-campaign-v2-tail" })
 ```
 
-**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
-```
+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.