@sellable/mcp 0.1.75 → 0.1.77

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.75",
+  "version": "0.1.77",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

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

@@ -922,6 +922,13 @@ Required behavior:
 - preserve recurring keep/exclude filter families that show up across campaign
   history: buyer role, wrong-function exclusions, company-type exclusions,
   competitor/vendor exclusions, geography, company size, and active-role status
+- treat right role/function, right seniority/authority, account/channel fit,
+  economic capacity, competitor/vendor exclusion, and active current-role status
+  as table-stakes buyer-quality gates; include geography/market whenever budget,
+  channel adoption, language, compliance, or delivery assumptions depend on it
+- do not turn "shown interest", post engagement, Signals source, recent posting,
+  provider source, or first-send priority into a production filter; those are
+  discovery or messaging context, not proof the lead is qualified
 - use the actual lead sample to identify repeated false positives
 - prefer required keep/exclude rules over a broad scoring stack
 - allow at most one optional/supporting rule when it materially helps later

package/skills/create-campaign-v2/references/filter-leads.md

@@ -10,6 +10,14 @@ to buying." A lead who may reply but cannot buy, lacks budget, sits at the wrong
 account type, is a vendor/competitor, or is on the wrong side of a marketplace
 is not a good lead.
 
+Source interest is not qualification. A lead who engaged with a post, appeared
+in a Signals search, recently posted on LinkedIn, or "showed interest" in the
+topic has only supplied discovery context. That context can justify the source
+lane, improve pass-rate confidence, or help message generation; it must not
+become a production filter or `leadScoringRubric` item. If the source lane was
+built from topical engagement, the filter should still ask: is this the right
+role, seniority, account type, budget band, market, and non-competitor?
+
 Inputs:
 
 - `brief.md`
@@ -61,6 +69,36 @@ Use the actual sample to answer:
 - whether the filtered leads are economically worth sending to, using the best
   campaign-native proxy available from row data, enrichment, or Googleable facts
 
+## Table-Stakes Qualification Gates
+
+Confirmed production filters should fail closed on buyer quality. The default
+confirmed filter set must explicitly include each table-stakes gate below, or
+`lead-filter.md` must state why a gate is irrelevant for this campaign:
+
+- right role / function: the person owns or directly influences the buyer
+  problem; wrong-function leads fail even when they match the source topic
+- right seniority / authority: the person can approve, pilot, champion, or
+  materially influence adoption; junior ICs fail unless the brief explicitly
+  targets them
+- account and channel fit: the company is the right account type and its buyers
+  are reachable through the chosen channel, such as LinkedIn for LinkedIn
+  outbound campaigns
+- economic capacity / ability to buy: the company has an appropriate budget
+  proxy for the offer, such as headcount, revenue, funding, team size, practice
+  size, location count, department maturity, or existing tooling
+- competitor / vendor / wrong-side exclusion: competitors, adjacent vendors,
+  agencies/service providers, resellers, and marketplace-side conflicts fail
+  unless the brief explicitly targets that group
+- geography / market fit: include the campaign's market, language, region, or
+  tier-country constraint when budget, channel adoption, compliance, or delivery
+  assumptions depend on it
+- active current-role safety: score the person's current role and company, not
+  stale prior roles, advisor blurbs, investor bios, or old engagement context
+
+Do not replace these gates with a "shown interest" or "engaged with relevant
+content" rule. Interest can help find a warmer list, but it does not prove the
+lead is a buyer.
+
 ## Standard Competitor / Vendor Exclusion
 
 Every confirmed filter should include a competitor / vendor / wrong-side
@@ -195,17 +233,21 @@ Rules:
 - do not put source-path mechanics or send-priority hints into
   `leadScoringRubrics`. Examples: recently posted on LinkedIn, came from a
   Signals search, appeared in Sales Nav, was found by Prospeo, first-send wave,
-  or priority cohort. If that signal was already used in the search, mention it
-  in `Pass Rate` or `Recommendation`; if it is useful but not required, keep it
-  as prose under `Optional Supporting Rule`, not as a production rubric.
+  priority cohort, engaged with selected posts, showed interest in the topic,
+  or matched a signal-discovery keyword. If that signal was already used in the
+  search, mention it in `Pass Rate` or `Recommendation`; if it helps messaging,
+  pass it to message generation as source context, not as a production rubric or
+  supporting fit rule.
 - do not put DNC or one-off relationship-safety notes into
   `leadScoringRubrics` unless the sample shows that family is likely to leak at
   meaningful volume and normal DNC/domain suppression will not catch it. Former
   employers, existing customers, investors, partner lists, and "do not contact"
   domains usually belong in `Recommendation` or a DNC note, not in ICP scoring.
 - confirmed `leadScoringRubrics` must protect sales quality, not just surface
-  similarity. They should usually cover:
-  - buyer authority / role fit
+  similarity. They must cover the table-stakes qualification gates unless
+  `lead-filter.md` explicitly justifies why a gate is irrelevant:
+  - right role / function fit
+  - buyer seniority / authority
   - account or company-type fit
   - economic capacity / ability to buy, using a campaign-native proxy such as
     headcount, revenue, funding, practice size, location count, patient volume,
