@sellable/mcp 0.1.213 → 0.1.215

package/skills/create-campaign-v2/references/gold-standard-message-patterns.md

@@ -1,6 +1,6 @@
 # Gold-Standard Message Patterns
 
-Use these patterns when validating or drafting messages for `create-campaign-v2`.
+Use these patterns when validating or drafting Sellable campaign messages.
 
 The priority is not "write generally good outbound." The priority is:
 
@@ -193,14 +193,15 @@ Shape:
 - plain signal mention first
 - one line that makes the relevance feel honest
 - simple product framing
-- binary options
+- specific low-friction next step
 - optional short `PS` with proof as the final line
 
 Prefer:
 
 - lowercase or casual casing when the motion supports it
-- an honest line like "hope this is relevant" or "so hopefully relevant"
-- two clean options instead of a long CTA paragraph
+- an honest line like "hope this is relevant" or "so may be off, but this seemed relevant"
+- a concrete CTA that names the useful conversation or asset
+- binary options only when the brief explicitly supports two real next steps
 - direct wording over polished marketing language
 
 Avoid:
@@ -229,11 +230,11 @@ Use only when event, signal, and hiring hooks are unavailable.
 
 This is the fallback most likely to drift into bland copy, so keep it tight.
 
-**Exemplar:** Example 2 in `gold-standard-message-examples.md` (Stack-Replacement
-Operator Diagnostic). It is the default proof-led fallback exemplar. Its
-rhythm — observed current-state → what breaks → product-name-first mechanism →
-PS for credibility — generalizes across proof-led fallbacks even when the
-category isn't literally stack-replacement.
+Use the proof-led fallback logic below directly. Do not retrieve a deleted
+stack-replacement archive example as copy. The useful rhythm is: observed
+current-state → what breaks → product-name-first mechanism → strongest true
+proof or useful CTA. That rhythm generalizes across proof-led fallbacks even
+when the category is not literally stack replacement.
 
 Shape:
 
@@ -277,6 +278,9 @@ Prefer:
 - product-name-first mechanism lines when the product can be named cleanly
 - a short `PS` for social proof, backing, prior-company proof, or category-first
   proof when that proof is real and would otherwise bloat the main body
+- backing proof in a `PS` must translate into buyer value, not seller focus:
+  `backed by [X] to help [buyer segment] [buyer outcome]` beats
+  `backed by [X] and focused on [category/problem]`
 - if a `PS` is used, keep it to the final line of the message
 - short words and plain sentences a busy buyer can scan fast
 - one sentence per line in the final draft when the channel is InMail or email

package/skills/create-campaign-v2/references/gold-standard-message-validation-example.md

@@ -19,7 +19,7 @@ Status: confirmed
 Mode: DRY MODE (no DB mutation)
 Template Used: event-led canonical template
 Primary Example: Example 1 — Revvix / Spektion Event-Led Security
-Secondary Influence: Example 7 — Useful CTA Shapes (binary option)
+Secondary Influence: Example 6 — Useful CTA Shapes (binary option)
 Lead Sample Basis: 3 validated leads (Dana Patel — VP Security Eng at Arco;
 Mariko Stein — Head of AppSec at Fernway; Ben Oduya — Director, Vuln Mgmt
 at Plantform)
@@ -52,7 +52,7 @@ No other tokens are allowed in this campaign.
 
 ## 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 |
 | ------ | --------------------- | ------------------- | ---------- | ------------------------ | -------------- | ------ |
 | Dana   | yes                   | yes                 | yes        | yes                      | pass           | pass   |
 | Mariko | yes                   | yes                 | yes        | yes                      | pass           | pass   |
@@ -135,7 +135,7 @@ No other tokens are allowed in this campaign.
 - Best bridge: **Candidate A** — single-line transition from pain to
   mechanism without editorializing.
 - Best CTA: **Candidate C** — "Happy to grab coffee or send a short
-  overview first" is the binary option from Example 7 and matches the
+  overview first" is the binary option from Example 6 and matches the
   low-pressure event motion better than A's open-ended close.
 - Assembly note: clean combination — opener from C, bridge + mechanism from
   A, CTA from C, plus a new short `PS` carrying the rank-5 founder proof
