@sellable/mcp 0.1.212 → 0.1.214

package/skills/generate-messages/SKILL.md

@@ -6,10 +6,11 @@ visibility: internal
 
 # Generate Messages
 
-You craft messages in one of two modes:
+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 Phase 84 validation artifacts before any live campaign exists
+- caller-declared DRY MODE for offline validation artifacts before any live
+  campaign exists
 
 ## Tools
 
@@ -28,37 +29,35 @@ You craft messages in one of two modes:
 
 ### Mode 0: Message Drafting Branch
 
-Use this mode when create-campaign-v2 starts background Message Drafting after
-`confirm_lead_list` copies source rows and the first
-review/process sample exists.
-This is not the row-cell generation path.
-
-Inputs must come from the parent thread or scoped MCP/product tools for the
-current workspace/campaign:
-
-- campaign id plus campaign revision or `updatedAt`
-- current campaign brief and a brief hash
-- selected source state and `selectedLeadListId`
-- `workflowTableId`
-- imported review-batch contacts, row ids, and review-batch row hash
-- filter choice at branch start, plus filter/rubric basis when present
+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.
+
+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 review-batch row ids/hash do not match. Do not reconstruct state from
-stale local markdown artifacts or direct database reads.
-
-Before drafting, load the packaged reference assets in "Reference Asset Loading"
-below through `mcp__sellable__get_subskill_asset`. In customer/package runs,
-the `mcp/sellable/skills/...` strings are asset identifiers, not local files.
-Do not use shell commands, local `Read`, `rg`, `cat`, `wc`, plugin-cache paths,
-repo paths, or `/Users/...` paths to load them. If a required asset cannot be
-loaded through the MCP asset loader, return `blocked` or `retry-needed` instead
-of drafting from memory.
-
-Return message-draft output only: template recommendation, token fill rules,
-rendered sample, concerns, status, basis token, output timestamp/hash, and error or
-retry detail. Do not write message cells, enrich rows, update the campaign
-brief, attach sequence, or imply send readiness from this branch.
+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
 
@@ -92,18 +91,18 @@ to live mode drafts, with live-mode-specific allowances:
 - personalization from research is allowed, but it does not replace the
   "what the product IS" / "what it DOES" anchors
 - save behavior and calibration loop follow the live-mode workflow below,
-  but the drafted message itself is subject to the same Thomas revision
+  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`, `Phase 84`,
+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 create-campaign-v2
-  Prospect Setup step, message generation may start before
+- `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.
 
@@ -139,49 +138,87 @@ Required dry-mode contract:
 If the dry-mode response is missing the no-mutation preamble, treat that as a
 hard failure and revise the output before returning it.
 
-## Phase 84 Dry-Mode Validation
+## Offline Validation
 
 Dry mode validates message quality before campaign mint.
 
-Read the campaign-specific dry-mode inputs from the caller's dry-run workspace:
+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
+- `~/.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" })`
 
-## Reference Asset Loading
+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.
 
-These references are packaged in `@sellable/mcp` and must be loaded through the
-Sellable MCP asset loader in live/customer runs. Continue each asset load with
-the returned `nextOffset` until `hasMore` is false.
+Default load order:
 
-- `mcp__sellable__get_subskill_asset({ subskillName: "create-campaign", assetPath: "references/ai-native-tokens.md" })`
-- `mcp__sellable__get_subskill_asset({ subskillName: "create-campaign", assetPath: "references/token-fill-examples.md" })`
-- `mcp__sellable__get_subskill_asset({ subskillName: "create-campaign-brief", assetPath: "references/phase75-active-runtime-message-pack.md" })`
-- `mcp__sellable__get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/validation-criteria.md" })`
-- `mcp__sellable__get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/thomas-revision-filters.md" })`
-- `mcp__sellable__get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/gold-standard-message-patterns.md" })`
-- `mcp__sellable__get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/gold-standard-message-examples.md" })`
-- `mcp__sellable__get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/gold-standard-message-validation-example.md" })`
+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 satisfy the list above by searching or reading the local filesystem.
-Path-like names in this section are package asset coordinates for MCP loading.
+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
@@ -218,14 +255,16 @@ winner gate**.
 
 ### Retrieval & motion
 