@@ -311,7 +353,7 @@ Recommended rubric grouping:
 - economic capacity / ability to buy
 - geography / size / stage fit, when relevant
 - competitor / vendor / wrong-side / repeated false-positive exclusion
-- one optional buyer-quality signal, at most, only when it changes fit scoring
+- one optional buyer-quality qualifier, at most, only when it changes fit scoring
   rather than send ordering
 
 Rubric-readiness checklist:

package/skills/generate-messages/SKILL.md

@@ -92,6 +92,8 @@ Required dry-mode contract:
 - use `lead-filter.md` once available to decide which find-leads sample rows
   remain valid for the final winner and which false-positive patterns must be
   avoided
+- use `lead-filter.md` only to decide which find-leads sample rows remain valid;
+  never use it to create replacement sample rows
 - do not mark `message-validation.md` as final or ready for message review until
   `lead-filter.md` exists and the selected winner cites only rows that still
   pass the filter
@@ -114,6 +116,8 @@ Read:
 - `lead-filter.md` when present. If it is absent because the caller launched
   post-lead workstreams in parallel, start the prep/candidate stages and then
   reconcile before final `message-validation.md`.
+- `mcp/sellable/skills/create-campaign/references/ai-native-tokens.md`
+- `mcp/sellable/skills/create-campaign/references/token-fill-examples.md`
 - `mcp/sellable/skills/create-campaign-brief/references/phase75-active-runtime-message-pack.md`
 - `mcp/sellable/skills/create-campaign-v2/references/validation-criteria.md`
 - `mcp/sellable/skills/create-campaign-v2/references/thomas-revision-filters.md`
@@ -121,6 +125,30 @@ Read:
 - `mcp/sellable/skills/create-campaign-v2/references/gold-standard-message-examples.md`
 - `mcp/sellable/skills/create-campaign-v2/references/gold-standard-message-validation-example.md`
 