@@ -203,7 +203,7 @@ No other tokens are allowed in this campaign.
   generic credibility sentence."
 - Token fill rules are declared once, with source fields and fallbacks, and
   the adherence table reports pass/fail per lead.
-- The "What Good Looks Like" bar in `thomas-revision-filters.md` is met:
+- The "What Good Looks Like" bar in `sellable-cleanup-rules.md` is met:
   sharp voice, grounded personalization, motion-aligned structure, useful
   CTA proportional to signal.
 

package/skills/create-campaign-v2/references/lead-validation-preview.md

@@ -1,6 +1,6 @@
 # Lead Validation Preview
 
-This reference defines the Phase 84 `find leads` output contract.
+This reference defines the `find leads` output contract.
 
 ## Inputs
 

package/skills/create-campaign-v2/references/parallel-critique-protocol.md

@@ -1,14 +1,14 @@
 # Parallel Critique Protocol
 
-This reference governs the optional Step 15 critique pass introduced in
-Plan 85-03. Load this file whenever `messaging.critique.enabled === true`
+This reference governs the optional Step 15 critique pass. Load this file
+whenever `messaging.critique.enabled === true`
 in `core/auto-execute.yaml`. When the flag is `false`, the plain Step 15
 path runs unchanged and none of the protocol below applies.
 
 ## Principle
 
 Step 15 (`auto-execute-messaging`) already generates messages under the
-Phase 84 token contract. The critique pass is a bounded, opt-in quality
+offline-validation token contract. The critique pass is a bounded, opt-in quality
 lens on top of that output. It is NOT a second drafting pass. It never
 invents new tokens, new proof, or new personalization, and it never
 ships a rewrite that violates the token contract.
@@ -20,7 +20,7 @@ The critique pass is:
 - **Parallel.** Three fixed critic groups (targeting, copy, voice)
   run in parallel and return structured JSON.
 - **Synthesized.** One synthesis step merges the three voices into a
-  single rewrite and re-runs the Phase 84 finalizer pass.
+  single rewrite and re-runs the offline-validation finalizer pass.
 - **Budget-capped.** A trip on `budgetUsdCap` HALTS critique for the
   remaining sample and continues the plain tail. Cost never explodes
   silently.
@@ -47,8 +47,8 @@ calibration.
 - `lead-sample.json`, `lead-filter.md`, `brief.md` (read-only — these
   are the same artifacts the plain drafter used).
 - `messaging.critique.*` config values from `auto-execute.yaml`.
-- The Phase 84 token contract rules in
-  `references/thomas-revision-filters.md`.
+- The offline-validation token contract rules in
+  `references/sellable-cleanup-rules.md`.
 
 ## Step Shape
 
@@ -201,7 +201,7 @@ the protocol file).
 
 Rules:
 
-1. **Token contract first.** The synthesizer enforces the Phase 84
+1. **Token contract first.** The synthesizer enforces the offline-validation
    token contract verbatim:
 
    - Use only tokens documented in `brief.md` as supported fields.
@@ -216,7 +216,7 @@ Rules:
    voice. Do not blend two motions into one rewrite.
 
 3. **Finalizer pass last.** If `synthesis.enforceFinalizerPass` is
-   `true` (default), re-run the Phase 84 finalizer pass on the
+   `true` (default), re-run the offline-validation finalizer pass on the
    synthesis output. The finalizer is the last guardrail against
    critic-introduced token drift. A finalizer failure falls back to
    the plain message for that row.
@@ -346,14 +346,14 @@ passes.
 
 ## Hard Rules
 
-- Critique is OFF by default. Plan 85-02 never flips the flag.
+- Critique is OFF by default. The plain campaign tail never flips the flag.
 - Sample size is bounded by `messaging.critique.sampleSize`. The
   pass NEVER runs against the full cohort.
 - Three critic groups only: targeting, copy, voice. Do NOT add a
   fourth.
 - Every critic returns the structured JSON envelope above. Free-form
   critic output is discarded.
