@sellable/mcp 0.1.37 → 0.1.38-rc.1

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

@@ -761,831 +761,17 @@ 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:
-
-- `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`.
-
-Do not:
-
-- call `get_campaign`
-- call `get_rows`
-- call `update_cell`
-- call `update_campaign_brief`
-- fetch fresh web or LinkedIn research
-- mutate DB-backed campaign state
-
-`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`
-
-`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:
-
-```text
-approve
-revise-brief
-revise-leads
-revise-rubric
-revise-messaging
-abort
 ```
+mcp__sellable__get_subskill_prompt({ subskillName: "create-campaign-v2-generate-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 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.
+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)