+### Rich Personalization Contract
+
+`mcp/sellable/skills/create-campaign/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.
+
+- Sentence-level personalization must use AI-native bracket tokens in the
+  reusable template / token plan, not old-school field substitution. Field
+  tokens such as `{{first_name}}` and `{{company}}` are fine for atomic slots.
+  Do not collapse rich personalization into `{{workflow_context}}`,
+  `{{company}}`, or another noun-shaped token when the line needs judgment.
+- Use this shape for any hook, bridge, or row-specific relevance line:
+  `[PERSONALIZATION_LINE — Intent: write one short sentence that anchors the
+note to the prospect's buyer-relevant activity. DO: name what they do, write
+about, focus on, or build toward. DON'T: name a product their company sells,
+use source-citation phrasing, or use generic nouns like "your work".
+FALLBACK: if unsupported, omit the entire line.]`
+- The bracketed token belongs in the reusable template / token plan only. The
+  rendered `Selected Winner` and sample messages must contain the composed
+  sentence or no line at all; never show the bracket to the buyer.
+- If the campaign truly only needs an atomic field value, document it as a
+  field token. If the value is a sentence, phrase, buyer-activity judgment, or
+  synthesis of multiple row fields, author it as AI-native.
+
 Dry-mode output must follow this flow: **element pool → gold-standard
 strategy map → current-campaign translation → element scoring → agent
 dialogue cross-review → angle drafts → kill/combine review → finalists →
@@ -535,18 +563,24 @@ The winner entry must:
   token plan instead.
 - never use generic signal tokens like `{{recentSignal}}`,
   `{{recent_signal}}`, or `{{recent_signal_quote}}`. If row personalization
-  is needed, use concrete enriched-row fields such as `{{post_context}}`,
-  `{{comment_summary}}`, `{{profile_summary}}`, `{{source_post_topic}}`,
-  `{{headline}}`, or `{{row_proof_note}}`, and make the line work without
-  source-citation phrases like `caught my eye`.
+  is needed in the raw selected winner, render the concrete sentence from
+  enriched-row fields such as `{{post_context}}`, `{{comment_summary}}`,
+  `{{profile_summary}}`, `{{source_post_topic}}`, `{{headline}}`, or
+  `{{row_proof_note}}`, and make the line work without source-citation phrases
+  like `caught my eye`. For the reusable template / token plan behind that
+  rendered line, prefer an AI-native bracket token with inline Intent / DO /
+  DON'T / FALLBACK rules; only use a row-derived `{{field_token}}` when the
+  inserted value is truly atomic.
 - never use `{{profile_signal}}` in selected copy, message-review templates,
   or rendered examples. It is an internal analysis bucket, not a sendable row
   token. Lines like `{{profile_signal}} is why I thought this might be
 relevant for {{company}}` are BLOCKED because they expose enrichment logic
   and read as AI-generated mail merge. If the underlying signal is strong,
-  convert it into a named row-derived context token such as
-  `{{workflow_context}}`, `{{source_post_topic}}`, or `{{row_proof_note}}`;
-  if it is weak, omit the personalization line.
+  render it into a buyer-readable sentence in the selected copy and document
+  the reusable template as an AI-native token. Use named row-derived context
+  tokens such as `{{workflow_context}}`, `{{source_post_topic}}`, or
+  `{{row_proof_note}}` only when the value is an atomic phrase that drops into
+  the sentence without judgment; if it is weak, omit the personalization line.
 
 Finalizer preference when multiple candidates are otherwise comparable:
 
@@ -1156,8 +1190,11 @@ yours` are not enough when a safe row token would make the line feel more
 {{reporting_context}} sits in the kind of reporting ownership...`, `your
 {{role_context}} work`, or `noticed your {{topic}}` are BLOCKED when the filled
   version sounds like mail merge. A good token should either make the sentence
-  more concrete in normal language or be omitted. If the row signal is weak,
-  write the segment-level line and document the omit rule.
+  more concrete in normal language or be omitted. If the context needs the
+  model to decide what the sentence should say, use an AI-native bracket token
+  in the reusable template / token plan instead of a noun-shaped
+  `{{workflow_context}}`-style slot. If the row signal is weak, write the
+  segment-level line and document the omit rule.
 - **No product-noun substitution in possessive frames (HARD INVARIANT):** when
   a token sits inside a possessive frame like `your {{X}}`, `at your {{X}}`,
   or `because of your {{X}}`, the filled value MUST describe something the
@@ -1193,9 +1230,12 @@ Engineering writing` (ALLOWED — what they do publicly). The omit-fallback
   gold pack: \`[PERSONALIZED REASON — their team size, role, or why
   they're a perfect fit]\` — the model picks whichever input the row supports
   and writes one short sentence in the sender's voice. Full spec:
-  \`references/ai-native-tokens.md\`. The \`[ALL_CAPS_NAME — ...]\` shape
-  is reserved for AI-native tokens; field substitutions stay as
-  \`{{snake_case}}\` and continue to work as direct value injections.
+  \`mcp/sellable/skills/create-campaign/references/ai-native-tokens.md\`. The
+  \`[ALL_CAPS_NAME — ...]\` shape is reserved for AI-native tokens; field
+  substitutions stay as \`{{snake_case}}\` and continue to work as direct
+  value injections. Do not collapse rich personalization into
+  \`{{workflow_context}}\`, \`{{company}}\`, or another field token just because
+  those are easier to list in Token Fill Rules.
 - **No internal profile-signal token:** `{{profile_signal}}` is never allowed
   in customer-facing copy, message-review templates, rendered examples, token
   notes, or approval-packet message bodies. It names how enrichment classified
@@ -1950,8 +1990,8 @@ shipping this template".
 
 ## Token Fill Rules
 
-| Token | Source Field | Allowed Transformation | Fallback | Result |
-| ----- | ------------ | ---------------------- | -------- | ------ |
+| Token | Type | Source Field / Instructions | Allowed Transformation | Fallback | Result |
+| ----- | ---- | --------------------------- | ---------------------- | -------- | ------ |
 
 If `{{company}}` or another account-context token is available, document
 whether it was tested as a believability personalization, not only whether it
@@ -1959,9 +1999,12 @@ was technically available. Use it when it grounds a generic phrase without
 creating employer-blame, employer-permission, legal, or scrape-y risk. If it is
 omitted, state the specific reason it would not improve believability.
 Do not define or use `{{profile_signal}}`. Treat it as an internal enrichment
-classification only. When a profile-derived signal is genuinely useful, define
-a buyer-readable derived token such as `{{workflow_context}}` or
-`{{role_specialization}}` and show both its clean fill rule and omit fallback.
+classification only. When a profile-derived signal is genuinely useful, prefer
+an AI-native token for the full personalization sentence and show the inline
+Intent / DO / DON'T / FALLBACK contract in the table or immediately below it.
+Only define a buyer-readable derived token such as `{{workflow_context}}` or
+`{{role_specialization}}` when it is a clean atomic phrase, and show both its
+fill rule and omit fallback.
 When raw `{{company}}` is awkward but employer grounding still helps, define
 `{{employer_context}}` as a row-derived token: fill with the clean company name
 when natural, otherwise `your group`, `your bank`, `your team`, or the closest
@@ -1977,9 +2020,13 @@ hiring for`
 - `{{role_specialization}}` = buyer-native specialization from title/headline;
   fallback broad role only when specialization is absent
 - `{{workflow_context}}` = concrete public workflow clue; fallback omitted, not
-  generic filler
+  generic filler; use only for atomic phrases, not sentence-level
+  personalization that needs judgment
 - `{{account_segment}}` = row-derived account category when it improves fit;
   fallback brief-level segment only when every row shares it
+- `[PERSONALIZATION_LINE — Intent: ... DO: ... DON'T: ... FALLBACK: omit]` =
+  AI-native sentence token; source from the lead sample fields that support the
+  DO rules; fallback omit the whole line, never generic filler
 
 ## Token Adherence Table