-- treat `phase75-active-runtime-message-pack.md` as the **real line-level
-  gold pack** for active clients and proven live message shapes
-- retrieve against the full archived gold-standard library and pick the closest 2-4 examples for consideration
-- use the runtime pack first for concrete formatting cues that the
-  abstract archive may flatten away: lowercase vs title case, exact
-  `two options:` formatting, short line rhythm, and load-bearing
-  `p.s.` lines
-- treat the archive as the **quality bar and motion reference**, not a paste source. Your job is to write a new message that could plausibly belong in the archive, not to recolor an existing one
+- 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
@@ -245,7 +284,7 @@ winner gate**.
   packaging tools. Use them only when they make the strongest true reason more
   compelling or easier to reply to.
 - **exact-template preservation only applies when the archived winner is the same company as the brief** (e.g., Superposition drafting for Superposition). In that case preserve casing, spacing, CTA shape, and proof ordering, and change only the documented tokens. For every other case, match the quality bar and motion shape; do not recolor the exemplar's wording
-- if the runtime pack shows a proven same-company or same-motion line that is
+- 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`)
@@ -348,6 +387,8 @@ artifact.**
    - `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:
 
@@ -355,25 +396,49 @@ artifact.**
    - `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`
-   - `may be off, but if {{workflow_signal}} is anywhere near your lane, this might be useful`
-   - `if {{workflow_signal}} is nowhere near your lane, ignore me`
+   - `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}}`
-   - `saw you raise your hand for {{signal_topic}}, so figured this was (hopefully) worth sending` only when the engagement signal is the actual source
-   - `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 engagement signal is the actual source and the sender's voice can carry the cheekier aside
-
-   For LinkedIn-post-sourced campaigns (commenters, reactors, lead magnet
-   replies, or scraped conversations), it is acceptable to reference the
+   - `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
+
+   For sender-owned 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.
+   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.
+   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 anywhere near your
-   lane...`, `if this is nowhere near your outbound workflow, ignore me`, `hope
+   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.
 
@@ -402,7 +467,7 @@ Selected Winner, check it against these gates:
 - **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 anywhere near your lane...`.
+  `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
@@ -421,7 +486,9 @@ Better:
 - `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.`
-- `may be off, but if outbound is anywhere near your lane, this might be useful.`
+- `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
@@ -664,18 +731,17 @@ help...` or `built for [buyer] to...`. Do not overuse generic solved-state
   solved, or fail to connect to the specific sample row. Prefer a concrete
   row-fit line, a useful artifact, or a buyer-owned current-state observation
   that the recipient can understand without reading the brief.
-- if 3 adjacent mechanics, objection removers, proof points, or CTA
-  options are genuinely parallel and easier to understand as a short
-  `-` bullet stack, use the bullet stack in the winner. Do not reserve
-  this for cleanup. Use bullets when they make the buyer picture the offer
-  faster on mobile. If the product has 3+ plain mechanics such as pricing
-  control, take-rate/economics, malpractice, credentialing, billing, async
-  chat/photo care, or setup speed, prefer a compact bullet stack over
-  separate prose lines unless bullets would make the note feel like a
-  landing page. For data / intelligence products, if the buyer receives 3+
-  concrete output types (e.g. accounts, infrastructure, signals, alerts,
-  records, reports), prefer a short bullet stack over a dense mechanism
-  paragraph.
+- 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)
@@ -740,12 +806,23 @@ Finalizer preference when multiple candidates are otherwise comparable:
   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, the CTA must name the
-  useful return artifact, preview, teardown, or working session.
+  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?"
@@ -842,6 +919,9 @@ 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
@@ -902,7 +982,7 @@ Message-validation artifact budget:
 
 **Substance-filter gate before the Finalizer Pass:** each candidate is
 checked against the 8 Substance Filters in
-`../create-campaign-v2/references/thomas-revision-filters.md` (Earned-
+`../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
@@ -955,7 +1035,10 @@ Before drafting, answer these five questions explicitly:
 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.
+   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:
 
@@ -996,6 +1079,20 @@ Return `revise-message` with the missing strategy pieces.
 
 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:
 
@@ -1006,6 +1103,23 @@ both choices are genuinely useful and supported:
 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.
@@ -1063,11 +1177,17 @@ message / artifact] was made with [product].`
    lowers "is this real?" / "will this company be around?" risk without
    bloating the body. Its job can be legitimacy, not direct persuasion:
    it answers whether the company and offer are real enough to take a look.
-   It must still tie the backing to the buyer segment, product boundary, or
-   buyer outcome instead of flashing a badge. Shapes:
+   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 backer] and focused on
-[specific buyer segment / problem].` Keep it short and test it against no-PS.
+[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.`
 
 If YC, notable backing, funding, or named investor proof is present AND
 the buyer is in healthcare, financial services, security, enterprise, or