-- The synthesizer enforces the Phase 84 token contract verbatim.
+- The synthesizer enforces the offline-validation token contract verbatim.
 - The synthesis step MUST re-run the finalizer pass when
   `enforceFinalizerPass === true` (default).
 - Opus is reserved for the highest-value subset only and gated

package/skills/create-campaign-v2/references/sample-validation-loop.md

@@ -1,6 +1,6 @@
 # Sample Validation Loop
 
-This reference governs Step 14 (`validate-sample`) of the Plan 85-02
+This reference governs Step 14 (`validate-sample`) of the
 autonomous tail. Load this file before enriching + scoring the sample, and
 on every revision round.
 
@@ -243,9 +243,9 @@ Action: autonomous `update_campaign_brief` with the specific diagnostic
 (e.g. "add case-study proof for pain point Y"). Rerun sample. Increment
 revisionRound.
 
-#### Worked example — horizontal-SaaS seniority drift (Plan 95-03 Ambral)
+#### Worked example — horizontal-SaaS seniority drift
 
-Symptom observed during Plan 95-03 Ambral walkthrough: 14/30 (47%)
+Symptom observed during an Ambral walkthrough: 14/30 (47%)
 sample was FIT+MAYBE, but the MAYBE cluster was driven by sub-D-round
 "VP Customer Success" titles. These rows match the title whitelist but
 likely don't own budget at that stage.

package/skills/create-campaign-v2/references/{thomas-revision-filters.md → sellable-cleanup-rules.md}

@@ -1,6 +1,6 @@
-# Thomas Revision Filters
+# Sellable Cleanup Rules
 
-Use these filters before Phase 84 message validation is marked `confirmed`.
+Use these filters before offline message validation is marked `confirmed`.
 
 Read "What Good Looks Like" first. These are the positive targets. Use
 "Automatic Revisions" as the rejection backstop, not the primary lens.
@@ -75,6 +75,7 @@ Revise or reject the sample when any of these happen.
 - **category-level opener used when a per-lead signal exists** — if `lead-sample.json` carries any per-lead signal (post, hire, visible tool, topic engagement), the opener must reference it. Category-level openers of shape `"Most [category] teams still do X by hand"` are only acceptable when zero per-lead signal is in the sample. When a category-level opener is used as fallback, Findings must flag it explicitly
 - **mind-reading from engagement signals** — a topic engagement, post, public activity, role, company, or hiring trigger does not prove buyer intent. Reject phrases like `"AI-GTM stack is clearly on your mind"`, `"you're clearly focused on..."`, `"obviously relevant"`, or `"already thinking about..."` unless that exact priority is explicitly present in `lead-sample.json`. Translate to low-certainty buyer context or omit the signal from copy.
 - **source-y signal narration** — reject `"saw you on..."`, `"saw you engaging with..."`, `"you commented on..."`, `"your LinkedIn activity..."`, `"you might not remember the thread..."`, `"found you through [source] and your role looked close..."`, or any line that makes the recipient feel watched unless the chosen archived motion is intentionally self-aware about the signal. For sender-owned LinkedIn post sources, a light first-person acknowledgment is allowed when row data proves a reaction/comment: `"appreciate you showing some love on my post about [topic]"` or `"thanks for showing support on my [topic] post"`. Do not name a comment unless comment text is present. Follow the acknowledgment with a soft relevance bridge before broad pain/product copy, e.g. `"figured this might be relevant if LinkedIn is becoming more of a GTM channel for [company]"`. For third-party LinkedIn-post-sourced campaigns, a topic-level bridge is allowed when it explains why the note exists and stays apologetically uncertain: `"saw you in a few conversations about [topic], so may be off, but this seemed relevant."`, `"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."` Reserve `"raise your hand"` language for explicit lead-magnet comments, replies, or opt-ins. Translate the signal into natural buyer context or omit it.
