@sellable/mcp 0.1.0

package/skills/generate-messages/SKILL.md

@@ -0,0 +1,2361 @@
+---
+name: generate-messages
+description: Generate LinkedIn messages either for live campaign leads or dry-mode validation samples, using gold-standard campaign examples first and the REPLY framework only as fallback.
+visibility: internal
+---
+
+# Generate Messages
+
+You craft messages in one of two modes:
+
+- live campaign mode for selected leads in a real campaign table
+- caller-declared DRY MODE for Phase 84 validation artifacts before any live campaign exists
+
+## Tools
+
+- `mcp__sellable__get_campaign` (live campaign mode only)
+- `mcp__sellable__update_campaign_brief` (live campaign mode only)
+- `mcp__sellable__get_rows` (live campaign mode only)
+- `mcp__sellable__update_cell` (live campaign mode only)
+- `mcp__sellable__get_message_prompt`
+- `WebSearch` (live campaign mode only)
+- `mcp__sellable__fetch_linkedin_profile` (live campaign mode only)
+- `mcp__sellable__fetch_linkedin_posts` (live campaign mode only)
+- `Task` (live campaign batch mode only)
+
+## Execution Modes
+
+### Mode 1: Live Campaign Mode
+
+Use this mode when the caller provides a real `campaignId` or asks to save
+messages into campaign rows.
+
+This is the existing campaign-backed path. It may:
+
+- load campaign and row data
+- research prospects when needed
+- save drafts or approvals
+- update the campaign brief
+
+**Live mode inherits the same quality contract as dry mode** — retrieval
+against the archived gold-standard library, proof inventory ranking, 3
+candidates + `Finalizer Pass`, 5th-grade reading level by default,
+blank-line-per-sentence body shape, PS-must-earn-its-place, and
+product-clarity flow (opener → pain → what the product IS → what it DOES
+one action per line → deployment ease → CTA → optional PS).
+
+Only the **process constraints** differ between modes (live mode can mutate
+rows and fetch research, dry mode cannot). The **voice and shape rules are
+identical**.
+
+Apply the full "Retrieval & motion", "Proof inventory & token fill rules",
+"Drafting & finalizer", "Voice rules", and "Product clarity" sections below
+to live mode drafts, with live-mode-specific allowances:
+
+- research the prospect when useful (WebSearch, LinkedIn tools) — but the
+  message must still pass the product-clarity, blank-line, and PS rules
+- personalization from research is allowed, but it does not replace the
+  "what the product IS" / "what it DOES" anchors
+- save behavior and calibration loop follow the live-mode workflow below,
+  but the drafted message itself is subject to the same Thomas revision
+  filters as dry mode
+
+### Mode 2: Caller-Declared DRY MODE
+
+Use this mode when the caller explicitly says `DRY MODE`, `Phase 84`,
+`create-campaign-v2`, or provides:
+
+- `brief.md`
+- `lead-filter.md`
+- `lead-sample.json`
+
+Required dry-mode contract:
+
+- do not require, infer, or backfill `campaignId`
+- do not call `mcp__sellable__get_campaign`
+- do not call `mcp__sellable__get_rows`
+- do not call `mcp__sellable__update_cell`
+- do not call `mcp__sellable__update_campaign_brief`
+- do not mutate DB-backed campaign state
+- do not fetch fresh web or LinkedIn research
+- use only `brief.md`, `lead-filter.md`, and `lead-sample.json`
+- generate 2-3 sample messages inline
+- write findings to `message-validation.md`
+- start `message-validation.md` with `Mode: DRY MODE (no DB mutation)`
+
+If the dry-mode response is missing the no-mutation preamble, treat that as a
+hard failure and revise the output before returning it.
+
+## Phase 84 Dry-Mode Validation
+
+Dry mode validates message quality before campaign mint.
+
+Read:
+
+- `brief.md`
+- `lead-filter.md`
+- `lead-sample.json`
+- `mcp/sellable/skills/create-campaign-brief/references/phase75-active-runtime-message-pack.md`
+- `mcp/sellable/skills/create-campaign-v2/references/validation-criteria.md`
+- `mcp/sellable/skills/create-campaign-v2/references/thomas-revision-filters.md`
+- `mcp/sellable/skills/create-campaign-v2/references/gold-standard-message-patterns.md`
+- `mcp/sellable/skills/create-campaign-v2/references/gold-standard-message-examples.md`
+- `mcp/sellable/skills/create-campaign-v2/references/gold-standard-message-validation-example.md`
+
+Dry-mode output must follow this flow: **element pool → gold-standard
+strategy map → current-campaign translation → element scoring → agent
+dialogue cross-review → angle drafts → kill/combine review → finalists →
+winner gate**.
+
+### Retrieval & motion
+
+- treat `phase75-active-runtime-message-pack.md` as the **real line-level
+  gold pack** for active clients and proven live message shapes
+- retrieve against the full archived gold-standard library and pick the closest 2-4 examples for consideration
+- use the runtime pack first for concrete formatting cues that the
+  abstract archive may flatten away: lowercase vs title case, exact
+  `two options:` formatting, short line rhythm, and load-bearing
+  `p.s.` lines
+- treat the archive as the **quality bar and motion reference**, not a paste source. Your job is to write a new message that could plausibly belong in the archive, not to recolor an existing one
+- before choosing any example, name the **strongest true reason this buyer
+  should reply**. This is the north star: the most compelling safe mechanism,
+  proof, asset, diagnostic, offer, or buyer outcome available from the brief and
+  sample.
+- choose one `Primary Example` only as packaging guidance: how to make that
+  reason feel human, readable, and non-AI in an inbox. The example does not
+  decide the message shape; the strongest true reason decides the shape.
+- choose at most one `Secondary Influence` for a narrow purpose (CTA packaging,
+  proof compression, opener rhythm)
+- choose the `Primary Example` by **reply-reason fit**, not just
+  founder/operator tone: which example best packages the strongest true thing
+  you can say without making it feel templated, scrape-y, or over-shaped
+- do not default to `Superposition` just because the sender is a founder/operator. Down-rank any example whose native shape would force heavier proof, `two options:`, or list density than this brief actually needs
+- do not blend multiple campaign motions into one message
+- do not fill a shape for its own sake. A/B CTA, PS, sender-origin line,
+  category analogy, proof stack, and row-signal bridge are all optional
+  packaging tools. Use them only when they make the strongest true reason more
+  compelling or easier to reply to.
+- **exact-template preservation only applies when the archived winner is the same company as the brief** (e.g., Superposition drafting for Superposition). In that case preserve casing, spacing, CTA shape, and proof ordering, and change only the documented tokens. For every other case, match the quality bar and motion shape; do not recolor the exemplar's wording
+- if the runtime pack shows a proven same-company or same-motion line that is
+  doing real work, do not silently flatten it away in the name of generic
+  cleanliness
+- choose the highest-specificity validated strategy available: event-led, signal-led, job-post-led, then proof-led specialist fallback (full patterns in `gold-standard-message-patterns.md`)
+
+### Proof inventory & token fill rules (document before drafting)
+
+- rank usable proof:
+  1. exact differentiated mechanism
+  2. named credibility proof or strongest safe social proof
+  3. concrete outcome proof
+  4. deployment simplicity or speed-to-value proof
+  5. founder, backing, prior-company, capital-raised-for-motion, or category-first proof
+- treat "founder/backing" broadly: meaningful prior employers, notable investors, capital raised for the motion, or first-to-do-X differentiation — all valid only when the brief supports them
+- classify every proof option before drafting:
+  - `body-worthy`: makes the core message clearer or more believable in one
+    natural line
+  - `translated`: the raw proof is useful, but must be rewritten into human
+    buyer language before it appears in the message
+  - `CTA-asset`: the proof is best used as something to send, show, or walk
+    through
+  - `PS-worthy`: the proof works only as a short natural aside after the CTA
+  - `internal-only`: useful for strategy, but awkward, confusing, braggy, or
+    skepticism-creating in the cold message itself
+- supported proof is not automatically message-worthy. If a real person would
+  not say the proof line in a cold InMail, translate it or keep it internal.
+- vague credibility wrappers are blocked. Phrases like `spoken publicly about`,
+  `publicly talked about`, `trusted by`, `worked with`, `used by`, or bare logo
+  lists are weak proof unless the same sentence names the buyer-relevant thing
+  that changed. Do not launder weak proof through testimonial language. If the
+  available proof only says a logo exists, keep it internal or turn it into a
+  CTA asset; do not put it in the body.
+- raw activity metrics, interaction counts, usage counts, time-window claims,
+  revenue math, and traction numbers must pass the "so what?" test. The issue
+  is not that they are raw numbers; the issue is whether the buyer immediately
+  understands why the number is impressive, relevant, and reply-worthy.
+- body-worthy proof must answer a buyer objection, not just display traction.
+  If the proof's real job is "this is live, not theoretical," say that in
+  natural language or omit the proof.
+- default the body to **one main proof beat**: the strongest safe thing that
+  makes the buyer care. If a second beat does not answer a different buyer
+  objection or make the CTA more credible, cut it.
+- document each token: name, source field, allowed transformation, fallback rule
+
+### Per-row signal extraction (do this FIRST, before any drafting)
+
+The current defect that substance filters catch (Earned-right, Read-as-1:1)
+is that the generator historically drafted 3 global templates and stamped
+them onto sample rows. The correct flow is: **iterate rows first, extract
+row-specific signal, draft per-row, then sample 2-3 rows for the output
+artifact.**
+
+1. Iterate `lead-sample.json` rows. For each row, look for row-specific
+   signals in this priority order:
+
+   - a recent post (URL + excerpt from `recent_posts[]` or `posts[]`) —
+     strongest, because you can quote-back a line
+   - a profile-summary phrase in the buyer's own voice (verbatim string
+     from `headline` / `summary` / `about`)
+   - a hiring trigger (open role title + posting date) or a recent
+     funding event / product launch on the row's company
+   - a visible tool or tech-stack keyword in the headline
+   - a mutual connection or company-event (webinar, conference, podcast)
+   - NONE — the row is category-only. Flag in Findings as "signal-absent
+     row" so real sends can enrich upstream.
+
+2. Pick the SAMPLE ROWS for the artifact (2-3 rows) such that each
+   chosen row has a signal category DIFFERENT from the others — the
+   sample should show the motion working across post-quote, profile-
+   snippet, and trigger-led angles, NOT three iterations of the same
+   template. If the sample carries only ONE signal category, draft the
+   rows against that same category and flag the diversity gap in
+   Findings.
+
+3. For each chosen sample row, the draft MUST include the extracted
+   signal specifically in the body — quoted or clearly paraphrased,
+   never buried into generic category language. **Default placement is
+   Block 3 / line 3, not the opener.** Only move the signal into line 1
+   or line 2 when the chosen archived motion truly depends on a
+   signal-led opener and can stay free of source-citation /
+   scrape-forward phrasing.
+
+4. Never turn a signal into mind-reading or source narration. A row
+   signal means the person engaged with, posted about, hired for, or
+   publicly touched a topic; it does NOT prove the topic is "clearly on
+   their mind," a priority, a current initiative, or an active buying
+   motion. Engagement signals can qualify the lead, but the message
+   should mention the topic only when it can be translated into a natural
+   buyer context without sounding scraped or stalkerish.
+
+   Blocked shapes:
+
+   - `{{recent_signal}} is clearly on your mind`
+   - `AI-GTM stack is clearly on your mind`
+   - `you are clearly focused on...`
+   - `your team is obviously paying attention to...`
+   - `you're already thinking about...`
+   - `this is obviously relevant because...`
+   - `saw you on {{recent_signal}}`
+   - `saw you around {{recent_signal}}`
+   - `saw you engaging with {{recent_signal}}`
+
+   Safer shapes:
+
+   - `not sure if this is relevant, but if {{signal_topic}} is part of what you're testing, this may be useful`
+   - `this may be too specific, but the {{signal_topic}} angle felt close enough to send`
+   - `if {{workflow_signal}} is relevant at {{company}}, this might be useful`
+   - `thought this was worth sending because {{signal_topic}} touches the same problem`
+
+### Angle drafting & finalizer
+
+Do not lock the strategy after the first decent idea. First create a
+campaign element pool, score the elements, then draft angle variants from
+the best combinations.
+
+Before drafting, generate **3-5 options** for each element:
+
+- sender relevance options: who is sending, and why that matters to this
+  buyer. Resume intros are blocked; sender identity is allowed when it
+  explains buyer relevance.
+- buyer problem options: annoying, expensive, risky, or desire-shaped
+  facts the buyer would already understand.
+- offer framings: what the recipient can actually do because this
+  product exists. Product category alone is not an offer.
+- mechanism framings: what burden, workflow, risk, or manual work the
+  product removes.
+- visibility-gap framings for data / intelligence products: what the buyer
+  already sees today vs. what the product uniquely lets them see. This often
+  beats a generic problem-solved opener because it makes the missing input
+  obvious without claiming the whole problem is fixed.
+- proof options: mechanism proof, customer/result proof, sender proof,
+  backing/status proof, asset proof, and no-proof version where clarity
+  is stronger without explicit proof.
+  For each proof option, separately classify **proof hardness**: hard-to-fake
+  legitimacy proof vs. easy-to-claim proof. Hard-to-fake legitimacy proof
+  can matter even when it is not the strongest buyer-outcome proof because
+  it answers "is this real?" for a cold recipient. Easy-to-claim proof
+  includes vague outcome promises, unsupported speed claims, and broad
+  "we can help you get X" claims. Hard-to-fake proof includes public backing
+  or batch status, verified founder/operator credentials, live/public product
+  artifacts, public customer logos/results, public company profiles, or
+  other claims a recipient could plausibly verify.
+  Founder-dogfood proof must clarify the sender is founder, user, or
+  both. If both, say why that matters to the buyer; vague lines like `I
+run my own on [Product]`, `using it myself now`, or `I use it myself`
+  are BLOCKED unless the same line makes the founder/user relationship and
+  buyer relevance clear.
+- CTA options: single soft ask, send-over asset, short walkthrough, A/B
+  choice, or reply-with-interest.
+- PS options: commitment-lowering aside, concrete preview aside,
+  proof-as-wink aside, tight customer/result proof, light human/humorous
+  aside, or no PS.
+
+Score every option on:
+
+- buyer care
+- clarity
+- believability
+- hard-to-fake legitimacy / scam-risk reduction
+- reply likelihood
+- gold-standard fit
+
+Tie-breaker: among truthful options, clarity beats completeness. Do not pick
+the most technically accurate or comprehensive line if a simpler line is still
+true and easier to understand. Preserve accuracy by avoiding false claims, but
+do not stuff every qualifier into the message just because the brief supports
+it. Cold outbound needs the clearest useful version, not the full specification.
+
+Then choose a **Best Strategy Combination** before drafting: sender
+relevance + buyer problem + offer + mechanism + proof role + CTA job +
+PS decision. Explain why it beats the next-best combination.
+
+`Gold Standard Strategy Map` is required before drafting. For the Primary
+Example and any Secondary Influence, explain:
+
+- buyer situation it interrupts
+- strongest reason the buyer replies
+- sender relevance
+- offer clarity move
+- mechanism clarity move
+- proof role
+- CTA job
+- surface traits NOT to copy blindly
+
+`Current Campaign Translation` is required before drafting. Map those
+same jobs to this campaign and reject awkward equivalents. Do not copy
+format until you can explain the line job.
+
+Draft **5-7 rough angle drafts**, not 5-7 rewrites of the same message.
+The goal is to see enough real message shapes to find the strongest reply
+reason before polishing. Use only angles that are supported by the element
+pool:
+
+- sender-origin angle
+- pain-removal angle
+- offer-first angle
+- mechanism-first angle
+- proof-translated angle
+- objection-handling angle
+- CTA-preview angle
+
+Each draft must test a different strategic approach: different opener job,
+offer framing, proof placement, CTA shape, or mechanism emphasis. Do not
+produce 5-7 tone variants of the same message.
+
+When any proof is classified as `PS-worthy` or `CTA-asset`, the rough
+angle set must include at least two drafts that test different proof/PS
+treatments in actual message copy:
+
+- proof in body vs proof in PS
+- buyer-outcome PS vs no PS
+- backing/status proof vs mechanism proof
+- proof-as-CTA asset vs proof omitted
+- light human/humorous PS vs straight PS vs no PS, only when humor lowers
+  friction without making the message clever, unserious, or less clear
+
+Do not decide PS or proof placement only in analysis. The Finalizer should
+choose after seeing the proof inside real draft shapes.
+
+Each angle draft must be AGAINST A SPECIFIC SAMPLE ROW (name the row in
+the angle's "Why this angle exists" line). If the row has a specific
+signal, the signal must be traceable to `lead-sample.json`. If no signal
+exists, say the angle is category-level and recommend upstream signal
+enrichment in Findings.
+
+Run a `Kill / Combine Review` before finalists:
+
+- mark each angle `keep`, `combine`, or `reject`
+- reject if unclear, weird, founder-braggy, over-explained,
+  resume-intro-shaped, proof-pasted, CTA-vague, or not reply-worthy
+- name the exact line or decision that caused rejection
+- do not let a merely supported proof beat survive if it hurts naturalness
+  or reply likelihood
+
+Run an `Agent Dialogue Cross-Review` before angle drafts are allowed to
+survive:
+
+- **Skeptical prospect:** roleplay the skeptical version of the recipient,
+  someone who has been prospected on LinkedIn by similar products hundreds of
+  times. Reject elements before drafting when they trigger "not me", "so
+  what?", legal/employment anxiety, vendor-pitch fatigue, or product-category
+  confusion. Explicitly list the biggest offer red flags and belief gaps:
+  what they would not believe yet, what feels risky, what feels unclear, and
+  what would make them ignore the message even if the offer is true. Include
+  a `Legitimacy / scam-risk` check: would this read like a real company with
+  a real product, or like a random person making an easy-to-fake promise?
+  Then include a `Who is this / why trust them?` check. These are different:
+  sender credibility can answer peer relevance, but it may not answer whether
+  the company, platform, workflow, or offer is legitimate. If that gap exists
+  and hard-to-fake proof is available (YC/backing/funding, verified credentials,
+  public company/profile proof, live product artifacts, named customers/results),
+  test it as body-worthy or PS-worthy legitimacy proof rather than discarding it
+  as mere badge-flashing.
+- **Offer strategist:** state the actual reply-worthy offer in plain English,
+  the buyer-side reason to care, the product explanation, the mechanism, proof
+  placement, and CTA job.
+- **Gold-standard editor:** choose the closest gold motion by line job, not
+  surface resemblance. Name what the final message must do to sit near the
+  archive quality bar.
+- **Cross-review consensus:** reconcile disagreement into one approved element
+  set before drafting: opener job, product explanation, mechanism, proof
+  treatment, CTA shape, PS/no-PS decision, and banned elements.
+
+If the approved element set still contains a weak proof, abstract CTA, product
+jargon, anti-current-state framing, or unsupported buyer assumption, do not
+draft. Return `revise-message` with the exact missing strategy piece.
+
+Build **2 finalists** from the best parts:
+
+- finalist 1: cleanest / lowest-friction version
+- finalist 2: strongest proof or CTA alternative that still sounds human
+
+Run a `Skeptical Prospect Review` on each finalist before the Finalizer
+Pass. Roleplay the skeptical version of the recipient: someone who has
+been prospected on LinkedIn by similar products hundreds of times and is
+looking for a reason to dismiss the note in 3 seconds.
+
+The skeptical prospect must flag:
+
+- the biggest offer red flags from the recipient's seat
+- why they would not believe the offer yet
+- what would make the offer feel risky, unclear, or too good to be true
+- "so what?" proof or claims
+- founder-story lines that do not help the buyer
+- "who is this / why trust them?" gaps, especially when the sender has domain
+  credibility but the offer also requires platform/company execution
+- product-category confusion
+- buyer-identity mismatch: any line that makes the recipient feel like the
+  offer is for some other generic `a [role]` instead of for them specifically
+- anti-employer / anti-current-vendor framing that the brief does not
+  explicitly allow
+- a CTA that feels like a call trap or an unclear artifact
+- any line that makes them think "not me," "too salesy," "too assumptive,"
+  or "I have seen this pitch before"
+
+If the skeptical prospect would not keep reading or would not plausibly
+reply, the finalist is blocked or rewritten. Do not let the writer grade
+its own copy without this adversarial pass.
+
+Bounded reviewer contract:
+
+- each reviewer gets one pass only
+- each reviewer may name at most 3 blockers and 1 recommended fix
+- no recursive debate after the cross-review consensus is written
+- once an element is approved, downstream passes may simplify, cut, or
+  reject it, but may not reopen the whole strategy
+- if a line trips the same gate twice, cut it, change the strategy for
+  that line, or use the safer approved fallback instead of making tiny
+  wording-only rewrites
+- ambiguous proof defaults to omitted, not softened into a new claim
+- preserve the rejected proof in Findings if useful, but do not keep
+  trying to rescue it inside the message
+
+Run a `Finalizer Pass` across the finalists and angle parts:
+
+- pick the best opener (most relevant, least assumptive)
+- pick the best offer sentence (what the buyer can do)
+- pick the best mechanism sentence(s) (what burden is removed)
+- pick the best proof treatment (body, translated, CTA asset, PS, or
+  internal-only)
+- pick the best CTA job and wording
+- decide whether PS is useful or should be omitted
+- assemble the winner from those parts inside the chosen motion's
+  skeleton
+- if all finalists use the same first substantive line, treat that as a
+  failed opener test. Rewrite and compare materially different opener jobs
+  before selecting a winner, or route to `revise-message`.
+- if stitching stacks ideas awkwardly, cut to the stronger one
+- run a phrase-level naturalness audit before selecting the winner. Block
+  coined or compressed strategy phrases when they technically describe the
+  idea but do not sound like something the sender would type to this buyer.
+  Non-exhaustive examples: `peer-built way`, `doctor-led path`,
+  `clinician-native option`, `the whole point is`, `platform-side proof`.
+  The pattern matters more than the exact words: if a phrase feels like an
+  internal label, strategy note, or stitched-together abstraction, rewrite
+  it into the concrete buyer benefit or sender intent. Every word and
+  phrase must make sense on first read without the recipient pausing to
+  decode it. If a phrase takes even a second to interpret, replace it with
+  plainer language tied to the exact basis row, e.g. `we're trying to
+help...` or `built for [buyer] to...`. Do not overuse generic solved-state
+  bridges like `there's a way to...`; they read informercial when they imply
+  the buyer's problem is now solved before the product or artifact has earned
+  that claim.
+- do not let the first substantive line become a generic problem-solved
+  promise. Openers shaped like `there's a way to stop/fix/solve [problem]`
+  are BLOCKED when they sound like an ad, imply the problem is already
+  solved, or fail to connect to the specific sample row. Prefer a concrete
+  row-fit line, a useful artifact, or a buyer-owned current-state observation
+  that the recipient can understand without reading the brief.
+- if 3 adjacent mechanics, objection removers, proof points, or CTA
+  options are genuinely parallel and easier to understand as a short
+  `-` bullet stack, use the bullet stack in the winner. Do not reserve
+  this for cleanup. Use bullets when they make the buyer picture the offer
+  faster on mobile. If the product has 3+ plain mechanics such as pricing
+  control, take-rate/economics, malpractice, credentialing, billing, async
+  chat/photo care, or setup speed, prefer a compact bullet stack over
+  separate prose lines unless bullets would make the note feel like a
+  landing page. For data / intelligence products, if the buyer receives 3+
+  concrete output types (e.g. accounts, infrastructure, signals, alerts,
+  records, reports), prefer a short bullet stack over a dense mechanism
+  paragraph.
+- if one finalist already holds the best of every piece, the winner may
+  equal it — name which one and on which axis it won (relevance,
+  distinctiveness, proof, coherence, readability)
+
+The winner entry must:
+
+- name which finalist or angle each borrowed part came from, or mark
+  "finalizer swept by Finalist X"
+- name the SPECIFIC SAMPLE ROW the winning draft targets
+- quote or paraphrase the row-specific signal used, or state that the
+  row is category-only
+- include raw sendable message copy only. Do not select a "canonical
+  template", a subsection named "Approved Message Template", or a body
+  containing bracketed instructions such as `[ROW BRIDGE ...]`,
+  `[insert ...]`, or `[generated ...]`. If the only scalable option needs a
+  deferred per-row instruction, route to `revise-message` and fix the
+  token plan instead.
+- never use generic signal tokens like `{{recentSignal}}`,
+  `{{recent_signal}}`, or `{{recent_signal_quote}}`. If row personalization
+  is needed, use concrete enriched-row fields such as `{{post_context}}`,
+  `{{comment_summary}}`, `{{profile_summary}}`, `{{source_post_topic}}`,
+  `{{headline}}`, or `{{row_proof_note}}`, and make the line work without
+  source-citation phrases like `caught my eye`.
+- never use `{{profile_signal}}` in selected copy, message-review templates,
+  or rendered examples. It is an internal analysis bucket, not a sendable row
+  token. Lines like `{{profile_signal}} is why I thought this might be
+relevant for {{company}}` are BLOCKED because they expose enrichment logic
+  and read as AI-generated mail merge. If the underlying signal is strong,
+  convert it into a named row-derived context token such as
+  `{{workflow_context}}`, `{{source_post_topic}}`, or `{{row_proof_note}}`;
+  if it is weak, omit the personalization line.
+
+Finalizer preference when multiple candidates are otherwise comparable:
+
+- prefer a **substance-first Block 1 + row-signal Block 3** winner over a
+  quote-back opener that starts with retrieved recipient text. Substance
+  means buyer-relevant current state, useful artifact, operator reality,
+  or mechanism — never `X here`, `I'm X at Y`, or a bare founder intro.
+- only let the row signal lead the opener when the archived motion truly
+  depends on it and the line can stay clear of source-citation / talk-at
+  patterns (`"your post"`, `"your bio says"`, `"saw you posted"`,
+  `"last month you wrote"`)
+- if a quote-back opener forces those patterns, keep the substance-first
+  opener and move the signal into Block 3 instead
+- when comparing two otherwise good winners, the one that sounds like a
+  sharp human sender using context usually beats the one that sounds like
+  a scrape-driven callback
+- prefer a **single low-pressure CTA** over `two options:` unless the
+  Primary Example itself is A/B and Option B is a genuinely strong
+  self-serve asset, proof artifact, or meta-demo that the brief clearly
+  supports
+- if an A/B CTA adds ceremony without increasing buyer confidence, cut
+  it back to one ask
+- do not default to founder-to-founder, MD-to-MD, doctor-to-doctor,
+  peer-call, compare-notes, or similar identity-call framing. Those CTAs
+  are usually weaker than naming the useful thing the buyer gets. Use them
+  only when the user explicitly chose that route or the brief makes that
+  peer-call motion the approved offer. Even then, the CTA must name the
+  useful return artifact, preview, teardown, or working session.
+- when the message is selling or introducing a product, make the product
+  plain before asking for time, but do not make the opener sound like a
+  homepage definition. The reader should be able to answer "what is this?"
+  before the CTA. Prefer a simple human line such as `[Product] lets
+[buyer] do [specific job]` or `I built [Product] so [buyer] can
+[specific outcome]` when founder involvement is part of the offer. A
+  line shaped like `[Product] is a [category] platform -- feature, feature,
+feature` is blocked when it reads like product copy instead of a note.
+  For command-native tools, describe the buyer job (`launch a LinkedIn
+campaign from Claude/Codex`) before category nouns like `platform` or
+  `MCP`.
+  Do not make the CTA carry product explanation the body skipped.
+- the final winner must enforce **one sentence per paragraph literally**
+  except for a deliberate short bullet stack, `two options:` CTA, or
+  optional PS. If a selected candidate has multi-sentence paragraphs,
+  split or cut before returning
+
+Run an `Optional Simplifier Pass` after the Finalizer Pass and before the
+Gold-Standard Quality Gate. This is not a strategy pass and must not
+reopen the winner selection. It starts from the finalizer winner and only
+asks whether the same message can be simpler, clearer, more concrete, and
+more believable without losing force. Mobile readability matters, but it is
+secondary to first-read clarity.
+
+This pass is optional and conservative:
+
+- keep the finalizer's strategy, strongest reply reason, proof role, CTA
+  job, casing style, tokens, and all AI-tell gates
+- if the simplified candidate is clearer and still truthful, it becomes the
+  candidate passed into Final Subtraction. Do not keep the heavier finalizer
+  winner merely because it preserves more proof or mechanism detail.
+- first run a required `Holistic Plain Rewrite`: rewrite the whole selected
+  candidate from scratch into the simplest clear version that preserves the
+  same reply reason. Do not preserve line order, proof placement, PS, or
+  sentence structure unless it still helps. The holistic rewrite should feel
+  like the clean message a sharp sender would actually send, not a polished
+  version of the finalizer's draft.
+- then run a `Simplifier Line Pass` on every mechanism, proof, CTA, and PS
+  line that remains in either the finalizer draft or holistic rewrite. For
+  each line, write:
+  - original line
+  - plain rewrite
+  - keep original | keep rewrite | cut
+  - reason
+    The selected winner should start from the Holistic Plain Rewrite when it is
+    clearer and still truthful. Use the line pass as a safety check, not as a
+    constraint to preserve the old structure. Keep original lines only if the
+    holistic rewrite or plain rewrite loses important truth, specificity, or
+    believability. If both original and rewrite are too abstract, rewrite again
+    before the line can survive.
+- a short line is not automatically simple. If a short mechanism line is
+  abstract, jargon-heavy, or hard to picture, rewrite it into the plain
+  action + output the buyer can understand. Example: `AI agents engage
+trust-based scammers directly` is less clear than `BeeSafe uses AI agents
+to talk to live scammers and turn those chats into fraud signals`.
+- remove adjacent repetition. A pain line may name the problem and the
+  next line may name the mechanism, but they cannot reuse the same noun
+  stack unless the second line adds plainly new information. Bad:
+  `Credentialing, multi-state licensure, and malpractice usually kill the
+idea.` followed by `FutureClinic handles credentialing, multi-state,
+malpractice...`. Fix by translating one line into the buyer outcome, a
+  bullet stack, or a simpler mechanism line such as `FutureClinic handles
+the admin work behind that.`
+- remove semicolons from final copy. Semicolons are allowed in analysis,
+  but the selected message body and subject must not contain `;`.
+- block sender-intro fragments shaped like `Usama here`, `derm here`,
+  `board-cert derm here`, `[credential] here`, or `[role] at [company]
+here`. If sender proof matters, write it as a normal human sentence tied
+  to the buyer reason, such as `I use it with my own patients now.` or cut
+  it.
+- preserve a finalizer bullet stack when it is doing clarity or mobile
+  readability work; do not flatten useful mechanics back into prose
+- use a short `-` bullet stack only when 3 adjacent items are genuinely
+  parallel mechanics, proof points, objection removers, or options
+- combine adjacent short sentences only when they are doing one job
+- split dense sentences when they carry more than one idea
+- do not bullet the opener, main proof line, CTA, or PS
+- reject the simplified candidate if it loses specificity, weakens the
+  objection-remover, makes proof more generic, makes the CTA less useful,
+  sounds like a landing page, creates new unsupported claims, or keeps /
+  introduces a buyer-identity mismatch
+- if simplification does not clearly improve simplicity, clarity,
+  concreteness, or believability, keep the
+  finalizer winner
+
+Run a `Final Subtraction Pass` after the Optional Simplifier Pass and before
+the Gold-Standard Quality Gate. This is the last copy pass and it optimizes
+for reply likelihood, not constraint coverage.
+
+Goal: shortest truthful message most likely to earn a reply.
+
+For every line in the selected winner, ask:
+
+- Would removing this line make the prospect less likely to reply?
+- Does this line make the reply reason clearer, more believable, or easier
+  to act on?
+- Is this line carrying one of the core jobs: buyer gap / pain, product
+  mechanism, concrete output, or CTA?
+- Does this line repeat the same nouns, proof, or mechanism already stated
+  in the previous 1-2 lines? If yes, merge, translate, or cut.
+
+If the answer is no, cut the line. True is not enough. Supported proof,
+category claims, extra mechanisms, founder/context lines, PS lines, and raw
+numbers are optional; they only stay when they clearly increase reply
+likelihood more than they increase cognitive load.
+
+When the CTA itself offers a concrete artifact, sample, audit, or preview,
+that artifact is usually proof of usefulness, but not always proof of
+legitimacy. If the offer could read as scammy, too-good-to-be-true, or
+"random internet person asking me to trust a new platform," keep one
+hard-to-fake legitimacy proof when it materially makes the company or offer
+feel real. Do not keep proof/PS just because it answers a theoretical trust
+objection in the artifact. Ask whether the actual final message would get
+more replies with the extra line. If not, cut it.
+
+Default keep-set:
+
+- buyer pain / gap
+- product mechanism in plain language
+- concrete output or asset
+- CTA
+
+Default cut-set unless clearly reply-positive:
+
+- `first`, `only`, category-claim lines
+- lists of examples that merely prove the model knows the space
+- raw proof numbers
+- investor/backing PS that is only badge-flashing
+- extra product explanation after the core mechanism is already clear
+- any second CTA or proof beat that competes with the sample / main ask
+
+Do not treat the artifact's analysis needs as copy needs. The message does
+not need to show every reason it passed the prompt. It only needs enough for
+the recipient to understand why replying is worth it.
+
+Message-validation artifact budget:
+
+- the final `message-validation.md` is an audit artifact, not a transcript
+  of every thought
+- never let analysis consume the budget needed for `## Selected Winner`
+- keep `## Strongest Reply Reason` under 80 words
+- keep each analysis section to 1-3 compact bullets unless the section is
+  actual message copy
+- `## Angle Drafts` should include 5-7 compact rough drafts or draft
+  skeletons, not long reasoning transcripts
+- `## Candidate Messages` may include the 2-3 full candidate bodies
+- `## Finalists` should summarize source parts and not duplicate full
+  message bodies already shown in Candidate Messages
+- avoid large tables; if a table is necessary, cap it at 6 rows
+- if output feels long, compress earlier analysis before shortening or
+  omitting the selected winner, gates, or findings
+- once the winner passes the gates, emit the JSON immediately; do not run
+  another diagnostic loop or restart angle evaluation
+
+**Substance-filter gate before the Finalizer Pass:** each candidate is
+checked against the 8 Substance Filters in
+`../create-campaign-v2/references/thomas-revision-filters.md` (Earned-
+right, Presumption, Vague-proof, Read-as-1:1, Founder-origin coherence,
+Anti-AI-tell, Anti-talk-at, Anti-self-introduction). A candidate that
+fails any filter is marked BLOCKED in `message-validation.md` (cite
+the filter name and the offending line) and CANNOT be selected as the
+winner. If all 3 candidates are BLOCKED, DO NOT finalize — route to
+`revise-message` with the enumerated failure reasons per candidate.
+
+### Reply-reason packaging contract (HARD INVARIANT)
+
+Every candidate message (A / B / C) MUST be built around the strongest
+true reason the buyer should reply. Message shape is packaging, not the
+strategy. This contract exists because weak outputs can pass structural
+checks while still reading as AI-generated: they fill blocks, mention a
+sender, include a CTA, and never give the buyer a reason to care.
+
+### Pre-Draft Buyer-Role Analysis (HARD INVARIANT)
+
+Do this BEFORE writing angle drafts. This is an internal roleplay
+panel, not a tool call or subagent dependency. The goal is to prevent the
+generator from drafting first and rationalizing later.
+
+The panel has three roles:
+
+- **Buyer-role reader:** roleplay the basis-row buyer using only the
+  brief, lead review, lead sample, and filter. Ask "why would I care,
+  what would confuse me, and what would make me reply?"
+- **Offer-clarity critic:** translate the campaign into the actual offer:
+  what the recipient can do, what the product does, what burden the
+  product removes, and what the next step gives them.
+- **Gold-standard editor:** compare the proposed strategy to the Primary
+  Example and block anything that is less believable, less clear, or more
+  self-centered than the gold-standard motion.
+
+Before drafting, answer these five questions explicitly:
+
+1. **Who is sending it?** Identify the sender voice and what the body must
+   make clear without a body-level self-introduction.
+   - If explicit sender data exists in the brief or input artifacts, use it
+     as context for voice, proof, and buyer relevance.
+   - If the explicit sender is the founder/operator, use `I` / `we` when
+     referencing sender proof. Never refer to the sender as `the founder`,
+     `the CEO`, or a third-party person in the selected winner.
+   - If no sender is specified, assume a company-side growth/operator is
+     sending on behalf of the company. Use `we`, `our team`, `our CEO`, or
+     `our founder` only when the proof is explicitly supported. Do not
+     invent a founder-sender voice.
+2. **What is the actual offer?** State the offer in one plain sentence.
+   A product category is not an offer. A feature list is not an offer.
+3. **Why should this buyer care?** Name the buyer-side outcome, pain, or
+   curiosity that makes a reply plausible.
+4. **What proof makes it believable?** Pick the one proof beat that
+   answers the buyer's biggest skepticism.
+5. **What is the lowest-friction true next step?** Use only a next step
+   supported by the inputs.
+
+Then choose the exact element pool that angle drafts are allowed to use:
+
+- 3-5 sender relevance options
+- 3-5 buyer problem options
+- 3-5 offer sentence options
+- 3-5 mechanism sentence options
+- 3-5 proof uses, each classified as `body-worthy`, `translated`,
+  `CTA-asset`, `PS-worthy`, or `internal-only`
+- 3-5 CTA options, including a single ask and A/B only if both choices
+  are genuinely useful
+- 0-3 PS options, including `no PS` as a normal winning option
+- phrases/angles to avoid
+
+Before drafting, convert the winning element set into a **Message Element
+Plan**. This is not a named template. It is the concrete list of pieces
+the final message is allowed to use:
+
+- base reusable pieces: sender relevance, buyer problem, product / offer,
+  mechanism, proof treatment, CTA, and optional PS
+- optional sample-derived personalization pieces from `lead-sample.json`
+- exact slot for each optional personalization piece: opener, soft bridge,
+  proof, CTA, or omit
+- casing / voice style for the whole message
+- whether each proof belongs in the body, PS, CTA artifact, or nowhere
+
+Base reusable pieces are not personalization. Row personalization should
+come from the sample only when it makes the message more believable, more
+relevant, or easier to picture. If the message only works because the
+basis row has a special detail, it is not ready for campaign use.
+
+If the panel cannot produce a clear sender voice, actual offer, buyer
+care reason, believable proof, and true CTA, do not draft candidates.
+Return `revise-message` with the missing strategy pieces.
+
+### CTA / PS decision rules (HARD INVARIANT)
+
+CTA and PS are tools, not defaults.
+
+CTA options must be scored before drafting. Use `two options:` only when
+both choices are genuinely useful and supported:
+
+- option A gives the buyer a useful conversation or walkthrough
+- option B gives a concrete self-serve asset, proof artifact, overview,
+  video, report, or meta-demo
+
+Do not add option B just to mimic a gold standard. If the second option
+is weak, use one CTA.
+
+For artifact/sample offers, the CTA should usually be one self-contained
+yes/no question that names the concrete thing the buyer gets. Do not split
+the ask into a setup sentence plus a vague question.
+
+Good shapes:
+
+- `Open to a small redacted sample you can compare against your queue?`
+- `Can I send over a small redacted sample you can compare against your queue?`
+- `Open to seeing one example against your own workflow?`
+
+Weaker shapes:
+
+- `Want me to send a small redacted sample?` unless the sender voice is
+  intentionally casual/operator-ish
+- `Happy to send a small redacted sample... Worth a look?`
+- `Happy to send it over. Open to a quick look?`
+- `Worth a look?` when the object of "it" is not in the same line
+
+The buyer should be able to reply `yes` without deciding what yes means.
+The CTA should feel open-handed, not like the sender is asking for a favor
+or permission to do work. Prefer `open to...` or `can I send...` for
+artifact/sample offers.
+
+For unfamiliar or new categories, do not use abstract artifact asks like
+`setup link` unless the buyer can already picture what that means. Prefer
+a short preview CTA that names the buyer-specific outcome in one phrase,
+not a list of screens. Example shape: `worth seeing what this would look
+like for your own [buyer-owned thing]?`
+Prefer `open to seeing...` over `worth seeing...` when the CTA is a
+low-pressure preview of what the buyer would get. It reads more
+open-handed and less like the sender is asking the buyer to judge value
+before seeing anything. Default preview shape: `open to seeing what this
+would look like for your own [buyer-owned thing]?`
+
+For new categories, the CTA object should be the buyer outcome or preview,
+not the artifact. `send the setup link` is usually weaker than `worth
+seeing what this would look like for your own [buyer-owned thing]?`
+
+PS is optional and rare. Use a PS only for one of these jobs:
+
+1. **Commitment-lowering aside** when the CTA could feel like a big
+   commitment. Shape: `p.s. no pressure to [big commitment]. thought it
+might be useful to see [small preview].`
+2. **Concrete preview aside** when the category is new and the buyer may
+   not know what they are agreeing to see. Shape: `p.s. happy to show the
+[specific side of workflow] too.`
+3. **Proof-as-wink aside** when the PS naturally verifies the core claim
+   without sounding like a credential dump. Shape: `p.s. yes, [this
+message / artifact] was made with [product].`
+4. **Customer/result proof aside** when one short peer result makes the
+   message more believable but would bloat the main body.
+5. **Legitimacy aside** when the buyer is enterprise, regulated, high
+   trust, or being asked to try a new category / platform where durability
+   and trust matter. Backing like YC is often `PS-worthy` here because it
+   lowers "is this real?" / "will this company be around?" risk without
+   bloating the body. Its job can be legitimacy, not direct persuasion:
+   it answers whether the company and offer are real enough to take a look.
+   It must still tie the backing to the buyer segment, product boundary, or
+   buyer outcome instead of flashing a badge. Shapes:
+   `p.s. we're YC-backed and built for [specific buyer segment] trying to
+[buyer outcome].` or `p.s. we're backed by [credible backer] and focused on
+[specific buyer segment / problem].` Keep it short and test it against no-PS.
+
+If YC, notable backing, funding, or named investor proof is present AND
+the buyer is in healthcare, financial services, security, enterprise, or
+another high-trust category, you must test one PS version unless the
+brief explicitly forbids backing proof. Do not omit it solely because the
+main CTA is single and low-pressure. Omit only if seeing it in the PS
+makes the note feel more badge-flashy, less human, or less reply-worthy.
+Testing a PS is not permission to keep it. No-PS should beat a weak
+backing PS. A bare batch/name tag like `P.S. YC F24.`, `p.s. YC W26`,
+`p.s. we're YC-backed`, or `p.s. backed by [investor]` is an automatic
+loser because it makes the reader do the work. If backing proof cannot
+tie to the buyer outcome in one natural sentence, omit it.
+
+### Legitimacy proof gate (HARD INVARIANT)
+
+Before selecting the winner, ask whether the prospect's likely objection is
+not "do I want this?" but "is this real and safe enough to engage with?" This
+is common for healthcare, finance, security, enterprise, compliance, clinical,
+employment-sensitive, and new-category offers.
+
+If yes, identify the hardest-to-fake proof available and decide whether it
+belongs in the body, PS, CTA artifact, or internal notes:
+
+- hard-to-fake proof: YC/backing/batch status, verified credentials or
+  licenses, public company/profile pages, live product artifacts, named public
+  customers/results, audited/compliance artifacts, or a concrete product flow
+  the buyer can inspect
+- easy-to-claim proof: broad outcome promises, "we can get you X", vague AI
+  automation claims, unsupported speed claims, or internal traction without
+  context
+
+Use hard-to-fake proof when it makes the offer feel legitimate. Do not force
+it to answer the buyer-outcome "so what?" by itself. Its job may simply be:
+this is a real company / real product / real regulated workflow. Still avoid
+defensive wording like `legit`, `real operation`, `not a side project`, or
+`not a scam`. Let the proof carry the trust quietly.
+
+6. **Light human/humorous aside** when it reduces awkwardness or friction
+   without becoming the reason to reply. Test only when the tone can stay
+   professional and the buyer would not read it as unserious. Never force
+   humor into healthcare, finance, security, legal, compliance, or other
+   high-trust contexts if it weakens trust. Humor must be optional and
+   easy to delete.
+
+Do not use PS to explain why the pitch is credible, defend the message,
+summarize the strategy, add a second offer, or patch a weak body. If the
+PS sounds like internal reasoning, delete it.
+
+### Raw proof translation test (HARD INVARIANT)
+
+Before placing any numeric or traction proof in the selected winner, ask:
+
+1. Does the buyer immediately know whether this number is good?
+2. Does the number answer their likely objection?
+3. Would the sender say this exact line to a peer in a cold note?
+4. Does the line make the buyer more likely to reply, or just make the
+   sender sound active?
+
+If any answer is no, the proof is not body-worthy. Translate it to the
+buyer-relevant meaning or keep it internal.
+
+Do not decide proof placement abstractly. When a proof element might help,
+draft versions that use it in different ways:
+
+- raw proof in the body
+- translated proof in the body
+- proof as CTA asset / proof artifact
+- proof as PS
+- no explicit proof
+
+Keep the proof only if seeing it inside the message makes the final copy
+clearer, more believable, or more reply-worthy. If the raw proof wins, it
+must still sound like something the sender would actually say and must make
+the buyer care more than the translated/no-proof version.
+
+Allowed translation shapes:
+
+- `I'm already using it with my own [workflow/customers/patients].`
+- `This is already live, not a concept.`
+- `We've seen this work with [peer/customer] for [buyer-relevant result].`
+
+Blocked raw proof shapes:
+
+- `[number] interactions in my first [time window]`
+- `[number] users/customers/leads in [time window]`
+- `[dollar amount] revenue math`
+
+Those shapes are allowed only when they beat the translated/no-proof variants
+and the line explains why the number matters to this buyer in plain language
+while still sounding human.
+
+### Line-level "so what?" gate (HARD INVARIANT)
+
+Before `confirmed`, inspect every line in the Selected Winner from the
+prospect's perspective.
+
+For each line, write the prospect-side answer to: `so what? why should I
+care about this line?`
+
+Keep the line only if the answer is compelling and immediate. If the answer
+is weak, meta, internal, or "because the brief says it is true," rewrite,
+move, or cut the line.
+
+This applies to:
+
+- sender relevance
+- buyer pain
+- offer
+- mechanism
+- proof
+- CTA
+- PS
+
+Truth is not enough. The line must do a job for the prospect.
+
+Use the 4-block shape below as the default packaging only when it helps
+the reply reason land. If a different shape is more natural, shorter, or
+more compelling for this offer, use it and explain why in `Packaging
+Rationale`. What cannot change: the winner must make the strongest true
+reason obvious, avoid AI tells, and end with a useful reply path.
+
+### Gold-standard quality gate (HARD INVARIANT)
+
+`confirmed` means the selected winner is good enough to sit next to the
+primary runtime gold example without sounding like a weaker AI copy of it.
+Do not mark `confirmed` just because headings, candidates, token tables,
+and a Finalizer Pass exist.
+
+Before `confirmed`, run the selected winner against these gates:
+
+- **Believability:** a real sender could plausibly type every line in
+  LinkedIn without sounding like a landing page, resume, or pitch deck.
+- **Sender relevance:** the message answers why this sender is relevant to
+  this buyer and offer. Resume intros are blocked, but sender identity is
+  allowed when it explains the buyer problem, product origin, or why the
+  offer exists.
+- **Non-assumption:** the opener does not assert what the buyer wants,
+  feels, needs, or is trying to do unless the exact fact is grounded in
+  the lead sample. If desire is inferred, use tentative framing like
+  `not sure if this is relevant, but...`, `thought this might be
+relevant if...`, or `if you've ever wanted...`.
+- **Buyer-first opener:** after the greeting, the first substantive line
+  should usually enter the buyer's world: a real signal, current-state
+  pain, buyer-owned priority, or useful artifact. Sender-origin can come
+  first only when it directly names the buyer-relevant mechanism or proof.
+  If the opener reads like autobiography before the buyer knows why they
+  should care, it is BLOCKED.
+- **Visibility-gap opener for intelligence products:** when the product sells
+  data, intelligence, signals, or enriched evidence, use permissioned
+  relevance unless the lead row proves the claim. The opener should make the
+  buyer feel selected, not diagnosed. Do not write `you already have...`,
+  `your team already sees...`, `you probably...`, or `the gap is...` unless
+  that exact fact is present in `lead-sample.json`. Default shapes:
+  `not sure if this is relevant, but if [workflow] still depends on [limited
+input], [product] might help with [missing input]`; `thought this might be
+useful if [buyer] is looking for [missing signal]`; `not sure if useful,
+but [product] is built around [gap]`. This usually beats broad
+  loss/problem language because it makes the artifact valuable without
+  sounding like the whole problem is solved.
+- **Basis-row fit before category fallback:** a function-level opener must
+  still make immediate sense for the named basis row. If the basis row gives
+  a clear role, company type, geography, or accountability, prefer a plain
+  row-fit bridge over a broad category opener. Category-level openers like
+  `Most [category]...` are last-resort fallbacks only; they are BLOCKED when
+  the resulting line is vague, overly broad, or would make the named buyer
+  ask "why are you saying this to me?"
+- **No proof-first opener:** when there is no strong row-specific signal,
+  the first substantive line should normally start from a buyer-owned
+  condition, not a sender-owned subject. Opener proof/origin lines that
+  start with `I`, `I'm`, `I've`, `my`, `we`, `our`, `pre-`, or `before`
+  are BLOCKED unless the same line is only a conversational hedge like
+  `we haven't met` and immediately moves into the buyer's world. Put
+  operator proof after the buyer pain.
+- **No resume intro:** any line shaped like `I'm a [credential/title] and
+co-founder of [company]` is BLOCKED when it functions as a standalone
+  introduction. Sender identity is allowed only when it connects directly
+  to buyer relevance, the product origin, or the offer. The LinkedIn UI
+  already shows who sent the message; the body must explain why that
+  matters.
+- **No bare founder intro:** a standalone line shaped like `I'm [name],
+co-founder at [company]` is also BLOCKED unless the same line explains
+  why the sender matters to this buyer. Prefer opening on the
+  buyer-relevant offer, mechanism, or operator origin. The sender card
+  already handles name/title.
+- **Attribution clarity:** every operator-history or resume-history line
+  must make it obvious who the fact belongs to: sender, recipient, or
+  recipient company. Subjectless lines like `spent years as...`,
+  `before [company]...`, or `scaled [company]...` are BLOCKED when a cold
+  reader could misread them as the sender's background or the recipient's
+  background. Recipient history can appear only when the exact fact is
+  present in `lead-sample.json`; otherwise keep it out. Sender history can
+  appear only when it is explicitly tied to the buyer problem in the same
+  sentence and still passes the buyer-first / no-resume gates.
+- **No third-person sender:** if sender data identifies the sender as the
+  founder/operator, the selected winner must not refer to that same person
+  as `the founder`, `the CEO`, or another third-person role. Use `I` or
+  `we` and tie the proof to buyer relevance. If no sender is specified,
+  do not invent first-person founder proof; use company-side operator voice
+  (`we`, `our team`, `our CEO/founder`) only when the proof is supported.
+- **No weak identity-call CTA:** founder-to-founder, MD-to-MD,
+  doctor-to-doctor, peer-call, compare-notes, and similar identity-call
+  CTAs are BLOCKED unless the user explicitly selected that motion or the
+  brief names it as the approved offer. A buyer should not have to care
+  about the sender's identity to understand the value of saying yes.
+  Prefer CTAs that name a concrete useful return, such as a setup preview,
+  workflow teardown, sample artifact, or walkthrough of their own likely
+  use case.
+- **No founder-name hook:** do not use the sender/founder first name as the
+  reason to open, read, or reply. Subject lines like `Austin's review`,
+  `{{founder_name}}'s teardown`, or `founder call` are blocked because the buyer
+  does not yet care who the founder is. The CTA can mention a named founder only
+  if the name adds trust or the user explicitly requested named-founder branding.
+  Default to the useful return artifact: `map one reporting problem`, `review
+one dashboard`, `pressure-test one workflow`, or equivalent.
+- **Element discipline:** the winner must follow the Message Element Plan.
+  Base pieces stay reusable across the segment. Optional row-personalization
+  pieces must be sourced from `lead-sample.json`, placed deliberately, and
+  removable without breaking the message.
+- **Personalization for believability:** row tokens are not just decoration.
+  If a generic line would become more believable, more relevant, or easier to
+  picture by using a safe row token, the draft must test that version. This is
+  especially true when the base copy says `without quitting`, `your current
+company`, `companies like yours`, `teams like yours`, `your workflow`,
+  `hiring [role]`, `your [function] team`, `your market`, or similar generic
+  context and `lead-sample.json` has a current company, role, account type,
+  market, hiring signal, team/function, or workflow signal. Good token usage is
+  neutral and grounding: `without leaving {{company}}`, `for your
+{{role_specialization}} team`, `if you're hiring {{hiring_role}}`, `for
+{{account_segment}}`, or a CTA like `open to seeing what this would look
+like alongside {{company}}?`. Block row tokens when they sound scrape-y,
+  create legal / employment anxiety, blame the employer, imply employer
+  approval, or do not change the reply reason. Generic substitutes like `your
+group`, `your company`, `your team`, `a role like that`, or `companies like
+yours` are not enough when a safe row token would make the line feel more
+  grounded. First test the tokenized version. If the raw field is too long,
+  noisy, or awkward, create a natural row-derived context token such as
+  `{{employer_context}}`, `{{hiring_role}}`, `{{role_specialization}}`,
+  `{{workflow_context}}`, or `{{account_segment}}` with a clear fill rule
+  (`{{company}}` when clean, otherwise `your group`; exact hired role when
+  clean, otherwise `the role you're hiring for`). If the final winner contains
+  row-dependent context and uses neither the exact token nor a row-derived
+  context token, it must explain why the token would be unsafe or less
+  believable. "Generic reads cleaner" is not enough. If a safe token would
+  improve fit-believability and the winner omits it, the gate is BLOCKED.
+  If the final copy contains generic row-context phrases such as `your
+  employer`, `your current group`, `your team`, `your company`, `the role`,
+  `the open role`, `your workflow`, `that process`, or `companies like yours`
+  and the row has the matching context, the generic phrase itself must usually
+  become a token (`{{employer_context}}`, `{{team_context}}`,
+  `{{hiring_role}}`, `{{workflow_context}}`, `{{account_segment}}`) with a
+  clear fill rule. Do not write generic row-context phrases in the final copy
+  and then say personalization was omitted. The exception is when even the
+  derived token creates safety risk or makes the sentence less believable; if
+  so, cut the row-context phrase rather than leaving it generic.
+- **Token restraint:** personalization that makes the sentence clunkier is worse
+  than no personalization. Tokenized lines such as `Reaching out because
+{{reporting_context}} sits in the kind of reporting ownership...`, `your
+{{role_context}} work`, or `noticed your {{topic}}` are BLOCKED when the filled
+  version sounds like mail merge. A good token should either make the sentence
+  more concrete in normal language or be omitted. If the row signal is weak,
+  write the segment-level line and document the omit rule.
+- **No internal profile-signal token:** `{{profile_signal}}` is never allowed
+  in customer-facing copy, message-review templates, rendered examples, token
+  notes, or approval-packet message bodies. It names how enrichment classified
+  the row, not what a buyer would recognize. Use a concrete field or a
+  row-derived token with a clear fill rule (`{{workflow_context}}`,
+  `{{source_post_topic}}`, `{{row_proof_note}}`) and only keep it when the
+  rendered sentence sounds natural.
+- **Product clarity:** the product noun must be plain enough that a cold
+  reader can say what happens. `chat clinic` by itself is not enough
+  when the buyer would reasonably ask "what does that mean?" Prefer
+  concrete mechanics like patients subscribing to the doctor, async
+  photo/chat follow-ups, credentialing, billing, or malpractice coverage
+  when those are the actual differentiators.
+- **Selling clarity:** if the message is selling or introducing something,
+  the body must clearly say what it is before the ask. The CTA can be
+  simple and call-based only after the offer is clear. Good shape:
+  `this is what it is` -> `why it might matter to you` -> `if that would
+be remotely helpful, open to a quick call / preview?`
+- **Clarity over completeness:** accurate does not mean exhaustive. If a
+  technically fuller sentence is harder to parse than a simpler true sentence,
+  choose the simpler sentence. Do not include every supported caveat, category
+  term, or mechanism detail in message 1 unless it directly increases reply
+  likelihood.
+- **Buyer-identity fit:** when the recipient already has the credential,
+  role, or identity required by the offer, do not describe the product as
+  serving `a [role]` in a way that makes the buyer feel outside the group.
+  Generic lines like `lets a board-certified derm...` are BLOCKED when the
+  basis row is already a board-certified dermatologist. Use `you`,
+  `[role]s like you`, or a direct product-category line instead. The
+  recipient should feel "this is for me specifically," not "this is for a
+  category I happen to be in." Prefer respectful full role terms by default
+  (`dermatologist` over `derm`, `physician` over `doc`) unless the brief or
+  gold motion proves the abbreviation is buyer-native.
+- **No product tautology:** a product definition line cannot merely say
+  `[Product] is a [category] on [Product]` or `It's a [category] on
+[Product]`. The line must explain what the buyer can do, who uses it,
+  what changes, or how the mechanism works.
+- **Proof naturalness:** supported proof is not enough. The selected proof
+  must make the message clearer, more believable, or more reply-worthy in
+  plain human language. If the raw proof sounds weird, vanity-like,
+  founder-braggy, or confusing, it must be translated or kept internal.
+  Ambiguous metric lines are blocked when the buyer cannot tell why the
+  number matters without extra explanation.
+- **Proof strength:** `spoken publicly about`, `publicly talked about`,
+  `trusted by`, `worked with`, `used by`, and bare customer-logo lists are
+  BLOCKED as body proof when they do not say what changed for the buyer. A
+  usable proof line should compress a concrete result, mechanism, or risk
+  reducer. If the honest version is only "these logos exist", omit it from the
+  message and keep it in Findings.
+- **Proof tie-breaker:** choose one main body proof. If two proofs answer
+  different objections, pick the one that removes the biggest reply blocker
+  for this buyer. Put the second proof in PS only if it lowers vendor or
+  category risk in one natural aside; otherwise keep it internal and note it
+  in Findings. Do not loop over whether to use both.
+- **Customer proof placement:** when customer/logo proof is useful mainly for
+  legitimacy, put it in a short PS instead of interrupting the body. The body
+  should carry buyer pain, mechanism, and CTA. The PS can carry one concrete
+  proof sentence if it names what customers used the product/service for, e.g.
+  `p.s. Schindler used CaseWhen for team training, ZBI/Union Investment for
+internal Power BI resources, and Peek & Cloppenburg for unified customer
+reporting.` Do not write a PS that is only a logo list. Do not label the PS
+  with internal phrases like `relevant proof:`, `useful proof:`, `proof:`, or
+  `social proof:`.
+- **Weak early-traction proof:** small-N or early-window proof like
+  `140 interactions in my first 2 weeks`, `first two weeks`, or similar is
+  BLOCKED unless it directly lowers a specific buyer objection. Treat the
+  raw number as internal-only by default. Do not soften it into a nearby
+  invented claim like `over 100 patient interactions` or re-litigate it in
+  later passes. If the number mostly proves the sender is using the
+  product, use the softer founder-dogfood proof (`I use it myself with
+real patients`) or omit proof entirely.
+- **Read-aloud exactness:** every phrase in the selected winner must
+  sound like something the sender would actually say out loud. Awkward
+  shorthand such as `board-cert derms`, internal/product shorthand, or
+  phrases that only make sense after reading the brief are BLOCKED.
+  Compressed strategy phrases are also BLOCKED when they feel like internal
+  labels instead of buyer-language. Do not overfit to an exact banned list:
+  judge whether the phrase would sound natural from this sender to this
+  recipient, then rewrite into plain sender intent or buyer benefit.
+- **Zero-parse-friction:** every word and phrase should clearly make sense
+  on first read. If the recipient has to pause for even a second to decode
+  what a phrase means, who it refers to, why it matters, or how it connects
+  to the offer, the phrase is BLOCKED. Replace clever, compressed, or
+  abstract bridge/PS wording with the plain thing it means. Judge this from
+  the basis row's seat, not from the brief. If a term is only clear after
+  reading the campaign thesis (`rails`, `queue`, `trust-based`, `motion`,
+  `lane`, etc.), either anchor it to a concrete buyer context or use simpler
+  language.
+- **Operator proof naturalness:** operator-background proof must answer
+  "why should this buyer trust this sender on this exact pain?" without
+  sounding like resume chronology. Standalone lines shaped like
+  `pre-[company], I scaled...`, `before [company], I...`, or
+  `I built/scaled [company] into...` are BLOCKED unless the same sentence
+  ties directly to the buyer's current workflow pain. Prefer conversational
+  proof like `we ran into this constantly at [operator company]` or
+  `saw this at [operator company] too`.
+- **No vague fragment lines:** short fragments are allowed only when they
+  add human rhythm and concrete meaning. Generic fragments such as
+  `same back-office pain every week`, `same problem every time`, or
+  `exactly why we built this` are BLOCKED unless the surrounding line names
+  the specific buyer-owned problem.
+- **Jargon / acronym exactness:** use buyer-native acronyms only when the
+  brief or sample supports them, and place them in concrete sentences.
+  Avoid abstract glued phrases like `APP-fraud exposure`, `attacker-
+infrastructure signal`, or `rails can match` unless that exact buyer
+  language is visible. Translate to plain mechanics when possible:
+  `matched mule accounts from APP scams` beats `APP-fraud exposure`.
+- **Mechanism focus:** when the product can do several workflows, the
+  first-touch winner should usually pick the most painful workflow and
+  make that one easy to picture. A single line that stacks three major
+  surfaces, such as orders + forecasting + inventory, is BLOCKED unless
+  the brief's actual offer requires the full bundle in the first ask.
+- **Style consistency:** choose one casing style before drafting and obey
+  it. Do not mix a formal bare-name greeting or sentence-case intro with
+  a lowercase body. If using casual lowercase common words, use a casual
+  greeting like `hey Kevin,` and keep the whole message in that style
+  while preserving proper nouns, acronyms, and `I`. If using `Hi Kevin,`
+  or writing to an enterprise/regulated buyer, use standard sentence case
+  throughout.
+- **No code fences around copy:** `## Selected Winner` must contain the
+  raw message only. Do not wrap the final copy in ``` fences or markdown
+  blocks; those are artifact formatting, not message copy.
+- **No mind-reading from signals:** if a line uses a post, topic
+  engagement, public activity, role, company, hiring trigger, or any
+  other row signal, it must describe the observable fact softly. It
+  cannot assert the buyer's internal priority, intent, focus, budget, or
+  urgency unless `lead-sample.json` states that exact fact. Phrases such
+  as `clearly on your mind`, `obviously focused on`, `already thinking
+about`, or `clearly relevant` are BLOCKED. Source-y phrases such as
+  `saw you on...`, `saw you around...`, and `saw you engaging with...`
+  are also blocked unless the archived winner explicitly depends on that
+  self-aware signal style. Translate the signal into low-certainty buyer
+  context instead: `not sure if this is relevant, but if [topic] is part
+of what you're testing...`, `this may be too specific, but [topic] felt
+close enough to send`, or a similarly natural line.
+- **No internal-metric flex:** internal process details are not proof by
+  default. Compute time, token/cache details, model names, number of
+  agents, orchestration internals, or `~5 min of compute per message`
+  are BLOCKED unless the brief proves the buyer already cares about that
+  exact operational detail. Translate to buyer value or cut. `runs inside
+Claude Code` can matter for Claude-native operators; `5 min of compute`
+  is usually a "who cares?" line.
+- **CTA truth:** the CTA cannot invent an artifact or action the brief
+  did not explicitly support. `spin up your clinic page`, `send a
+teardown`, `record a video`, or similar assets are BLOCKED unless the
+  input says that exact next step exists. When unsure, ask for the
+  lowest-friction true next step from the brief, such as sending the
+  setup link, next step, or a short walkthrough.
+- **CTA clarity:** if the product category is unfamiliar, the CTA must
+  make the preview easy to imagine in one short phrase. Avoid vague asks
+  like `send the setup link` unless the message has already made that
+  artifact concrete. For new categories, do not make the artifact noun the
+  object of the CTA; make the buyer outcome the object and use the artifact
+  only as the delivery mechanism if needed.
+- **Self-contained yes/no CTA:** for artifact, sample, preview, or audit
+  offers, the selected winner should end with one clear question whose
+  object is in the same line. Avoid `Happy to send...` plus `Worth a look?`
+  because it splits the ask and makes the buyer infer what yes means.
+  Prefer `Want me to send [specific artifact]?` or `Open to [specific
+artifact / preview] you can [use/check/compare]?`.
+- **CTA specificity:** generic CTAs like `compare notes`, `worth a chat`,
+  `open to a call`, or `quick walkthrough` are BLOCKED unless the same
+  line names the specific thing the buyer will compare, see, or get. The
+  next step must be easy to picture.
+- **Preview CTA wording:** when the CTA is a preview, prefer `open to
+seeing...` over `worth seeing...` unless the chosen gold motion strongly
+  supports `worth`. `Open to seeing what this would look like for your own
+[buyer-owned thing]?` is the default preview shape.
+- **Workflow-test CTA:** for ops / workflow products, prefer a CTA that
+  lets the buyer imagine testing the product on their own workflow or a
+  safe sample artifact. `worth seeing how this would handle one retailer
+PO from your inbox?` beats `worth 15 min to compare notes?` because the
+  buyer can picture what happens next.
+- **PS restraint:** if a PS appears, it must do one clear job:
+  commitment-lowering aside, concrete preview aside, proof-as-wink, or
+  tight customer/result proof. If it explains the strategy, defends the
+  pitch, or patches weak credibility, it is BLOCKED.
+- **YC / backing PS:** a PS that only says `we're YC`, `we're YC W26`,
+  `backed by YC`, or similar is BLOCKED as badge-flashing. If YC/backing
+  is used, the same sentence must either tie to the buyer segment/outcome
+  (`we're YC-backed and trying to help banks stop scam money before it
+moves`) or materially lower commitment (`happy to send the sample
+without a call first`). Prefer the buyer-outcome version when both fit.
+  For high-trust or new-category offers, YC/backing should be tested as a
+  PS before being marked internal-only; the question is whether the PS
+  lowers trust risk for the buyer, not whether the body already has one
+  proof beat. Do not require YC/backing to be the strongest reason to care;
+  it can be kept when its main job is hard-to-fake legitimacy.
+  Defensive PS language is BLOCKED. Do not write `real operation`, `not a
+side project`, `serious company`, `legit`, or any line that argues with an
+  imagined objection out loud. The PS should sound like useful context, not a
+  rebuttal. Preferred shape: `p.s. we're YC-backed and trying to help
+[buyer segment] [buyer outcome].`
+  Batch-code PS lines such as `P.S. YC F24.` are BLOCKED. They are
+  badge-flashing and create no prospect-side "so what?" answer. If the
+  sentence cannot answer why YC/backing makes the next step safer or more
+  relevant for this buyer, choose no PS.
+- **Line-level so-what:** every selected line must have a compelling
+  prospect-side answer to "so what?" If a line is true but the prospect
+  would not immediately understand why it matters, it is BLOCKED until
+  rewritten, moved, or cut.
+- **Skeptical prospect:** the selected winner must survive a skeptical
+  prospect who has been prospected on LinkedIn by similar products hundreds
+  of times. If that reader would dismiss the note as founder story, vague
+  product pitch, anti-employer framing, generic proof, or unclear CTA, route
+  to `revise-message`.
+- **Brief framing obedience:** if the brief says to avoid anti-employer,
+  anti-competitor, anti-PE, or rebellious framing, any line that blames or
+  negatively characterizes the buyer's employer/current setup is BLOCKED.
+  Negative contrast lines are also blocked unless explicitly allowed:
+  `not a gig platform`, `not a faceless service`, `not built like X`,
+  `unlike [competitor/current setup]`, or `instead of [negative category]`.
+  State the positive buyer outcome directly.
+- **Gold-standard match:** the winner should preserve the quality of the
+  Primary Example: human opener, strongest supported proof, clear
+  mechanism, and a useful CTA. If the winner is materially weaker than
+  the Primary Example, route to `revise-message`.
+- **Template disguise:** if the selected winner contains bracketed
+  instructions, a placeholder paragraph, a "canonical template" label, or
+  any instruction for a later generation step to invent a row-specific
+  bridge, it is not a winner. Route to `revise-message`.
+- **Signal-token disguise:** if the selected winner contains a generic
+  `recentSignal` / `recent_signal` token, or a phrase like `caught my eye`
+  that hides a source citation, route to `revise-message`. The row bridge
+  must use concrete enriched-row fields or be omitted.
+
+If any gate fails, set status to `revise-message`, cite the offending
+line, and include the best corrected direction. Do not finalize a merely
+less-bad version.
+
+**Default Block 1 — Hey + buyer-relevant substance.** ~1-2 sentences.
+Establishes WHY THIS MIGHT MATTER (the buyer's current state, useful
+artifact, operator reality, or mechanism), NOT WHO THE SENDER IS. The
+LinkedIn UI already shows the recipient who sent the message (sender
+name, photo, headline), so the body should NEVER
+include `"X here"`, `"I'm Y"`, `"{{sender_name}}, {{title}} at
+{{company}}"`, or any self-identification phrase — those are
+Filter-8 violations. NEVER references the recipient yet either (no
+`{{first_name}} — saw you...`, no `Your X is...`). Open with what
+matters to the buyer or the operator-reality that led to it. Acceptable
+openers:
+
+- `Hey {{first_name}}, [one plain sentence about what we built].`
+- `Hey {{first_name}}, pre-[product], we [did the operator-reality
+thing] for [X] years; [one-line consequence].`
+- `Hey {{first_name}}, building a thing for [segment] I think you'd
+have an opinion on. My co-founder and I [did operator-reality
+thing] before this...`
+
+Unacceptable Block-1 openers (Filter-8 violations):
+
+- `Hey {{first_name}} — {{sender_first_name}} here.` (the `"X here"`
+  clause is a self-intro tell — the LinkedIn UI already shows who
+  sent the message)
+- `Hey {{first_name}}, I'm {{sender_name}}, co-founder at [company].`
+- `{{sender_name}}, [title] at [company]. We do [X].`
+
+**Default Block 2 — Mechanism.** ~1 sentence. What the product actually does
+in plain words. NOT a feature list. NOT a stack dump. NOT a
+parenthetical of tool names. Name ONE concrete action the product
+takes on the buyer's behalf, or the single most important class of
+work it handles.
+
+Block 2 must name the **product category / system class explicitly**,
+not just the actions. The reader should be able to answer "what is
+this thing?" after the sentence, not just "what does it do?".
+
+Required shape:
+
+- `[Product] is [category noun] that [does the key action]`
+- `it's an [AI receptionist / AI SRE / agent / platform / layer] that [does Y]`
+
+If no clean existing category fits, you may **coin a short category by
+analogy** — but only when it makes the buyer's mental model clearer on
+first read.
+
+Good coined-category shapes:
+
+- `it's like Claude Code for AppSec`
+- `it's an AI SRE for on-call teams`
+- `it's a control layer for outbound calling`
+
+Rules for coined categories:
+
+- anchor them to a category or product the buyer already understands
+- keep them short enough to say in one breath
+- prefer clarity over cleverness
+- if the coined label sounds hype-y, abstract, or investor-pitchy, cut
+  it and fall back to the plain category noun
+- do not coin a category if the plain one is already clear enough
+- do not stack two analogies in the same sentence
+
+Not acceptable:
+
+- `we pick up the calls your front desk misses...`
+- `it books into your PMS and verifies insurance...`
+- `we investigate incidents before you wake up...`
+
+Those lines can follow the category sentence, but they cannot replace it.
+
+For technical / operator motions, Block 2 must stay especially tight:
+
+- do not laundry-list 3-4 vendor names in the body just because the
+  brief allows them
+- name the category noun or system class first (`"it's an AI SRE"`,
+  `"it's an AI receptionist"`, `"it's a lightweight layer"`) before
+  listing any action
+- when a coined category is genuinely clearer than the plain noun,
+  coin it once and then move straight to the action. Example:
+  `"it's like Claude Code for AppSec — it ..."` not a full analogy
+  paragraph
+- name the system class or workflow first (`"works inside the on-call
+thread"`, `"investigates incidents before a human wakes up"`,
+  `"books straight into your PMS"`)
+- mention at most **one** buyer-native tool name inline unless the row
+  signal itself makes a specific tool the reason the note is relevant
+- if the mechanism needs more than one clause to make sense, the product
+  explanation belongs in the later "what the product DOES" breakdown,
+  not in a glued Block-2 sentence
+
+**Default Block 3 — Soft bridge to recipient.** ~1 sentence. Light callback
+to a row signal, paraphrased and casual. NEVER a verbatim block
+quote with quotation marks. NEVER `"your profile says"` or `"the
+post you wrote on [date]"`. Frame as natural memory:
+
+- `"Thought of {{company}} because..."`
+- `"Feels relevant to the [area] work you've been doing."`
+- `"Saw you're working on [area]."`
+- `"You've been writing about [paraphrased topic], which is almost
+exactly what we built around."`
+
+If the row has no usable signal, Block 3 becomes a peer observation
+(`"feels relevant to the shape of what you're doing at
+{{company}}"`), not a broadcast `"most [segment] teams see..."`
+opener.
+
+**Default Block 4 — Low-pressure CTA.** ~1 sentence. Casual founder cadence:
+
+- `"Worth 20?"`
+- `"20 min sometime?"`
+- `"Could grab time this week or next?"`
+- `"Open to a quick chat?"`
+
+NOT `"Worth a 20-min walkthrough?"`, NOT `"Let's set up a meeting."`,
+NOT `"reply if you want a quick walkthrough"` unless the line names what
+the buyer will see or get, NOT `"We're picking 2 Q1 2026 pilot partners — would you like to
+be one?"` (over-precise numerics trip Filter 6).
+
+Default to a **single** CTA line. Use `two options:` only when both are
+true:
+
+1. the chosen archived motion is genuinely A/B
+2. Option B is a concrete self-serve asset, proof artifact, or
+   meta-demo that is clearly stronger than an ordinary reply ask
+
+If either condition fails, keep one low-pressure CTA.
+
+`Single CTA` means **one next step only**. Do not smuggle a second option
+into the same line with `or i can send...`, `or happy to share...`, or
+similar fallback phrasing unless the motion is explicitly A/B.
+
+Do not use pilot-slot scarcity, quarter labels, or exact slot counts in
+the CTA by default (`"2 Q1 pilot partners"`, `"3 beta slots left"`).
+Only keep scarcity when the archived motion truly depends on it and the
+brief makes that scarcity central to the offer.
+
+**Body proof density.** The body gets one main proof beat by default.
+If the message already has a strong sender-reality opener and clear
+mechanism line, do not also stack integration count, deployment detail,
+open-core detail, and audit-trail detail in the same note. Keep the
+single strongest proof treatment in the body; move the rest to an optional PS
+only if it materially increases fit-believability, or keep it internal when it
+would make the message less natural.
+
+**NO signoff line.** See next section.
+
+### NO SIGNOFF LINE (HARD INVARIANT — multi-sender hardening)
+
+Generated messages MUST NOT include a signoff line. Reject any
+candidate body that ends with:
+
+- `— {{sender_name}}`
+- `— Jimmy (co-founder, IncidentFox)`
+- `Best, [name]`
+- `Cheers, [name]`
+- `Thanks, [name]`
+- any line of the shape `[em-dash or punctuation] [first name] [role
+in parens]`
+
+Reasons this is a HARD INVARIANT:
+
+1. **Multi-sender pipelines.** The same message template may be
+   dispatched from multiple LinkedIn sender accounts. A hardcoded
+   founder name breaks personalization across senders — the message
+   literally has the wrong name when sent from a different account.
+2. **LinkedIn already shows sender identity.** The recipient sees
+   who sent the InMail from the LinkedIn UI itself (profile photo,
+   name, headline at the top of the thread). A signoff line is
+   redundant at best, incorrect at worst.
+3. **Gold-standard archive behavior.** The Revvix, Galley, Superpower,
+   and Superposition winners archived in
+   `gold-standard-message-examples.md` do NOT include hardcoded
+   signoffs — they end on the CTA. Match the archive.
+
+**Token exception:** if a `{{sender_name}}` variable is templated into
+the body (e.g., as part of a PS referencing the sender's role), it
+must appear inline with context, not as a trailing line. Example:
+`"Our CEO [did X]"` is fine. `"— [Name]"` as the last line is
+rejected.
+
+**Validator token-adherence check:** the `message-validation.md`
+Token Adherence Table must include a column or row-level assertion
+`"No signoff line: YES"`. If a candidate ships a signoff, mark it as
+a BLOCKED candidate (Filter 7 / Anti-talk-at also applies since the
+signoff is a talk-at shape).
+
+### Voice rules
+
+**Reading level (default = plain English)**
+
+- write at a 5th-grade reading level by default, even when the brief is technical
+- prefer short common words over industry jargon. "Orders come in by email" beats "sales order intake workflow." "It works on top of what you already use" beats "deploys as an overlay on the existing stack"
+- when the brief uses a piece of jargon (e.g. "Shopify"), keep the product/tool name exactly; the jargon to cut is the glue language around it
+- Casing must look intentional. Lowercase casual style is allowed for common words when the chosen motion uses it, but proper nouns, recipient names, company names, product names, acronyms, and the pronoun `I` stay capitalized. Do not output broken casing like `i'm`, `futureclinic`, or `michael`. Do not lowercase token values or invent transform syntax like `{{company_lower}}`, `{{first_name | lower}}`, or bracketed casing instructions; use the row value as a proper noun, or omit the optional token line if the value does not fit.
+- the only time a higher reading level is allowed is when the archived winner for this motion is the **same company** as the brief and the winner deliberately uses denser language (e.g. Superposition drafting for Superposition). In every other case, plainer language wins
+
+**Sentence and line shape**
+
+- **each sentence is its own paragraph** — put a blank line between every sentence in the body, even short ones
+- literally: the body should render as a sequence of one-line paragraphs separated by blank lines, not as multi-sentence paragraphs
+- this matches the archived winners (Revvix, Galley, Superposition all paragraph-break per sentence). It gives the reader one idea at a time and lets short sentences breathe
+- mobile scanability is a hard requirement. The winner should read cleanly in a one-thumb scroll on a phone
+- keep most sentences in the **6-14 word** range. If a sentence is above ~18 words or has more than one comma, split it
+- the whole body target is about 6-10 one-line paragraphs, **not** 3 multi-sentence paragraphs
+- if a line would wrap into a heavy 3-line block on mobile, cut or split it
+- keep the CTA as its own short line. In most cases the CTA should be **4-10 words**
+- **the PS is a single paragraph.** Its one or two sentences stay on the same line (or at most a soft line break between them — never a blank line). Every other sentence in the body gets its own paragraph; the PS does not
+
+**Product clarity (non-negotiable)**
+
+A cold reader of the message must be able to state, in one sentence, **what the product does** — in plain English, without re-reading the pain section to infer it.
+
+This rule is violated when the mechanism gestures at "that chain," "the stack," or "that work" without naming the specific actions the product takes. If the reader has to infer what the product does from context, the copy fails.
+
+Flow skeleton (apply even when motion varies):
+
+1. Opener anchored in the buyer's workflow
+2. Pain — what's breaking now
+3. **What the product IS** — one crisp sentence naming the product and what category of work it takes on. Example shape: `[Product] is [a category-noun] that [takes a specific class of work off the buyer's plate]`. When the offer is for the buyer's exact role/credential, prefer `lets you...` or `[role]s like you...` over `lets a [role]...` so the buyer does not feel treated like an outsider. Archive-anchored illustrations: Galley's "AI that reads the messiest BEOs and turns them into production-ready plans"; Revvix's "shows what's actually exploitable on your endpoints based on runtime activity".
+4. **What the product DOES** — one action per line. Three actions maximum. Choose the rendering by a **concrete test**, not a feeling:
+   - **Use bullets when the action lines are maximally parallel**: each starts with the same subject (e.g. `It X` / `It Y` / `It Z`), each is a discrete product function, none carries narrative context. This is the default case.
+     - Example shape: `- [Verb] [concrete object from the buyer's workflow].`
+   - **Use one-line paragraphs only when at least one action carries a short narrative clause** that wouldn't fit cleanly in a bullet.
+   - "Conversational motion" is **not** a reason to prefer paragraphs. If the three actions all start with `It X`, they are parallel by definition and should render as bullets.
+   - Never stack the three actions into one glued comma-list sentence.
+5. Deployment ease — one short paragraph
+6. CTA — useful next step, binary when the brief supports it
+7. Optional PS — only if it materially strengthens the fit case
+
+Rules within the flow:
+
+- **banned**: comma-stacking three actions into one glued sentence (e.g. `"order intake, inventory sync, and reorder timing"` glued together). Split into one action per line.
+- **preferred**: one action per line — as one-line paragraphs or as a bullet list, whichever reads cleaner (see below)
+- the "what the product IS" sentence comes **before** the action breakdown — skipping it makes the actions feel disconnected
+- if the brief does not support three distinct actions, drop to two or one. Do not pad.
+- if a proof sentence gets long, split the metric and the explanation into separate one-line paragraphs rather than chaining them together
+
+**Per-lead signal must appear when available**
+
+Category-level openers of the shape `"Most [category] teams still do X by hand"` read as mail merge at the lead level, even when `{{category}}` is tokenized per lead. They are only acceptable when `lead-sample.json` carries zero per-lead signal for this lead.
+
+Rules:
+
+- if `lead-sample.json` carries **any** per-lead signal for this lead — a recent post, a recent hire, a visible tool in the headline, a topic engagement, a public initiative — the **message must reference it specifically**. Category-level copy is rejected.
+- default placement is **Block 3**, not Block 1. Keep Block 1 substance-first unless the archived motion clearly earns a signal-led opener without falling into source-citation / talk-at phrasing.
+- acceptable signal use by default:
+  - `"Not sure if this is relevant, but if [topic] is part of what you're testing, this may be useful."`
+  - `"Thought of {{company}} because [observable signal] touches a similar problem."`
+  - `"This may be too specific, but the [topic] angle felt close enough to send."`
+- blocked signal use:
+  - `"AI-GTM stack is clearly on your mind."`
+  - `"You're clearly focused on [area]."`
+  - `"This is obviously relevant because you engaged with [topic]."`
+  - `"You are already thinking about [area]."`
+  - `"Saw you on [topic]."`
+  - `"Saw you around [topic]."`
+  - `"Saw you engaging with [topic]."`
+- signal-led opener shape is a **special case**, not the default. Use it only when the archived motion truly depends on it and the line can stay natural. Follow Superpower's `"saw you were active around some [topic] stuff recently and figured this might actually be relevant"` shape only when it reads like a real human note rather than a retrieval flex.
+- if no per-lead signal exists, a category-level opener is acceptable as a fallback, but the Findings section must flag: `"Category-level opener used because lead-sample.json carries no per-lead signal. Real sends should surface signals in lead-sample.json before using this template."`
+- this pushes the real fix upstream to find-leads, where the sample payload should include signals when they exist
+
+**Tone and framing**
+
+- avoid em dashes unless the chosen archived exemplar already uses them. In the final winner, prefer a period and a new line
+- avoid synthesized framing like "at your stage", "in a setup like yours", "running X means...", and "X means you're likely..."
+- in proof-led fallback, anchor to buyer-language workflow terms from the brief instead of generic "most teams..." openers (details in `gold-standard-message-patterns.md`)
+- samples in one set should read like siblings from one campaign, not three experiments
+- **subject lines follow the same jargon rules as the body.** Banned glue language (the same classes listed above for body copy) stays out of the subject too. Use the plain buyer-language equivalents the body uses. Shape rule: prefer the original gold-standard A + B + C pattern only when the filled subject piques buyer interest: a concrete row/company token + a concrete buyer workflow/problem + a useful artifact/result. A + B + C is not a license to stuff tokens. Only use a tokenized subject component when that token is supported by row data, natural when rendered, and more interesting than a non-tokenized version. Subjects must not use sender/founder names, `Austin's review`, `founder call`, `demo`, or `quick call` as the hook. Good: `{{company}} + Power BI sprawl + cleaner ownership`, `reporting handoffs + Power BI + team ownership`, `{{source_post_topic}} + active leads + first message test`, or `reachability + BlackHat + booth 1517`. Bad: `first LinkedIn campaign`, `quick question`, `Austin's one-report review`, `{{company}} + {{reporting_context}} + Austin's review`, `outbound`, or abstract `[brand] [jargon term]`.
+- prefer short common words and concrete verbs. `real revenue` beats `P&L`. `made` or `brought in` beats `generated incremental revenue`. `answers calls` beats `handles inbound communication workflows`
+
+**PS shape (optional — only include when it helps the reader decide this is a fit)**
+
+The PS is optional and rare. Include it **only if it materially
+strengthens the fit case** for this buyer. If the proof available would
+just add noise, drop the PS entirely.
+
+Exception: when the proven runtime message shape includes a **load-bearing
+PS**, treat it as part of the canonical skeleton, not optional garnish.
+This especially applies to:
+
+- a meta-demo / verification line that proves the core product claim
+- a short operational aside that closes the loop on the CTA
+- a same-company proven message where removing the PS weakens the motion
+
+Example: for `sellable.dev`, `p.s. yes, this message was entirely written
+and sent via claude code 😊` is not filler proof. It verifies the product
+claim and makes option B more believable. Do not prune that kind of PS just
+because the body already has mechanism + relevance.
+
+When it is included:
+
+The PS's job is to make the CTA feel safer, more concrete, or more
+believable. It should read like a natural final aside, not like a
+credibility repair patch.
+
+A PS can do four jobs:
+
+1. commitment-lowering aside: lowers fear that a reply means buying,
+   launching, migrating, switching, or committing
+2. concrete preview aside: makes a new category easier to picture by
+   naming one side of the workflow the buyer can see
+3. proof-as-wink aside: naturally verifies the core claim, like a meta
+   demo
+4. customer/result proof aside: adds one short peer result when it would
+   bloat the body but clearly increases believability. Customer/logo proof
+   belongs here when it is legitimacy proof, not the main reason to reply. It
+   must name what the customers used the product/service for, not just that
+   they exist.
+
+A PS must not explain strategy, defend the pitch, add a second unrelated
+offer, or say the quiet part out loud. Lines like `this is not just a
+platform idea` are blocked because they sound like internal rationale.
+
+The reader does not know who the sender's colleagues are. Dropping a bare first name with no anchor reads like a resume dump that was cut in half.
+
+Rules:
+
+- the PS must land a relevance hook — tie the proof directly to the buyer's pain or situation
+- the PS must read like a natural aside, not an artifact label. Block phrases
+  like `p.s. relevant proof:`, `p.s. useful proof:`, `p.s. proof:`, and
+  `p.s. social proof:`.
+- a meta-demo PS is valid when it increases confidence in the core claim by
+  showing the product already did the thing the message says it can do
+- write the PS in a voice the reader can place:
+  - if the **sender is the founder/operator**, write in `I` voice. Archive anchor: Superposition's `"I placed the first engineering hire at Brex."`
+  - if the **sender is not the founder**, use `our CEO`, `our team`, or `we` as the anchor — never drop a bare first name with no anchor. Shape: `"Our CEO [did the prior thing that shows they understand this buyer's pain]."`
+  - `our team` and `we` voices work well for backing, funding, or collective proof. Shape: `"Our team is backed by [investor] because they're seeing the same [buyer pain] everywhere we look."`
+- **default to ONE proof beat** — the single beat that most directly answers "why is this sender a fit for my specific pain?"
+- a second beat is only allowed when it answers a **different objection** the buyer would actually have — not when it's merely available. Structural examples of valid second beats (objection-shaped, motion-agnostic):
+  - the buyer's likely concern is "does this actually work reliably" → a beat about technical depth or track record strengthens the fit
+  - the buyer's likely concern is "is this product durable / will the company be here in a year" → a named backing or capital beat strengthens the fit
+  - the buyer's likely concern is "have you solved this for someone like me" → a named peer-customer beat (when safely available) strengthens the fit
+- if beat #1 already answers the buyer's primary question ("why does this sender understand my pain"), beat #2 needs to open a **new** dimension for the buyer. If it doesn't open a new dimension, it's a credential tack-on — cut it
+- no three-beat PS. No three-credential list. No title fragments like "CTO X led AI at Y"
+- close with the fit/relevance tag, not the credential. The last words should imply "that's why this might be worth 15 minutes," not "here's another bullet"
+- cut the PS entirely when:
+  - the best available proof does not clearly say "this sender understands your situation"
+  - the proof is purely credential without a relevance hook you can write in one sentence
+  - the body already carries the mechanism and relevance and adding a PS would dilute rather than reinforce
+  - except when the PS itself is the proof/demo that makes the core claim more believable
+- examples of good shapes (abstract — to be instantiated from the brief's safe-claims list, not copied):
+  - `"Our CEO [ran a comparable operation before this], so the product is built for how [buyer-specific failure mode] actually breaks."`
+  - `"I spent [X years] watching this exact [named handoff] fall apart at a previous role, which is why the first thing we built fixes it."`
+  - `"Our team is backed by [named investor] because they're seeing the same [buyer pain] at every [segment] we talk to."`
+- examples of bad shapes (automatic revisions):
+  - `"Alex did X. Jordan did Y."` — bare first names with no anchor, no relevance to the buyer's pain
+  - `"CEO Alex, 2x founder. CTO Jordan, ex-FAANG."` — credential list, no relevance hook
+  - `"Our team has deep [X] and [Y] experience."` — generic, no specifics
+  - any PS that could be dropped without weakening the fit case — drop it instead
+
+### Safety
+
+- reject unresolved `{{token}}`
+- reject unsupported new tokens not declared in the brief
+- reject invented proof, metrics, logos, customer names, or personalization
+- reject personalization that cannot be traced to `lead-sample.json`
+- keep proof claims inside the brief's safe-claims boundary
+- use only signals validated in `lead-sample.json`
+- pass the Thomas revision filters before returning
+
+When token sourcing is weak:
+
+- revise token fill rules
+- or revise the filter
+- or revise the message thesis
+
+Do not guess.
+
+### `message-validation.md` Shape
+
+```md
+# Message Validation
+
+Status: confirmed | revise-message | revise-filter
+Mode: DRY MODE (no DB mutation)
+Template Used: [template or thesis label from brief]
+Primary Example: [archived winner chosen]
+Secondary Influence: [optional CTA/proof/opener influence or none]
+Lead Sample Basis: [2-3 validated leads]
+
+## Strongest Reply Reason
+
+- Strongest true thing we can say: ...
+- Why this buyer would care: ...
+- Packaging Rationale: [why this shape makes the reason feel human,
+  interesting, and worth replying to; do not cite shape alone as the reason]
+
+## Pre-Draft Buyer-Role Analysis
+
+- Buyer role / accountability: ...
+- Likely inbox objection: ...
+- Offer clarity sentence: ...
+- Sender identity rule: ...
+- Strongest proof and objection answered: ...
+- Lowest-friction true CTA: ...
+- Message thesis before drafting: ...
+
+## Campaign Element Pool
+
+### Sender Relevance Options
+
+| Option | Line / Concept | Score | Keep / Reject | Reason |
+| ------ | -------------- | ----- | ------------- | ------ |
+
+### Buyer Problem Options
+
+| Option | Problem | Score | Keep / Reject | Reason |
+| ------ | ------- | ----- | ------------- | ------ |
+
+### Offer Framing Options
+
+| Option | Offer | Score | Keep / Reject | Reason |
+| ------ | ----- | ----- | ------------- | ------ |
+
+### Mechanism Framing Options
+
+| Option | Mechanism | Score | Keep / Reject | Reason |
+| ------ | --------- | ----- | ------------- | ------ |
+
+### Proof Options
+
+| Option | Proof | Role (`body-worthy` / `translated` / `CTA-asset` / `PS-worthy` / `internal-only`) | Score | Reason |
+| ------ | ----- | --------------------------------------------------------------------------------- | ----- | ------ |
+
+### CTA Options
+
+| Option | CTA | Type | Score | Reason |
+| ------ | --- | ---- | ----- | ------ |
+
+### PS Options
+
+| Option | PS  | Job | Score | Reason |
+| ------ | --- | --- | ----- | ------ |
+
+## Gold Standard Strategy Map
+
+| Example | Buyer Situation It Interrupts | Why Buyer Replies | Sender Relevance | Offer Clarity Move | Mechanism Clarity Move | Proof Role | CTA Job | Surface Traits Not To Copy |
+| ------- | ----------------------------- | ----------------- | ---------------- | ------------------ | ---------------------- | ---------- | ------- | -------------------------- |
+
+## Current Campaign Translation
+
+- Equivalent buyer situation: ...
+- Equivalent strongest reply reason: ...
+- Equivalent sender relevance: ...
+- Equivalent offer: ...
+- Equivalent mechanism: ...
+- Equivalent proof role: ...
+- Equivalent CTA: ...
+- What would feel fake or overfit: ...
+
+## Element Scoring
+
+- Best Strategy Combination: ...
+- Why this combination beats alternatives: ...
+- Rejected high-risk element: ...
+- Proof placement decision: body | translated | CTA asset | PS | internal-only
+- CTA / PS decision: single CTA | A/B CTA | PS | no PS — reason
+
+## Agent Dialogue Cross-Review
+
+### Skeptical Prospect
+
+- Rejected before drafting: ...
+- Would keep reading because: ...
+- Biggest "so what?" risk: ...
+- CTA risk: ...
+
+### Offer Strategist
+
+- Actual offer in plain English: ...
+- Buyer-side reason to care: ...
+- Product explanation: ...
+- Mechanism: ...
+- Proof treatment: ...
+- CTA job: ...
+
+### Gold-Standard Editor
+
+- Closest gold motion: ...
+- Line jobs to preserve: ...
+- Surface traits not to copy: ...
+- Where current strategy could become weaker than gold: ...
+
+### Cross-Review Consensus
+
+- Approved opener job: ...
+- Approved product explanation: ...
+- Approved mechanism: ...
+- Approved proof treatment: ...
+- Approved CTA shape: ...
+- Approved PS decision: ...
+- Banned elements before drafting: ...
+
+### Chosen Element Bank
+
+- Opener strategy: ...
+- Offer sentence: ...
+- Mechanism sentence(s): ...
+- Proof beat: ...
+- CTA: ...
+
+## Per-Row Signal Inventory
+
+| Row | Name / Company | Signal Category | Signal Verbatim | Strength |
+| --- | -------------- | --------------- | --------------- | -------- |
+
+Signal Category values: `post-quote` | `profile-snippet` | `trigger` |
+`tool-keyword` | `peer-event` | `none`.
+Strength: `strong` (verbatim quote-back ready) | `medium` (paraphrase
+only) | `weak` (inferred from category) | `absent`.
+If every row in the sample lists `none`/`absent`, Findings MUST flag
+"signal-absent sample — real sends should enrich upstream before
+shipping this template".
+
+## Proof Inventory
+
+- Mechanism: ...
+- Credibility / Social Proof: ...
+- Outcome Proof: ...
+- Deployment / Simplicity Proof: ...
+- Founder / Backing / Prior-Work Proof: ...
+
+## Token Fill Rules
+
+| Token | Source Field | Allowed Transformation | Fallback | Result |
+| ----- | ------------ | ---------------------- | -------- | ------ |
+
+If `{{company}}` or another account-context token is available, document
+whether it was tested as a believability personalization, not only whether it
+was technically available. Use it when it grounds a generic phrase without
+creating employer-blame, employer-permission, legal, or scrape-y risk. If it is
+omitted, state the specific reason it would not improve believability.
+Do not define or use `{{profile_signal}}`. Treat it as an internal enrichment
+classification only. When a profile-derived signal is genuinely useful, define
+a buyer-readable derived token such as `{{workflow_context}}` or
+`{{role_specialization}}` and show both its clean fill rule and omit fallback.
+When raw `{{company}}` is awkward but employer grounding still helps, define
+`{{employer_context}}` as a row-derived token: fill with the clean company name
+when natural, otherwise `your group`, `your bank`, `your team`, or the closest
+buyer-native account phrase. Do not silently fall back to generic language
+without documenting the transformation.
+Apply the same pattern to role, hiring, workflow, team/function, geography, and
+account-segment context. If the copy says a generic role/team/workflow and the
+row has a safe field for it, define the token and fallback before drafting.
+Examples:
+
+- `{{hiring_role}}` = exact open role when clean; fallback `the role you're
+hiring for`
+- `{{role_specialization}}` = buyer-native specialization from title/headline;
+  fallback broad role only when specialization is absent
+- `{{workflow_context}}` = concrete public workflow clue; fallback omitted, not
+  generic filler
+- `{{account_segment}}` = row-derived account category when it improves fit;
+  fallback brief-level segment only when every row shares it
+
+## Token Adherence Table
+
+| Sample | Supported Tokens Only | All Tokens Resolved | Proof Safe | Personalization Grounded | Thomas Filters | Result |
+| ------ | --------------------- | ------------------- | ---------- | ------------------------ | -------------- | ------ |
+
+## Message Element Plan
+
+- Base reusable pieces: ...
+- Optional sample-derived personalization pieces: ...
+- Personalization slots chosen: opener | soft bridge | proof | CTA | none
+- Casing / voice style: standard sentence case | casual lowercase common words
+- Sender-origin decision: include | omit | rewrite — reason
+- Proof placement decision: body | PS | CTA artifact | omitted — reason
+- PS decision: keep | test | omit — reason
+- Jargon / acronym decision: buyer-native | translate | omit — reason
+
+| Element          | Type (`base` / `sample-derived` / `omit`) | Source              | Message Job      | Planned Line / Rule | Decision              |
+| ---------------- | ----------------------------------------- | ------------------- | ---------------- | ------------------- | --------------------- |
+| Greeting         | base                                      | lead sample         | opener           | ...                 | keep                  |
+| Sender relevance | base                                      | brief               | sender relevance | ...                 | keep / rewrite / omit |
+| Buyer problem    | base                                      | brief / lead review | buyer problem    | ...                 | keep / rewrite / omit |
+| Product / offer  | base                                      | brief               | product clarity  | ...                 | keep / rewrite        |
+| Mechanism        | base                                      | brief               | mechanism        | ...                 | keep / rewrite        |
+| Proof            | base                                      | brief               | proof            | ...                 | body / PS / omit      |
+| Personalization  | sample-derived                            | lead sample         | soft bridge      | ...                 | use / test / omit     |
+| CTA              | base                                      | brief               | CTA              | ...                 | keep / rewrite        |
+| PS               | base                                      | brief               | PS               | ...                 | keep / omit           |
+
+## Angle Drafts
+
+### Angle A
+
+- Angle type: sender-origin | pain-removal | offer-first | mechanism-first | proof-translated | objection-handling | CTA-preview
+- Why this angle exists: ...
+- Target row: [name @ company, with row-specific signal quoted/paraphrased or category-only]
+- Substance Filter gate: PASS | BLOCKED (cite filter name + offending line)
+- Message: ...
+
+### Angle B
+
+- Angle type: ...
+- Why this angle exists: ...
+- Target row: ...
+- Substance Filter gate: PASS | BLOCKED (cite filter name + offending line)
+- Message: ...
+
+### Angle C
+
+- Angle type: ...
+- Why this angle exists: ...
+- Target row: ...
+- Substance Filter gate: PASS | BLOCKED (cite filter name + offending line)
+- Message: ...
+
+### Angle D
+
+- Angle type: ...
+- Why this angle exists: ...
+- Target row: ...
+- Substance Filter gate: PASS | BLOCKED (cite filter name + offending line)
+- Message: ...
+
+### Angle E
+
+- Angle type: ...
+- Why this angle exists: ...
+- Target row: ...
+- Substance Filter gate: PASS | BLOCKED (cite filter name + offending line)
+- Message: ...
+
+## Kill / Combine Review
+
+| Angle | Keep / Combine / Reject | Reason | Best Piece To Reuse |
+| ----- | ----------------------- | ------ | ------------------- |
+
+## Finalists
+
+### Finalist 1
+
+- Source parts: ...
+- Why this finalist exists: ...
+- Message: ...
+
+### Finalist 2
+
+- Source parts: ...
+- Why this finalist exists: ...
+- Message: ...
+
+## Candidate Messages
+
+### Candidate A
+
+- Why this candidate exists: ...
+- Target row: [name @ company, with row-specific signal quoted verbatim]
+- Substance Filter gate: PASS | BLOCKED (cite filter name + offending line)
+- Message: ...
+
+### Candidate B
+
+- Why this candidate exists: ...
+- Target row: [name @ company, with row-specific signal quoted verbatim]
+- Substance Filter gate: PASS | BLOCKED (cite filter name + offending line)
+- Message: ...
+
+### Candidate C
+
+- Why this candidate exists: ...
+- Target row: [name @ company, with row-specific signal quoted verbatim]
+- Substance Filter gate: PASS | BLOCKED (cite filter name + offending line)
+- Message: ...
+
+## Finalizer Pass
+
+- Best opener: Candidate [A|B|C] — reason
+- Best proof sentence: Candidate [A|B|C] — reason
+- Best bridge: Candidate [A|B|C] — reason
+- Best CTA: Candidate [A|B|C] — reason
+- Best PS / no-PS decision: Candidate [A|B|C] — reason
+- Element edits made by finalizer: ...
+- Bullet-stack decision: used | rejected | not applicable — reason
+- Style consistency check: PASS | BLOCKED — reason
+- Assembly note: clean combination or one candidate swept
+
+## Optional Simplifier Pass
+
+- Original winner: ...
+- Simplified candidate: ...
+- Simplifier edits: combined lines | split dense line | preserved bullet stack | added bullet stack | none
+- Bullet-stack decision: preserved | added | rejected | not applicable — reason
+- Robustness check: PASS | BLOCKED — reason
+- Decision: applied | rejected
+
+## Gold-Standard Quality Gate
+
+- Believability: PASS | BLOCKED — reason
+- Legitimacy / scam-risk proof: PASS | BLOCKED | OMITTED — reason
+- Sender relevance: PASS | BLOCKED — reason
+- Non-assumption opener: PASS | BLOCKED — reason
+- No resume intro: PASS | BLOCKED — reason
+- Buyer-first opener: PASS | BLOCKED — reason
+- No bare founder intro: PASS | BLOCKED — reason
+- No `X here` sender intro: PASS | BLOCKED — reason
+- No semicolons in final copy: PASS | BLOCKED — reason
+- No adjacent repeated mechanism/pain terms: PASS | BLOCKED — reason
+- Element discipline: PASS | BLOCKED — reason
+- Product clarity: PASS | BLOCKED — reason
+- Proof naturalness: PASS | BLOCKED — reason
+- Read-aloud exactness: PASS | BLOCKED — reason
+- Jargon / acronym exactness: PASS | BLOCKED — reason
+- Style consistency: PASS | BLOCKED — reason
+- CTA truth: PASS | BLOCKED — reason
+- CTA clarity: PASS | BLOCKED — reason
+- PS restraint: PASS | BLOCKED | OMITTED — reason
+- YC / backing PS: PASS | BLOCKED | OMITTED — reason
+- Hard-to-fake proof used correctly: PASS | BLOCKED | OMITTED — reason
+- Gold-standard match: PASS | BLOCKED — reason
+- Decision: confirmed | revise-message | revise-filter
+
+## Skeptical Prospect Review
+
+- Prospect lens: skeptical recipient who has been pitched similar products on LinkedIn hundreds of times
+- Biggest offer red flags: ...
+- why they would not believe it yet: ...
+- Legitimacy / scam concern: ...
+- What feels risky, unclear, or too good to be true: ...
+- Would they keep reading after line 1? PASS | BLOCKED — reason
+- Founder-story risk: PASS | BLOCKED — reason
+- Product/category clarity: PASS | BLOCKED — reason
+- Proof "so what?" risk: PASS | BLOCKED — reason
+- Anti-employer / anti-current-setup risk: PASS | BLOCKED — reason
+- CTA friction / trap risk: PASS | BLOCKED — reason
+- Decision: keep | rewrite | reject
+
+## Winner Gate
+
+- Buyer understands sender relevance: PASS | BLOCKED — reason
+- Buyer understands product / offer: PASS | BLOCKED — reason
+- Buyer understands why it matters: PASS | BLOCKED — reason
+- Buyer believes the company / offer is real enough to engage: PASS | BLOCKED — reason
+- Proof improves the message: PASS | BLOCKED | OMITTED — reason
+- YC / backing PS improves reply odds: PASS | BLOCKED | OMITTED — reason
+- Hard-to-fake legitimacy proof is present when needed: PASS | BLOCKED | OMITTED — reason
+- No mind-reading from signals: PASS | BLOCKED — reason
+- No adjacent repetition: PASS | BLOCKED — reason
+- No semicolons or `X here` sender fragments: PASS | BLOCKED — reason
+- CTA is useful and low-friction: PASS | BLOCKED — reason
+- Every line has a prospect-side "so what?": PASS | BLOCKED — reason
+- Winner clearly beats rejected drafts: PASS | BLOCKED — reason
+- Decision: confirmed | revise-message | revise-filter
+
+## Selected Winner
+
+- Winner: Candidate A | B | C | finalizer-remix
+- Why it won: axis (relevance | distinctiveness | proof | coherence | readability)
+- Lead: ...
+- Signals Used: ...
+- Tokens Used: ...
+- Message: ...
+
+## Findings
+
+- ...
+
+## Recommendation
+
+- proceed
+- revise-message
+- revise-filter
+```
+
+Automatic failures in dry mode:
+
+- unresolved `{{token}}`
+- unsupported tokens not declared in the brief
+- invented proof or personalization
+- no compelling proof element despite the brief supporting one
+- a CTA that depends on missing proof
+- copy that fails the Thomas revision filters
+- any mutation tool usage
+
+## Workflow
+
+### Calibration Loop (recommended, not a hard gate)
+
+Goal: lock tone + offer with 1-3 examples before scaling.
+Only hard requirement: draft at least one message before batch; saving examples is strongly recommended but optional.
+
+Before drafting, read any Phase 75 brief-calibration assets already present:
+
+- the campaign brief itself
+- any "Messaging Calibration" section saved back into the brief
+- any bounded copy appendix created through `create-campaign-brief`
+- token-fill and good/bad contrast examples when template-style personalization is in play
+
+1. Draft 1 message for a single lead (v1).
+2. Ask what to change (tone, offer, wording) and what to keep.
+3. If the user likes it, save as Example:
+   - `update_cell(exampleCellId, true)`
+4. Update the campaign brief with a "Messaging Calibration" section:
+   - `get_campaign(campaignId)` to read current brief
+   - `update_campaign_brief(campaignId, campaignBrief)` with:
+     - Example(s): subject + body
+     - Tone rules (dos/donts)
+     - Offer framing notes
+     - Opener / CTA guardrails
+     - Token-fill notes when relevant
+5. Ask whether to draft another example or proceed to batch.
+
+If user wants to skip, proceed to batch but remind that examples improve quality.
+
+The calibration loop above is for live campaign mode only. In dry mode, do not
+save examples, do not update the campaign brief, and do not convert validation
+into campaign state.
+
+### Zero-Shot Quality Reminder
+
+The goal is not to rescue weak output with endless rewrites. If the draft is
+too generic, diagnose the gap precisely:
+
+- ICP not sharp enough
+- offer too heavy
+- proof too vague
+- opener too pitchy
+- token fill too mechanical
+
+Then tighten the brief or calibration notes before scaling.
+
+Use the example bank as the primary strategy source even when the brief does
+not already contain winning examples. Do not default to generic REPLY-style
+copy when the motion clearly matches a tighter archived pattern. Strong
+references include:
+
+- Sellable.dev
+- Galley
+- Gelee
+- HeyDigital
+- Revvix / Spektion
+- Superposition
+- Persona Digital
+
+When the brief is sparse but the motion clearly matches an archived winner,
+borrow the closest message shape from
+`gold-standard-message-examples.md` before inventing a new structure.
+
+### Single Row
+
+1. Load campaign examples, calibration notes, and bounded copy from the brief first.
+2. Load the REPLY framework prompt with `get_message_prompt` only as a fallback
+   structure and QA backstop when the brief lacks a concrete pattern.
+3. Fetch lead details via `get_rows`.
+4. Draft a message, show it with a full 12-gate check.
+5. If the message cell is empty, auto-save the draft with `update_cell` and say "Draft saved (not approved)."
+6. If the message cell has content, ask before overwriting; only save on explicit confirmation.
+7. Ask whether to approve, and if yes, set the approve cell.
+8. Ask whether to save as Example (exampleCellId) and update the campaign brief.
+
+### Batch Mode (Multiple Rows)
+
+When crafting messages for multiple rows (e.g., "craft rows 1-5"):
+
+**CRITICAL: Use parallel subagents for efficiency.**
+
+1. Load campaign examples, calibration notes, and bounded copy from the brief first.
+2. Call `get_message_prompt()` once to get the fallback REPLY framework and QA checks
+3. Spawn parallel subagents using the `Task` tool with explicit `model: "opus"` and `subagent_type: "general-purpose"` (never omit model):
+
+```
+For each row (1-5), launch a Task subagent:
+- subagent_type: "general-purpose"
+- model: "opus"
+- prompt: Include campaign context, sender info, row data, gold-standard message examples when present, and fallback REPLY framework
+- Do NOT use run_in_background (avoids notification spam)
+```
+
+4. Each subagent:
+
+   - Researches the prospect (WebSearch, LinkedIn tools)
+   - Crafts message by following the campaign's gold-standard pattern first
+   - Uses the proof-led specialist fallback when the campaign lacks a stronger validated hook
+   - Uses the fallback REPLY framework only as structure and QA support
+   - Returns the draft + research notes (do NOT save)
+
+5. Wait for all subagents to complete
+6. Auto-save drafts for rows where the message cell is empty (announce "Draft saved (not approved)")
+7. Show summary:
+
+```
+Crafted 5/5 messages:
+
+| Row | Name | Status | Preview |
+|-----|------|--------|---------|
+| 1 | John | ✅ Saved | "Saw your post about..." |
+| 2 | Sarah | ✅ Saved | "Love what you're doing..." |
+...
+
+Approve all for sending?
+- Yes, approve all
+- Review individually first
+```
+
+### Subagent Prompt Template
+
+When spawning craft subagents, include:
+
+```
+Craft a personalized LinkedIn message for this prospect using the campaign's
+gold-standard examples first, then the Doctor Strange method only as needed:
+research → condense → 10 angle agents in parallel → finalizer combines best elements.
+
+## Campaign Context
+{brief, positioning, dos/donts, calibration notes (if present)}
+
+## Sender
+- Name: {name} | Company: {company} | Title: {title}
+- Core thesis: {1 line from styleguide-core.md}
+- Signature phrases: {3-5 key phrases}
+- Background: {1-2 lines}
+
+## Voice + Outbound Rules (condensed — full files available via Read tool)
+- Flow skeleton: opener → pain → **what the product IS** → **what it DOES** (one action per line, up to three) → deployment ease → CTA → optional PS
+- A cold reader must be able to state what the product does in one sentence after reading. Require a crisp `Product is an X that does Y` anchor before any action breakdown. Do not gesture at "that chain" / "the stack" / "that work"
+- Blank line between every sentence in the body. The body renders as a sequence of one-line paragraphs separated by blank lines, not as multi-sentence paragraphs. Target 6-10 one-line paragraphs
+- 5th-grade reading level by default. Cut glue language (handoff, order-to-cash, rip-and-replace). Keep brief-native product/tool names (Shopify, HubSpot)
+- No bullet points, no "I noticed...", no compliment sandwiches, no em dashes unless the canonical example uses one
+- No synthesized framing ("at your stage", "in a setup like yours", "running X means...", "X means you're likely...")
+- 3 candidates then `Finalizer Pass` — pick best opener, proof sentence, bridge, CTA across them and assemble the winner
+- PS is optional; only include if it materially strengthens the fit case. When included, use `I` / `our CEO` / `our team` / `we` voice, never bare first names. At most two proof beats, tied to why the sender understands the buyer's pain. No three-credential resume lists
+- Sound like a human peer, not a salesperson
+
+## Cross-Skill Insights
+{2-3 bullets from cross-skill.md}
+
+## Prospect (Row #{n})
+- Name: {name}
+- Company: {company}
+- Title: {title}
+- LinkedIn: {linkedinUrl}
+- Current message: {current or "[empty]"}
+- messageCellId: {cellId}
+- tableId: {tableId}
+
+## Gold-Standard Message Examples
+{best campaign-native examples, interpolation rules, and dos/donts from the brief}
+
+## Gold-Standard Strategy Patterns
+{event-led, signal-led, job-post-led, and proof-led specialist fallback rules from gold-standard-message-patterns.md}
+
+## Fallback REPLY Framework
+{full prompt from get_message_prompt()}
+
+## Instructions
+1. Research the prospect (WebSearch, LinkedIn tools if needed)
+2. Choose the highest-specificity validated strategy available in this order:
+   - event-led
+   - signal-led
+   - job-post-led
+   - proof-led specialist fallback
+3. Follow the gold-standard examples first when they exist. Preserve structure,
+   proof ordering, CTA shape, and subject style unless the prospect data makes
+   that impossible.
+4. If forced into proof-led specialist fallback:
+   - use buyer-language workflow terms from the brief
+   - lead with specialization or the specific workflow problem, not a generic
+     "most teams..." opener
+   - make the mechanism concrete
+   - use the strongest safe proof
+   - make the CTA a useful next step, not a vague meeting ask
+5. Build a condensed angle brief (~1.5k tokens) from research + sender info
+6. Fan out 10 angle agents (model: "sonnet", run_in_background: true):
+   - Each gets the condensed brief + their angle instruction (~2k tokens per agent)
+   - DO NOT pass the full fallback REPLY framework to angle agents, only the brief
+7. After all 10 return, act as the Finalizer:
+   - Combine the best opener, bridge, body, and CTA across all drafts
+   - Credibility pass: must say something they haven't heard from 50 other people
+   - Voice-check against sender's signature phrases
+   - Reject generic fallback openers and abstract noun subjects when the
+     specialist fallback can be made more concrete
+   - Run full 12-gate check using the fallback REPLY framework as QA only, all must pass
+8. Return: { success: true, message: "...", research: [...], anglesExplored: 10 }
+```
+
+**IMPORTANT:** Load `.sellable/configs/writing/outbound.md`, `styleguide-core.md`, and `.sellable/insights/cross-skill.md` ONCE in the lead agent, then pass **condensed** versions to subagents. Don't pass full file contents to every subagent — that wastes context and causes overflow.
+
+## Batch Approval
+
+After batch generation, user can approve all:
+
+```
+update_cell(approveCellId1, true)
+update_cell(approveCellId2, true)
+...
+```
+
+Or approve individually after reviewing in UI.