@@ -1118,7 +1238,7 @@ 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 nowhere near your outbound workflow, ignore me.`
+source: `p.s. if this is not relevant to your outbound workflow, ignore me.`
 
 ### Raw proof translation test (HARD INVARIANT)
 
@@ -1189,7 +1309,7 @@ Truth is not enough. The line must do a job for the prospect.
 
 ### Single-send-unit gate (HARD INVARIANT)
 
-Dry-mode create-campaign-v2 message generation approves the **first outbound
+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.
@@ -1584,6 +1704,13 @@ 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
@@ -1598,8 +1725,11 @@ teardown`, `record a video`, or similar assets are BLOCKED unless the
 artifact / preview] you can [use/check/compare]?`.
 - **CTA specificity:** generic CTAs like `compare notes`, `worth a chat`,
   `open to a call`, or `quick walkthrough` are BLOCKED unless the same
-  line names the specific thing the buyer will compare, see, or get. The
-  next step must be easy to picture.
+  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
@@ -1617,13 +1747,16 @@ PO from your inbox?` beats `worth 15 min to compare notes?` because the
   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 nowhere near your outbound workflow, ignore me.`
+  `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
@@ -1688,8 +1821,11 @@ led to it. Acceptable openers:
 - `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}}, saw you raise your hand for [topic], so figured this was (hopefully) worth sending.`