+- **sender-owned source rendered as third-party** — hard fail when the source post is sender-owned and the draft says `"found you in a thread"`, `"saw you in a thread"`, `"saw you in conversations"`, or `"saw you in a few conversations"` as if the post were third-party. For sender-owned sources, the copy must either use a light first-person acknowledgment plus a soft relevance bridge, or omit the source line. If multiple senders may send the campaign, or the final sender/source-owner match is ambiguous, do not assume a specific `my post` voice or name a specific sender; omit the sender-owned source line until row-level sender ownership is proven. Neutral low-certainty thread/source language is only for truly third-party sources.
 - **fake line-to-line continuity** — reject line stacks where the source acknowledgment, relevance bridge, product line, and CTA do not actually build on each other. Each line must make the next line feel earned. If two adjacent lines could be swapped, deleted, or joined with `"anyway"` without changing the meaning, the transition is fake. In sender-owned post campaigns, the chain should be: support on my post -> why this topic may matter for the company -> what the product/problem does about that same topic -> low-friction next step.
 - **assumptive title-fit opener** — reject `"Your [role] role at [company] looked close to this problem"` or `"looked close to this outbound campaign problem"`. This asserts fit from title/company. Keep the apologetic uncertainty instead: `"may be off, but if [workflow] is relevant to what you're working on..."`.
 - **internal-metric flex** — reject compute time, token/cache details, model names, agent-counts, orchestration internals, or similar process metrics unless the brief proves the buyer cares about that exact detail. `~5 min of compute per message` is not buyer value by itself.
@@ -99,6 +100,7 @@ Revise or reject the sample when any of these happen.
 - **full titles in the PS when the bare role word would read more natural** — "our CEO [did X]" reads more natural than "CEO Alex, 2x founder, [did X]". Drop titles unless the title itself is the proof
 - more than two proof beats in the PS (three or more reads as a resume dump)
 - a proof beat that is not tied to the buyer's situation — proof should explain why this sender gets the buyer's pain, not just list credentials
+- **backing proof ends in seller-focus copy** — reject `backed by [X] and focused on [category/problem]`. Keep the backing only if the same line turns into buyer value, e.g. `backed by [X] to help [buyer segment] [buyer outcome]`; otherwise cut the PS
 
 **Motion alignment**
 
@@ -453,17 +455,17 @@ Tell #8 hardcoded signoff, Tell #10 vague-proof) overlap with
 Filters 3 and 6. This is intentional — the catalog is the canonical
 enumeration; Filter 8 is the catalog-driven check. Filters 3 and 6
 remain as human-readable explanations of specific high-priority
-tell classes, but the actual detection logic in Phase-84 reads from
+tell classes, but the actual detection logic in offline validation reads from
 `ai-tells.md`.
 
 **Adding new tells.** When UAT surfaces a new AI-tell pattern, add
 it as `Tell #N` in `ai-tells.md` with Pattern / Why / Allowed
-alternative / Severity. The next Phase-84 run picks it up
+alternative / Severity. The next offline validation run picks it up
 automatically. Update
 `tests/scripts/skill-references-substance-filters.test.ts` if the
 new tell needs regression coverage.
 
-**Example of a violation** (Plan 05 Patientdesk winner, pre-catalog —
+**Example of a violation** (Patientdesk regression example, pre-catalog —
 Tell #1 body-level self-introduction):
 
 > "Hey Bonnie — Oncel here. My co-founders and I ran our own dental
@@ -519,7 +521,7 @@ Do not patch a weak message by inventing stronger personalization.
 
 ## Dry-Mode Discipline
 
-Phase 84 dry mode is validation, not production drafting.
+Offline dry mode is validation, not production drafting.
 
 - use only `brief.md`, `lead-filter.md`, and `lead-sample.json`
 - do not fetch new research
@@ -530,19 +532,18 @@ Phase 84 dry mode is validation, not production drafting.
 - retrieve broadly, but preserve one primary example and borrow from at most one
   narrow secondary influence
 
-## Plan 85-03 Critique Addendum
+## Critique Rewrite Addendum
 
 These filters are also the gate on any critique rewrite shipped by the
-Plan 85-03 parallel critique protocol (see
-`references/parallel-critique-protocol.md`). When the critique flag is
-on, a rewritten message must still clear:
+parallel critique protocol (see `references/parallel-critique-protocol.md`).
+When the critique flag is on, a rewritten message must still clear:
 
 - every "Automatic Revisions" check above (jargon, resume-list PS, stacked
   sentences, weak hooks, etc.)
-- the Phase 84 token contract: only supported tokens from the brief, no
+- the offline-validation token contract: only supported tokens from the brief, no
   unresolved `{{token}}`, no invented proof, no personalization that can't
   be traced to `lead-sample.json`
-- the Phase 84 finalizer pass when `synthesis.enforceFinalizerPass` is
+- the offline-validation finalizer pass when `synthesis.enforceFinalizerPass` is
   `true` (default)
 
 If a rewrite fails any of these, the critique pass falls back to the

package/skills/create-campaign-v2/references/step-15-re-cascade.md

@@ -63,7 +63,7 @@ rows graduated.
      })
 
 5. re-check token contract on the cascaded subset (strict mode default)
