--- 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 row-level messages in two active modes: - live campaign mode for selected leads in a real campaign table - caller-declared DRY MODE for offline 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) - `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) - `mcp__sellable__get_subskill_asset` (required for packaged reference assets) - `mcp__sellable__get_subskill_prompt` (only when this prompt was not already loaded) ## Execution Modes ### Mode 0: Message Drafting Branch Use `generate-messages` for the campaign workflow's live template recommendation branch after the source list is copied into the campaign table and the first non-empty execution slice exists. This is not the row-cell generation path. Before drafting, that branch must also load the required message assets through Sellable MCP tools: - `create-campaign-v2/references/gold-standard-message-examples.md` - `create-campaign-v2/references/gold-standard-message-patterns.md` - `create-campaign-v2/references/ai-tells.md` - `create-campaign-v2/references/sellable-cleanup-rules.md` - `create-campaign/references/ai-native-tokens.md` - `create-campaign/references/token-fill-examples.md` After candidate generation and revision, and before returning `ready`, load `create-campaign-v2-validation` through Sellable MCP as the final gate. Both live and dry runs must produce or validate `message-validation.md` with the same quality gates. The selected winner must pass the `Concrete Language Audit`: identify and replace or cut abstract verbs, abstract nouns, abstract adjectives, abstract adverbs, and cliches before the message is treated as ready. Never reconstruct that branch from `brief.md`, `lead-review.md`, `lead-sample.json`, `lead-filter.md`, `message-validation.md`, local files, or direct database reads. If any required message asset cannot be loaded through MCP before drafting, return `blocked` or `retry-needed`. If the validation prompt cannot be loaded after generation, or the candidate fails that final gate, return `blocked` or `retry-needed`. Reject the branch as blocked if the campaign id, selected lead list, workflow table, or initial execution-slice rows do not match. Return message-draft output only: template recommendation, token fill rules, rendered good sample, status, basis token, output timestamp/hash, and blocked/retry detail when applicable. Do not write message cells, enrich rows, update the campaign brief, attach a sequence, or imply send readiness from this branch. ### 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 Sellable cleanup filters as dry mode ### Mode 2: Caller-Declared DRY MODE Use this mode when the caller explicitly says `DRY MODE`, `offline validation`, `create-campaign-v2`, or provides: - `brief.md` - `lead-sample.json` - `lead-filter.md` when available. In the campaign workflow's post-lead workstream, message generation may start before `lead-filter.md` exists so it can prepare proof inventory, token strategy, and candidate angles while filter-leads runs. 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-sample.json`, and `lead-filter.md` when present - treat `lead-sample.json` from find-leads as the message sample source; do not ask filter-leads for a new sample, create a new sample, or fetch additional prospects for dry-mode message generation - if `lead-filter.md` is not present yet, do the expensive early work only: proof inventory, token rules, strategy map, candidate angle drafting, and provisional sample fills. Prefer writing `message-prep.md` and `message-candidate-drafts.md` while waiting for the filter branch. - use `lead-filter.md` once available to decide which find-leads sample rows remain valid for the final winner and which false-positive patterns must be avoided - use `lead-filter.md` only to decide which find-leads sample rows remain valid; never use it to create replacement sample rows - do not mark `message-validation.md` as final or ready for message review until `lead-filter.md` exists and the selected winner cites only rows that still pass the filter - 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. ## Offline Validation Dry mode validates message quality before campaign mint. Read these campaign inputs: - `~/.sellable/configs/core/about-me.md` - `~/.sellable/configs/core/my-company.md` - `~/.sellable/configs/core/context-modes.md` - `~/.sellable/configs/core/proof-ledger.md` - `~/.sellable/configs/core/wins-ledger.md` - `~/.sellable/configs/core/anti-ai-writing-style.md` - `~/.sellable/configs/writing/outbound.md` and legacy `styleguide-core.md` as fallback/source material when present - `brief.md` - `lead-sample.json` from the find-leads step; this is the only allowed sample source for dry-mode message generation - `lead-filter.md` when present. If it is absent because the caller launched prospect setup workstreams in parallel, start the prep/candidate stages and then reconcile before final `message-validation.md`. ## Reference Asset Loading (do this before drafting) Do not draft from this prompt alone. The full `generate-messages` prompt is only the contract; the reference assets below are the evidence and examples that define the desired output. Before writing angle drafts, you MUST load every required pre-draft reference below with `mcp__sellable__get_subskill_asset`. This is the required pre-draft reference pack for Mode 0 message drafting. This is a hard gate: if the required pre-draft assets are not loaded, return `blocked` / `retry-needed` instead of drafting. Write a short internal `Reference Asset Loading` note naming each loaded asset and whether it was required pre-draft, dry-mode-only, or token-rules-only. Do not bulk-load the conditional references unless their trigger applies or the caller explicitly asks for maximum context over speed. Use `mcp__sellable__get_subskill_asset` for packaged assets: | Group | Asset to load | Job | | --- | --- | --- | | Always load before drafting | `subskillName: "create-campaign-v2", assetPath: "references/gold-standard-message-examples.md"` | Active line-level gold pack. Full archive quality bar: exact motion examples, hard rules, and transfer limits. Use it to choose 1 primary example, not to recolor copy. | | Always load before drafting | `subskillName: "create-campaign-v2", assetPath: "references/gold-standard-message-patterns.md"` | Strategy selector: event-led vs signal-led vs job-post-led vs proof-led fallback, proof inventory, candidate set, and Finalizer Pass. | | Always load before drafting (never optional) | `subskillName: "create-campaign-v2", assetPath: "references/ai-tells.md"` | Canonical anti-AI checklist: body self-intros, source citations, resume recaps, title-fit assumptions, em dashes, signoffs, weak proof brags, and flattened "worth sending" source bridges. | | Load before approval / final pass | `subskillName: "create-campaign-v2", assetPath: "references/sellable-cleanup-rules.md"` | Substance filters: earned-right, presumption, vague proof, read-as-1:1, founder-origin coherence, anti-talk-at, AI-tell filter, line continuity, PS shape, and proof safety. | | Reusable token rules only | `subskillName: "create-campaign", assetPath: "references/ai-native-tokens.md"` | Token spec for rich judgment tokens, including required clauses and fallback behavior. Always load before reusable template/token rules. | | Reusable token rules only | `subskillName: "create-campaign", assetPath: "references/token-fill-examples.md"` | Concrete good/bad token fills, interpolation guardrails, and product-noun substitution traps. Always load before reusable template/token rules. | | Dry-mode artifact output only | `subskillName: "create-campaign-v2", assetPath: "references/gold-standard-message-validation-example.md"` | Fully worked example for proof inventory, candidate messages, Finalizer Pass, Selected Winner, findings, and recommendation. | | Dry-mode artifact output only | `subskillName: "create-campaign-v2", assetPath: "references/validation-criteria.md"` | Step-level acceptance criteria and dry-mode message validation expectations. | Example packaged asset calls: - `get_subskill_asset({ subskillName: "create-campaign", assetPath: "references/ai-native-tokens.md" })` - `get_subskill_asset({ subskillName: "create-campaign", assetPath: "references/token-fill-examples.md" })` - `get_subskill_asset({ subskillName: "create-campaign-brief", assetPath: "references/phase75-active-runtime-message-pack.md" })` - `get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/gold-standard-message-examples.md" })` - `get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/sellable-cleanup-rules.md" })` - `get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/validation-criteria.md" })` Do not satisfy the list above by searching or reading the local filesystem. Path-like names in this section are package asset coordinates for MCP loading. Default load order: 1. Load the **Always load before drafting** assets. Do not infer their contents from this prompt; actually call `mcp__sellable__get_subskill_asset` for each required asset. 2. Draft and run the internal Finalizer Pass. 3. Run the selected winner against `ai-tells.md`. This is never optional. If the AI-tells catalog was not loaded or any `REJECT` tell matches, do not approve, confirm, recommend, or show the template as ready; return `revise-message`. 4. Run the selected winner against `sellable-cleanup-rules.md` before approval, `confirmed`, or template recommendation. 5. Load dry-mode artifact references only when writing `message-validation.md`. Do not load retired branch/runtime packs. ### Rich Personalization Contract The `create-campaign` asset `references/ai-native-tokens.md` is the canonical spec for personalization that requires judgment. Load it before writing the Token Fill Rules or any reusable template notes. When token fill wording is material, use `mcp/sellable/skills/create-campaign/references/token-fill-examples.md` as the conditional good/bad fill reference. - Sentence-level personalization must use AI-native bracket tokens in the reusable template / token plan, not old-school field substitution. Field tokens such as `{{first_name}}` and `{{company}}` are fine for atomic slots. Do not collapse rich personalization into `{{workflow_context}}`, `{{company}}`, or another noun-shaped token when the line needs judgment. - Use this shape for any hook, bridge, or row-specific relevance line: `[PERSONALIZATION_LINE — Intent: write one short sentence that anchors the note to why this might matter now. DO: connect one observable role/company/ activity signal to the buyer problem or offer with low-certainty language like "hope this is relevant if...", "saw you might be interested in...", "saw you in a few conversations around...", or "figured this might matter if...". DON'T: recap their resume, list companies, compliment their background, name a product their company sells, use source-citation phrasing, or use generic nouns like "your work". FALLBACK: if unsupported, omit the entire line.]` - The rendered personalization line should usually be 6-14 words. If it needs two clauses, multiple companies, or abstract tags like `GTM`, `international growth`, and `outbound work` to make sense, it is probably analysis leakage, not sendable copy. - Personalization must not only tell the prospect about themselves. A good line creates a reason for the note: observed context -> why this might be relevant. - The bracketed token belongs in the reusable template / token plan only. The rendered `Selected Winner` and sample messages must contain the composed sentence or no line at all; never show the bracket to the buyer. - If the campaign truly only needs an atomic field value, document it as a field token. If the value is a sentence, phrase, buyer-activity judgment, or synthesis of multiple row fields, author it as AI-native. 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 `gold-standard-message-examples.md` as the canonical examples asset for both primary runtime examples and conditional motion references - retrieve against the primary runtime examples first, then conditional examples only when the campaign motion matches - use the examples for concrete formatting cues that abstract patterns may flatten away: lowercase vs title case, exact `two options:` formatting, short line rhythm, and load-bearing `p.s.` lines - treat the examples 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 examples file 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...` - `your {{role}} role at {{company}} looked close to this problem` - `your {{role}} role at {{company}} looked close to this outbound campaign problem` - `saw you on {{recent_signal}}` - `saw you around {{recent_signal}}` - `saw you engaging with {{recent_signal}}` - `saw you raise your hand for {{signal_topic}}, so figured this was worth sending` - `figured this was worth sending` Safer shapes: - `hope this is relevant if {{signal_topic}} is part of the plan` - `saw you might be interested in {{signal_topic}}, so hope this is relevant` - `saw you in a few conversations around {{signal_topic}}, so hope this is relevant` - `saw you in a few conversations about {{signal_topic}}, so may be off, but this seemed relevant` - `appreciate you showing some love on my post about {{signal_topic}}` only when the sender/client authored the source post and the row proves a reaction or comment - `thanks for showing support on my {{signal_topic}} post` only when the sender/client authored the source post and the row proves a reaction or comment - `figured this might be relevant if {{channel_context}} is becoming more of a {{workflow_context}} for {{company_context}}` as the bridge after a sender-owned post acknowledgment - `may be off, but if {{workflow_signal}} is relevant to what you're working on, this might be useful` - `if {{workflow_signal}} is not relevant to what you're working on, ignore me` - `figured this might matter if {{workflow_signal}} is live at {{company}}` - `thought of {{company}} because {{observable_signal}} points at {{problem_context}}` - `found you in a thread about {{signal_topic}}, so may be off, but this seemed relevant` - `saw you raise your hand for {{signal_topic}}, so figured this was (hopefully) worth sending` only when the source was an explicit lead-magnet comment, reply, or opt-in. The parenthetical uncertainty is load-bearing; do not flatten it to `so figured this was worth sending`. - `saw you raise your hand for {{signal_topic}} (creepy to reach out based on that, i know) - but this felt too on the nose to ignore` only when the source was an explicit lead-magnet comment, reply, or opt-in and the sender's voice can carry the cheekier aside Before choosing the source opener, classify source ownership: - `sender-owned-single`: one sender/client is known, the selected source post was authored by that same person, and the row/list proves a reaction or comment. - `sender-owned-ambiguous`: the source appears sender-owned but the final sender is not known, multiple senders may be used, or the source author does not clearly match the specific sender voice. - `third-party`: the source post/thread/conversation was authored by someone other than the sender/client. For `sender-owned-single` LinkedIn-post-sourced campaigns, it is acceptable to thank the recipient for showing some love/support on the sender's post when the row proves a reaction or comment. Keep it first-person, light, and non-assumptive: `appreciate you showing some love on my post about {{signal_topic}}` is acceptable; do not say `you commented` unless the row proves comment text. If meaningful comment text exists in the row, a comment callout is allowed only at topic level; do not quote or paraphrase the comment unless the row text is available and the wording materially improves the opener. For `sender-owned-single`, third-party thread framing is a hard failure: do not write `found you in a thread`, `saw you in a thread`, `saw you in conversations`, or `saw you in a few conversations` unless the source is truly third-party. The branch-level reusable template must either use the first-person acknowledgment plus bridge, or omit the source line. For `sender-owned-ambiguous` or multi-sender campaigns, do not assume the message is from a specific person. Do not write `my post`, `Grace's post`, or any first-person post acknowledgment unless the final sender/source-owner match is proven for that row. Omit the sender-owned source line until row generation can safely fill it. Neutral thread/source language is only for truly third-party sources. In short: do not assume the message is from a specific person when the final sender/source-owner match is ambiguous. Do not let the acknowledgment dead-end. Follow it with a soft post-topic to buyer-context bridge before broad pain or product copy. Prefer: `figured this might be relevant if {{channel_context}} is becoming more of a {{workflow_context}} for {{company_context}}`. Avoid jumping directly from `appreciate you showing some love...` into `a lot of B2B teams...` or `most teams...`; that transition reads stitched together instead of human. Every following line must cash the previous line: post support -> why the topic may matter now -> what the product/problem has to do with that topic. If the product/problem line would read the same after deleting the source acknowledgment and bridge, the connection is fake; rewrite or cut until the line-to-line chain is real. For third-party LinkedIn-post-sourced campaigns (commenters, reactors, lead magnet replies, or scraped conversations), it is acceptable to reference the conversation when it explains why the note exists. Keep it topic-level, not activity-log-level: `saw you in a few conversations around {{signal_topic}}, so hope this is relevant` is acceptable; `saw you commented on {{post_context}}` and `your LinkedIn activity around...` are not. Reserve `raise your hand` phrasing for explicit lead-magnet comments, replies, or opt-ins. For ordinary thread discovery, use `saw you in a few conversations around {{signal_topic}}...` or `found you in a thread about {{signal_topic}}...`. Keep the apologetic nature, but aim it at uncertainty, not surveillance. Good: `saw you in a few conversations about outbound, so may be off, but this seemed relevant`, `may be off, but if outbound is relevant to what you're working on...`, `if this is not relevant to your outbound workflow, ignore me`, `hope this is relevant if...`. Bad: `your role at {{company}} looked close...`, because it asserts fit from a title and tells the buyer about themselves. Block wordier source narration such as `you might not remember the thread, but I found you through a {{signal_topic}} discussion and your {{observable_role_context}} looked close to {{problem_context}}`. It reads like sourcing metadata plus resume recap. Replace it with the shorter topic-level bridge above, or omit the personalization line and start with the buyer pain. ### Personalization compression gate Before a personalization line can survive into a template, rendered sample, or Selected Winner, check it against these gates: - **Bridge, not recap:** it must make why the note might matter feel earned. A line that only says where the person worked, what role they held, or what their company does is blocked. - **Short by default:** target 6-14 words. A longer line must earn every word by improving relevance or reducing assumption risk. - **One inference only:** use one observed signal and one buyer-relevant bridge. Do not stack two employers, two roles, and the product category into one line. - **No product-centered bridge:** do not write `looked close to what [Product] is built for`, `relevant to our platform`, or similar copy that centers the sender's product before the buyer feels seen. - **No title-fit assertion:** do not write `your [role] role at [company] looked close to this problem`. A title/company can be the private reason you selected the row, but the buyer-facing line should stay conditional: `may be off, but if [workflow] is relevant to what you're working on...`. - **Swap test:** if another founder/operator could receive the line after only changing names and companies, cut it or make the bridge more specific. - **Tell-about-themselves test:** if the line merely reports a fact the buyer already knows, rewrite it into a relevance hypothesis (`hope this is relevant if...`) or omit it. Blocked: - `Your GTM and international growth work at Nas Daily and 1000media looked close to the kind of outbound work Sellable is built for.` - `You might not remember the thread, but I found you through a LinkedIn outreach discussion and your sales development role at Gainsight looked close to this problem.` - `Your enterprise sales role at Odoo looked close to this outbound campaign problem.` Better: - `hope this is relevant if market expansion is still on your plate.` - `saw you in a few conversations around international growth, so hope this is relevant.` - `saw you in a few conversations around LinkedIn outreach, so hope this is relevant.` - `saw you in a few conversations about LinkedIn outreach, so may be off, but this seemed relevant.` - `appreciate you showing some love on my post about GTM engineering.` - `figured this might be relevant if LinkedIn is becoming more of a GTM channel for {{company_context}}.` - `may be off, but if outbound is relevant to what you're working on, this might be useful.` - `figured this might matter if you're testing outbound by market.` ### 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. - run a contraction naturalness pass on the buyer-facing copy before selecting the winner. Use common contractions when they make the message sound like a human LinkedIn note: `it is` -> `it's`, `does not` -> `doesn't`, `do not` -> `don't`, `cannot` -> `can't`, `we are` -> `we're`, `I am` -> `I'm`, and `you are` -> `you're`. Keep the uncontracted form only when emphasis, grammar, token boundaries, legal/technical clarity, or a deliberate formal voice requires it. Do not create awkward noun contractions like `outbound's becoming`. If selected copy contains stiff helper-verb phrasing such as `It is knowing...`, rewrite it before approval. - 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. - run the parallel action formatting check when the winner has 3 adjacent product actions, outputs, mechanics, or objection removers. If the lines repeat the same subject pattern (`It drafts...` / `It adapts...` / `It helps...`) and each line is a discrete function with no narrative proof clause, prefer a compact `-` bullet stack because it is easier to scan on mobile. Example: `It helps your team:` followed by `- Draft posts...`, `- Adapt them...`, `- Keep showing up...`. Do not force bullets when there are only 1-2 actions, one line needs narrative context, the bullets feel like a landing page, or the paragraph version is clearly more human and still scans cleanly. This is a formatting preference, not a message-strategy gate. - 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. - contain exactly one outbound send unit. Do not include post-accept DMs, follow-ups, second touches, cadence branches, sequence notes, or later-message copy in the Selected Winner or nearby rendered examples. If a later message idea is useful, keep it out of the generated first-message artifact and put it in an internal finding for post-mint sequence work. - never use generic signal tokens like `{{recentSignal}}`, `{{recent_signal}}`, or `{{recent_signal_quote}}`. If row personalization is needed in the raw selected winner, render the concrete sentence from 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`. For the reusable template / token plan behind that rendered line, prefer an AI-native bracket token with inline Intent / DO / DON'T / FALLBACK rules; only use a row-derived `{{field_token}}` when the inserted value is truly atomic. - 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, render it into a buyer-readable sentence in the selected copy and document the reusable template as an AI-native token. Use named row-derived context tokens such as `{{workflow_context}}`, `{{source_post_topic}}`, or `{{row_proof_note}}` only when the value is an atomic phrase that drops into the sentence without judgment; 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 - if a selected template or gold-standard influence ends with a non-question CTA statement, do not preserve the surface wording. Preserve the buyer promise and rewrite the CTA as one concrete yes/no question. Example: `easiest way to see if it's worth a look is to try it with one of your actual menus. happy to set that up or I can send a 2-min video instead.` should become a single question that names the useful object, such as `open to seeing what one real menu would look like in the product?` - 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, preserve the intent, not the phrase. Translate `compare notes` into a concrete CTA that names the topic, workflow, artifact, preview, teardown, or working session. Prefer shapes like `Open to a quick call on how {{company_or_team}} might turn LinkedIn content into pipeline?`. Do not use `Open to compare notes?` or `Open to comparing notes on...`. - 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 `Concrete Language Audit` after the Optional Simplifier Pass and before the Gold-Standard Quality Gate. This pass starts from the current selected winner and highlights every word, phrase, or sentence that contains: - abstract verbs - abstract nouns - abstract adjectives - abstract adverbs - cliches For every highlight, write the exact text, category, why it is too abstract or stale for this buyer, the concrete replacement, and whether the replacement was applied or the line was cut. The replacement must name a buyer-visible action, object, workflow, artifact, risk, result, or next step from the brief, lead-sample, proof inventory, or approved token rules. Do not replace abstract language with a different abstraction. If the concrete replacement would invent proof, overclaim intent, or create a safety issue, cut the phrase or route to `revise-message` / `revise-filter`. Use this audit as a rewrite engine, not a style note. The selected winner must not carry unresolved abstract or cliche language that can be made concrete from available evidence. If an abstract term is intentionally kept because it is the buyer-native category noun, document why it is buyer-native and why a concrete replacement would be less clear. Run a `Final Subtraction Pass` after the Concrete Language Audit 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? - Does this line follow from the line before it and make the next line feel earned? If two adjacent lines could be swapped, deleted, or joined with `anyway`, the transition is fake. Rewrite the bridge or cut the orphan line. - 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/sellable-cleanup-rules.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 from core identity memory, context modes, and explicit campaign inputs. Legacy `styleguide-core.md` is fallback/source material, not the primary voice source. State 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. If the campaign brief explicitly names a CTA motion, preserve it unless it fails truth, clarity, pressure, or safety gates. Improve the CTA by making the object concrete before replacing the motion. 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` Prefer source-aware entries from `proof-ledger.md`, `wins-ledger.md`, or the campaign brief. Do not invent proof or upgrade dated proof. - 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. The final CTA must be a question unless the user explicitly approved a non-question outbound motion. Template preservation does not override this. If the best draft or primary example has a statement CTA (`happy to set that up`, `I can send...`, `let me know`, `worth a look is...`), run a CTA normalization pass before selecting the winner: - keep the useful object the buyer gets - cut weak second options unless both choices are independently valuable - make the ask one self-contained yes/no question on its own line - preserve the campaign's approved intent, not the exact words - write the question from the campaign's real object and product category; do not hard-code wording from a gold example when the buyer input, artifact, preview, or product is different 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. CTA precedence: 1. If the campaign brief explicitly names a CTA motion, preserve the intent of that motion unless it is unsupported, too high-pressure, unsafe, or too vague to make concrete. 2. If preserving it, make the object specific in the same line so the buyer knows what they are agreeing to discuss, see, or get. 3. Replace it only when the brief CTA cannot pass truth, clarity, pressure, or safety gates. Treat `compare notes` as shorthand for a peer conversation, not as buyer-facing copy. The phrase itself is blocked in selected winners, including `Open to compare notes?`, `Founder-to-founder compare notes?`, and `Open to comparing notes on...`. If the brief selected that intent, translate it into a concrete quick-call or working-session CTA, e.g. `Open to a quick call on how {{company_or_team}} might turn LinkedIn content into pipeline?`. 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 outcome instead of flashing a badge or describing the seller's focus. Good 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 backers] to help [buyer segment] turn [buyer-owned workflow/channel] into [buyer outcome].` Keep it short and test it against no-PS. Do not use `focused on [category/problem]` in prospect-facing copy; translate company focus into the buyer's problem/outcome, or omit the PS. For a LinkedIn-content motion only, a good translation is: `p.s. we're backed by operators from [credible companies] to help teams turn LinkedIn content into dependable pipeline.` Before keeping any PS, name the job it performs: lower commitment, preview what they will see, answer a trust/category objection, or tie proof to buyer value. If the job is not concrete, omit the PS. If the line needs an after-the-fact explanation to make sense, it fails. The PS is optional. Do not preserve a PS just because the proof is true or available. If the PS adds friction, sounds like internal category anxiety, or uses language the buyer would not naturally say, cut the confusing clause or remove the whole PS. Generic nouns do not satisfy the concrete-job gate. Lines like `built around the workflow`, `more than a message draft`, `covers the whole process`, or `full system` still fail unless the same sentence is concrete and falsifiable: it names buyer-visible steps, a specific next-step preview, a concrete artifact, or an outcome the buyer can immediately verify. When the best rewrite is still abstract, cut the PS. Use the same standard as the older Sellable outbound configs: proof is concrete or omitted. Good proof has a real name, number, timeframe, artifact, or visible mechanism. Bad proof is vague/unfalsifiable like `helps teams communicate better` or `built around the workflow`. 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. Block vague contrast-only final lines. Contrast is allowed only when the same sentence names the concrete workflow, next step, or buyer outcome. Otherwise it points at seller breadth and makes the reader infer the value. Prefer a concrete proof/value line, cut the weak clause, or omit the PS. ### 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, narrate the source thread, or patch a weak body. If the PS sounds like internal reasoning, delete it. Source disclaimers such as `p.s. if the source thread was just casual reading, ignore me` are BLOCKED; if the source is too weak to stand in the opener/body, omit it. A relevance-risk PS is allowed when it names uncertainty without narrating the source: `p.s. if this is not relevant to your outbound workflow, ignore me.` ### 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. ### Single-send-unit gate (HARD INVARIANT) Offline-validation message generation approves the **first outbound send only**. The Selected Winner must be exactly one send unit for one channel: one INVITE, one INMAIL_OPEN / INMAIL_CLOSED body plus optional subject, or one DM body when the campaign explicitly starts with DM. Do not generate, approve, or include sequence-shaped copy in `message-validation.md`, `message-review.md`, selected copy, rendered examples, token notes, findings, or recommendation text. Blocked sequence-shaped outputs include: - post-accept DMs - connection-accepted follow-ups - day-2 / day-7 follow-ups - second touches - "reply/acceptance" branches - cadence notes - fallback send paths as copy - any "INVITE + DM", "InMail + follow-up", or multi-step message plan If a proof, PS, Loom, setup link, or meta-demo line cannot fit in the first send unit, either compress it into that first send unit or omit it. Do not move it to a later message. Preserve the idea as an internal `Findings` note only if it is useful after campaign mint. ### Message Review Revision Loop When the user gives edits to an already rendered template, treat that feedback as the next drafting input. Produce a revised selected template, rendered example, and short change summary before asking for approval again. Do not only acknowledge the feedback or ask whether a new version is better without showing the new version. In live campaign mode, save with `update_campaign_brief` only after the user approves the revised template. Do not call `request_user_input` or `AskUserQuestion` from the drafting or revision step; approval questions belong after the revised copy is visible. Before returning `Status: confirmed`, run this explicit check: `Single send unit: PASS | BLOCKED — reason` If BLOCKED, set `Recommendation: revise-message` and rewrite the Selected Winner until it contains only the first outbound send. A message can be strong and still be invalid if it requires a post-accept DM or other sequence copy. 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 `hope this is relevant if...`, `saw you might be interested in...`, `saw you in a few conversations around...`, `figured this might matter 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 context needs the model to decide what the sentence should say, use an AI-native bracket token in the reusable template / token plan instead of a noun-shaped `{{workflow_context}}`-style slot. If the row signal is weak, write the segment-level line and document the omit rule. - **No product-noun substitution in possessive frames (HARD INVARIANT):** when a token sits inside a possessive frame like `your {{X}}`, `at your {{X}}`, or `because of your {{X}}`, the filled value MUST describe something the recipient personally **does** — their work, focus, or activity. It must NOT describe a product their company **builds or sells**. Grammar test: read `your ` out loud. If it reads as if the recipient _uses_ or _has_ the thing, but they actually _build/sell_ the thing, the fill is wrong → OMIT the entire sentence. Examples: `your monetization layer for AI builders` (BLOCKED — product description from the company), `your Moneyball dashboard for CEOs` (BLOCKED — the recipient builds this product, doesn't have one of their own), `your AI scoring engine` (BLOCKED — product), vs `your monetization research for AI founders` (ALLOWED — buyer activity), `your founder-led-sales experiments` (ALLOWED — activity), `your GTM Engineering writing` (ALLOWED — what they do publicly). The omit-fallback is the safe default. Aggressive omit > awkward fill. Do NOT substitute generic nouns (`your work`, `your stack`, `your team`) — those add no relevance and read as mail merge. - **AI-native tokens — write the sentence, don't fill the slot (HARD INVARIANT):** when the message template contains a bracketed instruction token of the form \`[ALL_CAPS_NAME — instructions]\`, that placeholder is NOT a field-substitution slot. It is an inline instruction. Read the contents of the bracket. The bracket will name an Intent, DO shapes, DON'T shapes, and a FALLBACK clause. Your job: COMPOSE a complete sentence (or sentences, if the intent calls for it) that satisfies all the DO rules and avoids all the DON'T rules, then replace the bracket with that rendered sentence. If you cannot satisfy the DOs cleanly from the row data, REPLACE THE BRACKET WITH NOTHING (the entire line is omitted, including any leading/trailing whitespace; the surrounding message must read cleanly without it). Aggressive omit > awkward fill. Never leave the bracket itself in the rendered output. Never substitute a placeholder, ellipsis, or generic noun (\`your work\`, \`your team\`) when the FALLBACK clause says omit. Canonical example from the runtime gold pack: \`[PERSONALIZED REASON — their team size, role, or why they're a perfect fit]\` — the model picks whichever input the row supports and writes one short sentence in the sender's voice. Full spec: \`get_subskill_asset({ subskillName: "create-campaign", assetPath: "references/ai-native-tokens.md" })\`. The \`[ALL_CAPS_NAME — ...]\` shape is reserved for AI-native tokens; field substitutions stay as \`{{snake_case}}\` and continue to work as direct value injections. Do not collapse rich personalization into \`{{workflow_context}}\`, \`{{company}}\`, or another field token just because those are easier to list in Token Fill Rules. - **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...`, bare `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: `hope this is relevant if [topic] is part of the plan`, `saw you might be interested in [topic], so hope this is relevant`, `saw you in a few conversations around [topic], so hope this is relevant`, `found you in a few conversations about [topic], so may be off, but this seemed relevant`, `figured this might matter if [workflow] is live at [company]`, or a similarly natural line. Longer source-recap forms such as `you might not remember the thread, but I found you through a [topic] discussion...` are BLOCKED; they narrate the scrape path instead of creating buyer relevance. - **Engagement reference is opt-in, not the default opener:** do not default to `{{first_name}}, saw you {{engagement_context}} on {{post_context}}`, `saw you reacted to...`, or equivalent retrieval-log copy. That reads like surveillance unless the line is self-aware about the weak inference and uses low-certainty language. If that sounds awkward, omit the engagement source and open from role, company, problem, or the approved offer. - **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. - **Brief CTA obedience:** if the brief explicitly names a CTA motion, the selected winner must either preserve that motion's intent with concrete specificity or explain why truth, clarity, pressure, or safety gates forced a replacement. If the brief uses `compare notes`, do not put that phrase in buyer-facing copy. Translate it into a concrete quick-call or working-session CTA that names the topic or workflow. - **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 discuss, see, or get. The next step must be easy to picture. `Open to a quick call on how {{company_or_team}} might turn LinkedIn content into pipeline?` passes because the topic is concrete; `Open to compare notes?` fails because the object is missing and the phrase is stale. - **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. PS source disclaimers are also BLOCKED: do not write `if the source thread was just casual reading, ignore me`, `only reaching out where the role and topic looked close`, or similar sourcing-defense copy. Relevance-risk opt-outs are allowed when they do not defend the source: `p.s. if this is not relevant to your outbound workflow, ignore me.` - **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. Do not write `backed by [X] and focused on [Y]`; "focused on" describes the seller. Translate it to `backed by [X] to help [buyer] [outcome]`, or choose no PS. 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. - **Concrete language audit:** the selected winner must highlight and resolve every abstract verb, abstract noun, abstract adjective, abstract adverb, and cliche that weakens the message. For each highlighted item, replace it with a buyer-visible action, object, workflow, artifact, risk, result, or next step from available evidence; cut it if no safe concrete replacement exists. If a highlighted item remains, the audit must explain why it is buyer-native and clearer than the concrete alternative. Unresolved abstraction or cliche is BLOCKED. - **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. Recipient context may lead only when it is a permissioned relevance bridge or self-aware engagement opener, not a resume recap, compliment, source citation, or `Your X is...` line. Open with what matters to the buyer, why this might be relevant, or the operator-reality that led to it. Acceptable openers: - `Hey {{first_name}}, [one plain sentence about what we built].` - `Hey {{first_name}}, hope this is relevant if [buyer context] is still on your plate.` - `Hey {{first_name}}, saw you might be interested in [topic], so hope this is relevant.` - `Hey {{first_name}}, saw you in a few conversations around [topic], so hope this is relevant.` - `Hey {{first_name}}, found you in a thread about [topic], so may be off, but this seemed relevant.` - `Hey {{first_name}}, saw you raise your hand for [topic], so figured this was (hopefully) worth sending.` Only use this for explicit lead-magnet comments, replies, or opt-ins. - `Hey {{first_name}}, saw you raise your hand for [topic] (creepy to reach out based on that, i know) - but this felt too on the nose to ignore.` Only use this for explicit lead-magnet comments, replies, or opt-ins. - Do not use the flattened line `so figured this was worth sending`; either keep `(hopefully)` or use `so hope this is relevant`. - `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].` - `Hey {{first_name}}, caught your profile and thought...` - `Hey {{first_name}}, your GTM and international growth work at [Company A] and [Company B] looked close to what [Product] is built for.` **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 - the approved template must contain the literal blank lines. Do not fake paragraph spacing by putting each sentence on adjacent single-newline lines. If the template or Selected Winner has 3+ consecutive non-empty prose lines with no blank line between them, mark it `revise-message` / `blocked` and rewrite before approval. - bad shape: `saw you in a few conversations about corporate comms, so may be off, but this seemed relevant.\nyour team probably puts a lot of work into getting people on webinars.\nArbor turns those recordings into ready-to-publish content.` - good shape: `saw you in a few conversations about corporate comms, so may be off, but this seemed relevant.\n\nyour team probably puts a lot of work into getting people on webinars.\n\nArbor turns those recordings into ready-to-publish content.` - 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: - **Prefer bullets when 3 adjacent action lines are maximally parallel**: each starts with the same subject pattern (e.g. `It drafts...` / `It adapts...` / `It helps...`), each is a discrete product function, and none carries narrative context or proof. Use a setup line plus short `-` bullets, e.g. `It helps your team:` then `- Draft posts...`, `- Adapt them...`, `- Keep showing up...`. - **Use one-line paragraphs** when there are only 1-2 actions, at least one action carries a short narrative clause, bullets would feel like a landing page, or the paragraph version is clearly more human and still scans cleanly. - "Conversational motion" alone is **not** a reason to avoid bullets when all 3 action lines repeat the same `It X` structure. - 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. Use bullets as a mobile readability preference for 3 repeated-subject product actions, not as a blanket hard gate. - 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: - `"Hope this is relevant if [topic] is part of the plan."` - `"Saw you might be interested in [topic], so hope this is relevant."` - `"Saw you in a few conversations around [topic], so hope this is relevant."` - `"Saw you in a few conversations about [topic], so may be off, but this seemed relevant."` - `"Found you in a thread about [topic], so may be off, but this seemed relevant."` - `"Thought of {{company}} because [observable signal] points at [problem]."` - `"Figured this might matter if [workflow] is live at {{company}}."` - `"Saw you raise your hand for [topic], so figured this was (hopefully) worth sending."` Only for explicit lead-magnet comments, replies, or opt-ins. - `"Saw you raise your hand for [topic] (creepy to reach out based on that, i know) - but this felt too on the nose to ignore."` Only for explicit lead-magnet comments, replies, or opt-ins. - 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]."` - `"Saw you raise your hand for [topic], so figured this was worth sending."` - `"Figured this was worth sending."` - 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. For LinkedIn-post-sourced campaigns, prefer `"saw you in a few conversations around [topic], so hope this is relevant"` or `"found you in a thread about [topic], so may be off, but this seemed relevant"` when referencing the source makes the outreach feel less random. Avoid activity-log phrasing such as `"you commented on..."`, `"you reacted to..."`, or `"your LinkedIn activity..."` unless the approved motion is the deliberately self-aware raise-hand line for an explicit lead-magnet comment, reply, or opt-in. - tokenized engagement-source opener shape is BLOCKED by default: `{{first_name}}, saw you {{engagement_context}} on {{post_context}}` reads like surveillance unless the filled line is explicitly self-aware and low-certainty. Prefer a concise bridge such as `hope this is relevant if [topic] is part of the plan`, `saw you might be interested in [topic], so hope this is relevant`, `saw you in a few conversations around [topic], so hope this is relevant`, `saw you in a few conversations about [topic], so may be off, but this seemed relevant`, or `found you in a thread about [topic], so may be off, but this seemed relevant`. Use the self-aware raise-hand shapes only when the source was an explicit lead-magnet comment, reply, or opt-in: `saw you raise your hand for [topic], so figured this was (hopefully) worth sending` or `saw you raise your hand for [topic] (creepy to reach out based on that, i know) - but this felt too on the nose to ignore`. Do not use the longer `you might not remember the thread...` shape; if the concise source bridge still feels awkward, omit the engagement reference. - do not describe the sender/client in third person inside the outbound message. `p.s. Saju's angle is...`, `Christian's angle is...`, `[sender]'s approach is...`, and similar lines are internal notes leaking into prospect copy. If the point matters, write it from the sender's voice (`p.s. we usually pair the build with enablement`) or omit it. - 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, narrate the source thread, add a second unrelated offer, or say the quiet part out loud. Lines like `this is not just a platform idea` and `if the source thread was just casual reading, ignore me` are blocked because they sound like internal rationale. A plain relevance-risk opt-out such as `if this is not relevant to your outbound workflow, ignore me` can stay when it lowers pressure without explaining the scrape. 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] to help [buyer segment] [buyer outcome]."` - **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] to help [buyer segment] [buyer outcome]."` - 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 - `"We're backed by [investor] and focused on [category/problem]."` — company-focus copy; translate to buyer outcome or cut - 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 Sellable cleanup rules 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 | Type | Source Field / Instructions | 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, prefer an AI-native token for the full personalization sentence and show the inline Intent / DO / DON'T / FALLBACK contract in the table or immediately below it. Only define a buyer-readable derived token such as `{{workflow_context}}` or `{{role_specialization}}` when it is a clean atomic phrase, and show both its 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; use only for atomic phrases, not sentence-level personalization that needs judgment - `{{account_segment}}` = row-derived account category when it improves fit; fallback brief-level segment only when every row shares it - `[PERSONALIZATION_LINE — Intent: ... DO: ... DON'T: ... FALLBACK: omit]` = AI-native sentence token; source from the lead sample fields that support the DO rules; fallback omit the whole line, never generic filler ## Token Adherence Table | Sample | Supported Tokens Only | All Tokens Resolved | Proof Safe | Personalization Grounded | Sellable Cleanup Rules | 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: ... - Parallel action formatting: bullets used | paragraphs kept | not applicable — reason - Contraction naturalness: PASS | BLOCKED — 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 - Parallel action formatting: preserved bullets | added bullets | paragraphs kept | not applicable — reason - Robustness check: PASS | BLOCKED — reason - Decision: applied | rejected ## Concrete Language Audit | Location | Highlighted Text | Category (`abstract verb` / `abstract noun` / `abstract adjective` / `abstract adverb` / `cliche`) | Why It Weakens Reply Odds | Concrete Replacement | Decision (`applied` / `cut` / `kept as buyer-native`) | | -------- | ---------------- | -------------------------------------------------------------------------------------------------- | ------------------------- | -------------------- | ------------------------------------------------------ | - Rewrite summary: ... - Remaining abstraction/cliche risk: PASS | BLOCKED — reason ## 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 - Brief CTA obedience: PASS | BLOCKED | NOT APPLICABLE — reason - CTA clarity: PASS | BLOCKED — reason - PS restraint: PASS | BLOCKED | OMITTED — reason - Concrete language audit: PASS | BLOCKED — 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 - Single send unit only, with no post-accept DM/follow-up/sequence copy: 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 Sellable cleanup rules - any post-accept DM, follow-up, second touch, cadence branch, or sequence copy in the first-message validation artifact - 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 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 `gold-standard-message-examples.md` as the primary line-level 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 approved pattern. Primary runtime references are: - sellable.dev - Hey Digital - Galley - Clover - Persona Use Superpower only for benefits/healthcare mechanism language and cleaned low-certainty relevance bridges. Use Galley only for matching foodservice, event/demo, or signal-led operator motions. Use Revvix / Spektion and Superposition only for explicit event/logistics or job-post/founder-hiring motions. Do not use Gelee, westpark villas, Amplify Security, or raw old-client archive examples as runtime inspiration unless the caller explicitly provides them as campaign calibration. When the brief is sparse but the motion clearly matches an approved winner, borrow the closest approved 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. Use the quality gates and fallback REPLY framework embedded in this `generate-messages` prompt. Do not call a separate message-prompt tool. 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 real parallelism only when the host explicitly supports it for this run. Prefer product-native MCP/tool parallelism that works in both Claude Code and Codex; host subagents are optional acceleration only when the user explicitly asked for agent fan-out.** 1. Load campaign examples, calibration notes, and bounded copy from the brief first. 2. Use the quality gates and fallback REPLY framework embedded in this `generate-messages` prompt. 3. If the user explicitly asked for agent fan-out and the host exposes subagents, spawn parallel workers with explicit model/config. Otherwise batch independent MCP/tool reads where available or run rows sequentially with honest progress copy. Do not claim subagents or background work unless they actually started. ``` For each row (1-5), launch a worker only when allowed: - 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 worker or sequential row pass: - 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 workers to complete, or finish the sequential row pass 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 ``` ### Optional Worker Prompt Template When spawning craft workers, 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 core identity/company memory or composed core memory} - Signature phrases: {3-5 key phrases} - Background: {1-2 lines} ## Voice + Outbound Rules (condensed — full files available via Read tool) - Use `~/.sellable/configs/core/context-modes.md` to choose the right context stance, then run an anti-AI audit against `~/.sellable/configs/core/anti-ai-writing-style.md` before returning copy. - Flow skeleton: opener → pain → **what the product IS** → **what it DOES** (one action per line, up to three; prefer short bullets for 3 repeated-subject product actions) → 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 - The approved template must include actual double-newline paragraph breaks. Never approve or return a body with 3+ consecutive non-empty prose lines separated only by single newlines. - 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 feature/benefit marketing bullet lists, no "I noticed...", no compliment sandwiches, no em dashes unless the canonical example uses one. Exception: use a short bullet stack when 3 adjacent product actions repeat the same subject pattern and bullets improve mobile readability. - 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 {quality gates and fallback REPLY rules embedded in this generate-messages 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. If explicit host subagent fan-out is available, fan out 10 angle workers (model: "sonnet", no delayed/background notifications). Otherwise explore a smaller bounded set of angles sequentially and do not claim parallelism: - 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 the sender's core identity, context mode, and signature phrases - Proof-check every claim against `proof-ledger.md`, `wins-ledger.md`, or the campaign brief - Run an anti-AI audit and cut phrasing that sounds synthesized, over-shaped, or proof-laundered - 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/core/about-me.md`, `~/.sellable/configs/core/my-company.md`, `~/.sellable/configs/core/context-modes.md`, `~/.sellable/configs/core/proof-ledger.md`, `~/.sellable/configs/core/wins-ledger.md`, `~/.sellable/configs/core/anti-ai-writing-style.md`, `~/.sellable/configs/writing/outbound.md`, and `~/.sellable/insights/cross-skill.md` once in the lead agent. Use the legacy style guide fallback when present. Pass condensed versions to workers so context stays focused. ## Batch Approval After batch generation in campaign-table mode, approve the actual visible `Approved` cells. Resolve them semantically first; do not rely on `approveCellId` from row reads unless it matches the selector result. ``` select_campaign_cells({ columnRole: "approved", rowSelector: { type: "rowIds", rowIds: reviewedRowIds } }) update_cell(returnedApprovedCellId1, true) update_cell(returnedApprovedCellId2, true) ``` Or approve individually after reviewing in UI.