@sellable/mcp 0.1.213 → 0.1.215

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,7 +138,7 @@ 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.
 
@@ -158,17 +157,17 @@ Read these campaign inputs:
 - `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 the
-required pre-draft reference pack below with `mcp__sellable__get_subskill_asset`.
-This is a hard gate: if the four required pre-draft assets are not loaded,
+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
-`Reference Asset Loading` note naming each loaded asset and whether it was
-required pre-draft, final-pass, dry-mode-only, or token-rules-only. Do not
+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.
 
@@ -176,21 +175,22 @@ Use `mcp__sellable__get_subskill_asset` for packaged assets:
 
 | Group | Asset to load | Job |
 | --- | --- | --- |
-| Always load before drafting | `subskillName: "create-campaign-brief", assetPath: "references/phase75-active-runtime-message-pack.md"` | Active line-level gold pack: real approved examples, short-line rhythm, CTA blocks, lowercase/titlecase cues, and PS restraint. |
+| 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 | `subskillName: "create-campaign-v2", assetPath: "references/gold-standard-message-examples.md"` | 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 (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/thomas-revision-filters.md"` | Substance filters: earned-right, presumption, vague proof, read-as-1:1, founder-origin coherence, anti-talk-at, and AI-tell filter. |
+| 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. |
-| 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. |
-| 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. |
 
 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.
@@ -198,18 +198,18 @@ Path-like names in this section are package asset coordinates for MCP loading.
 
 Default load order:
 
-1. Load the 4 **Always load before drafting** assets. Do not infer their
+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. Load `thomas-revision-filters.md` before approval, `confirmed`, or template
-   recommendation.
+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`.
-6. Load token-rule references only when creating reusable templates or Token
-   Fill Rules that need sentence-level personalization.
+
+Do not load retired branch/runtime packs.
 
 ### Rich Personalization Contract
 
@@ -255,14 +255,16 @@ winner gate**.
 
 ### Retrieval & motion
 
-- treat `gold-standard-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
@@ -282,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`)
@@ -405,11 +407,42 @@ artifact.**
    - `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.
+   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
@@ -804,6 +837,13 @@ 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
@@ -973,7 +1013,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
@@ -1070,6 +1110,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:
 
@@ -1154,11 +1208,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
@@ -1280,7 +1340,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.
@@ -1725,6 +1785,9 @@ PO from your inbox?` beats `worth 15 min to compare notes?` because the
   (`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
@@ -2150,7 +2213,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
@@ -2164,14 +2227,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
@@ -2182,7 +2246,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:
 
@@ -2388,7 +2452,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
@@ -2607,7 +2671,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
@@ -2619,7 +2683,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
@@ -2659,27 +2723,27 @@ too generic, diagnose the gap precisely:
 
 Then tighten the brief or calibration notes before scaling.
 
-Use the v2 runtime gold pack 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 approved references are:
+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 / HeyDigital
+- Hey Digital
 - Galley
 - Clover
 - Persona
 
 Use Superpower only for benefits/healthcare mechanism language and cleaned
-low-certainty relevance bridges. 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 approved shape from `gold-standard-runtime-message-pack.md`
-first, then use `gold-standard-message-examples.md` only for strategy skeletons
+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

package/skills/research/config.json

@@ -0,0 +1,9 @@
+{
+  "parallelMode": "wide",
+  "agentCount": 6,
+  "maxToolCallsPerAgent": 2,
+  "senderMaxAgents": 2,
+  "senderMaxToolCallsPerAgent": 3,
+  "progressMode": true,
+  "debugMode": true
+}