@sellable/mcp 0.1.75 → 0.1.76

package/package.json

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

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