-- `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.`
+- `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
@@ -1900,10 +2036,18 @@ Flow skeleton (apply even when motion varies):
 2. Pain — what's breaking now
 3. **What the product IS** — one crisp sentence naming the product and what category of work it takes on. Example shape: `[Product] is [a category-noun] that [takes a specific class of work off the buyer's plate]`. When the offer is for the buyer's exact role/credential, prefer `lets you...` or `[role]s like you...` over `lets a [role]...` so the buyer does not feel treated like an outsider. Archive-anchored illustrations: Galley's "AI that reads the messiest BEOs and turns them into production-ready plans"; Revvix's "shows what's actually exploitable on your endpoints based on runtime activity".
 4. **What the product DOES** — one action per line. Three actions maximum. Choose the rendering by a **concrete test**, not a feeling:
-   - **Use bullets when the action lines are maximally parallel**: each starts with the same subject (e.g. `It X` / `It Y` / `It Z`), each is a discrete product function, none carries narrative context. This is the default case.
-     - Example shape: `- [Verb] [concrete object from the buyer's workflow].`
-   - **Use one-line paragraphs only when at least one action carries a short narrative clause** that wouldn't fit cleanly in a bullet.
-   - "Conversational motion" is **not** a reason to prefer paragraphs. If the three actions all start with `It X`, they are parallel by definition and should render as bullets.
+   - **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
@@ -1912,7 +2056,9 @@ Flow skeleton (apply even when motion varies):
 Rules within the flow:
 
 - **banned**: comma-stacking three actions into one glued sentence (e.g. `"order intake, inventory sync, and reorder timing"` glued together). Split into one action per line.
-- **preferred**: one action per line — as one-line paragraphs or as a bullet list, whichever reads cleaner (see below)
+- **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
@@ -1930,10 +2076,11 @@ Rules:
   - `"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."`
-  - `"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."`
+  - `"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]."`
@@ -1942,7 +2089,9 @@ Rules:
   - `"Saw you on [topic]."`
   - `"Saw you around [topic]."`
   - `"Saw you engaging with [topic]."`
-- signal-led opener shape is a **special case**, not the default. Use it only when the archived motion truly depends on it and the line can stay natural. For LinkedIn-post-sourced campaigns, prefer `"saw you in a few conversations around [topic], so hope this is 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.
+  - `"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
@@ -1950,11 +2099,12 @@ Rules:
 [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 one of the self-aware raise-hand shapes when the source is the
-actual reason for the note: `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;
+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
@@ -2016,8 +2166,8 @@ 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 nowhere near your outbound workflow,
-ignore me` can stay when it lowers pressure without explaining the scrape.
+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.
 
@@ -2032,7 +2182,7 @@ Rules:
 - write the PS in a voice the reader can place:
   - if the **sender is the founder/operator**, write in `I` voice. Archive anchor: Superposition's `"I placed the first engineering hire at Brex."`
   - if the **sender is not the founder**, use `our CEO`, `our team`, or `we` as the anchor — never drop a bare first name with no anchor. Shape: `"Our CEO [did the prior thing that shows they understand this buyer's pain]."`
-  - `our team` and `we` voices work well for backing, funding, or collective proof. Shape: `"Our team is backed by [investor] because they're seeing the same [buyer pain] everywhere we look."`
+  - `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
@@ -2046,14 +2196,15 @@ Rules:
   - 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):
+  - examples of good shapes (abstract — to be instantiated from the brief's safe-claims list, not copied):
   - `"Our CEO [ran a comparable operation before this], so the product is built for how [buyer-specific failure mode] actually breaks."`
   - `"I spent [X years] watching this exact [named handoff] fall apart at a previous role, which is why the first thing we built fixes it."`
-  - `"Our team is backed by [named investor] because they're seeing the same [buyer pain] at every [segment] we talk to."`
+  - `"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
@@ -2064,7 +2215,7 @@ Rules:
 - reject personalization that cannot be traced to `lead-sample.json`
 - keep proof claims inside the brief's safe-claims boundary
 - use only signals validated in `lead-sample.json`
-- pass the Thomas revision filters before returning
+- pass the Sellable cleanup rules before returning
 
 When token sourcing is weak:
 
@@ -2270,7 +2421,7 @@ hiring for`
 
 ## Token Adherence Table
 
-| Sample | Supported Tokens Only | All Tokens Resolved | Proof Safe | Personalization Grounded | Thomas Filters | Result |
+| Sample | Supported Tokens Only | All Tokens Resolved | Proof Safe | Personalization Grounded | Sellable Cleanup Rules | Result |
 | ------ | --------------------- | ------------------- | ---------- | ------------------------ | -------------- | ------ |
 
 ## Message Element Plan
@@ -2388,7 +2539,7 @@ hiring for`
 - Best CTA: Candidate [A|B|C] — reason
 - Best PS / no-PS decision: Candidate [A|B|C] — reason
 - Element edits made by finalizer: ...
-- Bullet-stack decision: used | rejected | not applicable — reason
+- Parallel action formatting: bullets used | paragraphs kept | not applicable — reason
 - Style consistency check: PASS | BLOCKED — reason
 - Assembly note: clean combination or one candidate swept
 
@@ -2397,7 +2548,7 @@ hiring for`
 - Original winner: ...
 - Simplified candidate: ...
 - Simplifier edits: combined lines | split dense line | preserved bullet stack | added bullet stack | none
-- Bullet-stack decision: preserved | added | rejected | not applicable — reason
+- Parallel action formatting: preserved bullets | added bullets | paragraphs kept | not applicable — reason
 - Robustness check: PASS | BLOCKED — reason
 - Decision: applied | rejected
 
@@ -2420,6 +2571,7 @@ hiring for`
 - 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
 - YC / backing PS: PASS | BLOCKED | OMITTED — reason
@@ -2488,7 +2640,7 @@ Automatic failures in dry mode:
 - invented proof or personalization
 - no compelling proof element despite the brief supporting one
 - a CTA that depends on missing proof
-- copy that fails the Thomas revision filters
+- 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
@@ -2500,7 +2652,7 @@ Automatic failures in dry mode:
 Goal: lock tone + offer with 1-3 examples before scaling.
 Only hard requirement: draft at least one message before batch; saving examples is strongly recommended but optional.
 
-Before drafting, read any Phase 75 brief-calibration assets already present:
+Before drafting, read any brief-calibration assets already present:
 
 - the campaign brief itself
 - any "Messaging Calibration" section saved back into the brief
@@ -2540,22 +2692,28 @@ too generic, diagnose the gap precisely:
 
 Then tighten the brief or calibration notes before scaling.
 
-Use the example bank as the primary strategy source even when the brief does
-not already contain winning examples. Do not default to generic REPLY-style
-copy when the motion clearly matches a tighter archived pattern. Strong
-references include:
+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
+- sellable.dev
+- Hey Digital
 - Galley
-- Gelee
-- HeyDigital
-- Revvix / Spektion
-- Superposition
-- Persona Digital
+- 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 archived winner,
-borrow the closest message shape from
-`gold-standard-message-examples.md` before inventing a new structure.
+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
 
@@ -2639,12 +2797,12 @@ research → condense → 10 angle agents in parallel → finalizer combines bes
 - 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) → deployment ease → CTA → optional PS
+- 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
 - 5th-grade reading level by default. Cut glue language (handoff, order-to-cash, rip-and-replace). Keep brief-native product/tool names (Shopify, HubSpot)
-- No bullet points, no "I noticed...", no compliment sandwiches, no em dashes unless the canonical example uses one
+- No 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
@@ -2706,7 +2864,7 @@ research → condense → 10 angle agents in parallel → finalizer combines bes
 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.
+**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