-   — see references/thomas-revision-filters.md + gold-standard-message-patterns.md
+   — see references/sellable-cleanup-rules.md + gold-standard-message-patterns.md
 
 6. go back to step 1 until selectedCellCount == 0
 ```

package/skills/create-campaign-v2/references/thomas-variant-selection.md

@@ -1,6 +1,6 @@
 # Thomas Variant Selection
 
-This reference governs which rows in a Plan 85-03 critique sample earn
+This reference governs which rows in a critique sample earn
 an Opus refinement rewrite. Load this file only when
 `messaging.critique.enabled === true` AND
 `messaging.critique.opus.enabled === true` in

package/skills/create-campaign-v2/references/validation-criteria.md

@@ -1,8 +1,8 @@
 # Validation Criteria
 
-Phase 84 is a chained-artifact validation pass over the Phase 83 brief. The
-goal is to preserve the brief thesis while proving that leads, filters, and
-message direction hold up against real preview evidence.
+Offline validation is a chained-artifact validation pass over the approved
+campaign brief. The goal is to preserve the brief thesis while proving that
+leads, filters, and message direction hold up against real preview evidence.
 
 ## Primary Contract
 
@@ -10,7 +10,7 @@ message direction hold up against real preview evidence.
 - validation/debug artifacts are optional debug/UAT diagnostics, not durable campaign state.
 - normal customer runs should not expose local draft files.
 - resume and handoff read campaign state before debug files.
-- `CampaignOffer.campaignBrief` is the durable Phase 83 thesis input;
+- `CampaignOffer.campaignBrief` is the durable campaign thesis input;
   `brief.md` is its debug copy
 - `lead-review.md` and `lead-sample.json` are the required outputs of lead preview
 - `lead-filter.md` is the primary output of the middle step
@@ -28,7 +28,7 @@ Allowed:
 
 Not allowed:
 
-- rewrite the Phase 83 thesis in `brief.md`
+- rewrite the approved campaign thesis in `brief.md`
 - create `lead-filter.md`
 - create `message-validation.md`
 - mutate campaign state
@@ -87,13 +87,12 @@ Required:
   the brief justifies absence with reference to a specific archived winner.
   If a candidate uses `two options:`, option `a)` and option `b)` must be
   separated by a blank line so the CTA scans cleanly on mobile.
-- **All 5 Substance Filters from `thomas-revision-filters.md` MUST
-  PASS per candidate.** A candidate that fails any substance filter
-  (Earned-right, Presumption, Vague-proof, Read-as-1:1, Founder-origin
-  coherence) is BLOCKED. The Finalizer Pass CANNOT select a blocked
-  candidate. If all 3 candidates fail, route to `revise-message` with
-  the failure reasons enumerated per candidate (cite the filter name and
-  the offending line).
+- **All Sellable cleanup rules, including all 8 substance filters from
+  `sellable-cleanup-rules.md`, MUST PASS per candidate.** A candidate that fails
+  any cleanup rule or substance filter is BLOCKED. The Finalizer Pass CANNOT
+  select a blocked candidate. If all 3 candidates fail, route to
+  `revise-message` with the failure reasons enumerated per candidate (cite the
+  rule/filter name and the offending line).
 
 ## Lead Preview Expectations
 
@@ -254,7 +253,7 @@ The sample set must:
 - contain no invented proof, metrics, logos, or customer names
 - keep proof claims inside the brief's safe-claims boundary
 - reject personalization that cannot be traced back to `lead-sample.json`
-- apply Thomas revision filters before the step is marked `confirmed`
+- apply Sellable cleanup rules before the step is marked `confirmed`
 - choose the highest-specificity validated strategy available in this order:
   event-led, signal-led, job-post-led, then proof-led specialist fallback
 - retrieve against the full archived gold-standard library and choose a
@@ -328,6 +327,10 @@ that does Y` anchor sentence before any action breakdown, then one action
   with no anchor. Use "I" voice if the sender is the founder; "our CEO",
   "our team", or "we" otherwise. At most two proof beats. No three-credential
   resume lists
+- reject backing PS lines that describe the seller's focus instead of the
+  buyer's outcome, such as `backed by [X] and focused on [category/problem]`.
+  Backing proof only survives when the same line translates to buyer value,
+  e.g. `backed by [X] to help [buyer segment] [buyer outcome]`
 - samples in one set must read like siblings from one campaign, not three
   experiments
 - reject fallback drafts that lead with generic "most teams..." copy without a

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

@@ -379,7 +379,7 @@ templateRevision: "current" })` until the first current-revision generated
    Generate Message cell, and do not add "one more wait" for a stronger sample.
    Remaining review/process sample rows can continue processing in the background.
 4. Read the first ready generated message back via `get_rows` (full) and
-   sanity-check that sample against the Phase 84 token contract: no unresolved
+   sanity-check that sample against the offline-validation token contract: no unresolved
    `{{tokens}}`, no invented proof, one sentence per line, etc.
 5. If the sample fails the token contract, diagnose brief-vs-list
    (same revision loop as Step 14) and escalate if over
@@ -403,17 +403,17 @@ strings, which is why Step 16 requires Step 15 to be complete.
 
 1. Observe the review-sample messages on the same sample that passed
    validation.
-2. If `messaging.critique.enabled` is true (Plan 85-03), run the
+2. If `messaging.critique.enabled` is true, run the
    bounded critique pass on the sample output per
    `references/parallel-critique-protocol.md`. The pass runs on at
    most `messaging.critique.sampleSize` rows, sends each row through
    three parallel critics (targeting / copy / voice) that return
    structured JSON, and merges the voices in a synthesis step that
-   enforces the Phase 84 token contract verbatim and re-runs the
+   enforces the offline-validation token contract verbatim and re-runs the
    finalizer pass. Any rewrite that invents proof or uses an
    unsupported token falls back to the plain generated message. A
    trip of `messaging.critique.budgetUsdCap` HALTS critique for the
-   remaining sample and continues the plain tail. Plan 85-02 reads
+   remaining sample and continues the plain tail. The plain campaign tail reads
    the flag but never flips it; critique stays off until the flag is
    deliberately enabled.
 3. If `messaging.critique.opus.enabled` is also true, route the
@@ -512,7 +512,7 @@ calling any mutating tool; if the campaign is already running, skip
 approve-batch / start_campaign / update_campaign and just confirm.
 
 Workspace/sender mismatch at greenlight time aborts the start with the
-same invariant Phase 84 enforces.
+same invariant offline validation enforces.
 
 ## Threshold Trips and Logging
 
@@ -546,7 +546,7 @@ runs.
 
 | File                                             | Load when                                                                 |
 | ------------------------------------------------ | ------------------------------------------------------------------------- |
-| `references/approval-gate-framing.md`            | Phase 85 commit gate, before showing the approval packet                  |
+| `references/approval-gate-framing.md`            | Approval gate, before showing the approval packet                         |
 | `references/watch-link-handoff.md`               | First brief handoff + explicit link recovery only                         |
 | `references/post-mint-source-materialization.md` | Step 13, before importing normal-discovery or legacy campaignless sources |
 | `references/sample-validation-loop.md`           | Step 14, before enriching + scoring the sample                            |
@@ -554,7 +554,7 @@ runs.
 | `references/final-handoff-contract.md`           | Step 16, and every Claude greenlight turn                                 |
 | `references/parallel-critique-protocol.md`       | Step 15 when `messaging.critique.enabled` is true                         |
 | `references/thomas-variant-selection.md`         | Step 15 when `messaging.critique.opus.enabled` is true                    |
-| `references/thomas-revision-filters.md`          | Any critique rewrite, before persisting                                   |
+| `references/sellable-cleanup-rules.md`          | Any critique rewrite, before persisting                                   |
 | `core/auto-execute.yaml`                         | Start of Step 13, load once; all tail steps read parsed values            |
 | `core/auto-execute.README.md`                    | When tuning `auto-execute.yaml` knobs or reviewing threshold-trip logs    |
 

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

@@ -1,14 +1,14 @@
 ---
 name: create-campaign-v2-validation
-description: Validate a Phase 83 `brief.md` through chained Phase 84 artifacts before any live campaign state exists.
+description: Validate an approved `brief.md` through chained offline artifacts before any live campaign state exists.
 visibility: internal
 ---
 
 # Create Campaign v2 Validation
 
 <role>
-You are the Phase 84 validation orchestrator for create-campaign-v2. Your job
-is to validate a Phase 83 `brief.md` through chained draft artifacts without
+You are the offline validation orchestrator for create-campaign-v2. Your job
+is to validate an approved `brief.md` through chained draft artifacts without
 creating live campaign state.
 </role>
 
@@ -41,7 +41,7 @@ Validated draft directory:
 
 <rules>
 
-- `brief.md` is the stable Phase 83 input and remains the thesis source.
+- `brief.md` is the stable approved input and remains the thesis source.
 - `lead-review.md` and `lead-sample.json` are the required outputs of `find leads`.
 - `lead-filter.md` is the primary output of `filter leads`.
 - `rubric.json` is optional and secondary to `lead-filter.md`.
@@ -49,7 +49,7 @@ Validated draft directory:
 - Run validation serially in this order: `find leads`, `filter leads`, `generate message`.
 - Resume state is based on the presence and completeness of the chained artifacts,
   not on inline validation blocks inside `brief.md`.
-- Preserve the Phase 83 thesis. Do not rewrite product, ICP, offer, or message
+- Preserve the approved thesis. Do not rewrite product, ICP, offer, or message
   hypothesis sections during preview validation.
 - Every artifact write uses `tmp + rename` so a failed write leaves the prior
   artifact intact.
@@ -222,7 +222,7 @@ Orchestration requirements:
   same company as the brief
 - draft 3 internal candidates and run a Finalizer Pass that combines the
   best opener, proof sentence, bridge, and CTA across them into one winner
-- pass the Thomas revision filters before writing findings
+- pass the Sellable cleanup rules before writing findings
 - pass the source-transition gate before writing findings. For sender-owned
   LinkedIn post sources where the sample proves a reaction/comment, a light
   first-person acknowledgment is allowed (`appreciate you showing some love on
@@ -230,8 +230,17 @@ Orchestration requirements:
   before broad problem or product copy (`figured this might be relevant if
   LinkedIn is becoming more of a GTM channel for [company/team]`). Block drafts
   that jump straight from the acknowledgment into generic `a lot of teams...` or
-  `most teams...` pain. For third-party post sources, keep source references
-  topic-level and low-certainty.
+  `most teams...` pain. For sender-owned sources, third-party thread framing is
+  blocked unless the source is truly third-party: reject `found you in a thread`,
+  `saw you in a thread`, `saw you in conversations`, or `saw you in a few
+  conversations`. The message must either use the first-person acknowledgment
+  plus bridge or omit the source line. Use the first-person acknowledgment plus
+  bridge only when the final sender and source owner are proven to match. If
+  multiple senders may send the campaign, or the final sender/source-owner match
+  is ambiguous, do not assume `my post` or name a specific sender; omit the
+  sender-owned source line until row-level sender ownership is proven. Neutral
+  low-certainty source language is only for truly third-party post sources; keep
+  those source references topic-level and low-certainty.
 - pass the line-continuity gate before writing findings. Each message line must
   make the next line feel earned: source/post signal -> relevance bridge ->
   product/problem -> next step. If two adjacent lines could be swapped, deleted,