@sellable/mcp 0.1.31 → 0.1.33

package/dist/tools/prompts.js

@@ -97,8 +97,8 @@ export const promptToolDefinitions = [
             properties: {
                 depth: {
                     type: "string",
-                    enum: ["minimal-verification", "deep-proof"],
-                    description: "Research depth used: minimal verification or deeper proof-focused pass.",
+                    enum: ["minimal-verification", "deep-proof", "parallel-batch"],
+                    description: "Research depth used: minimal-verification (proofDigest already had strong signals), deep-proof (extra search agents spawned), or parallel-batch (Phase 114+ default — single 5-call parallel batch with fetch_linkedin_profile + fetch_company + 3x WebSearch).",
                 },
                 proofItemsFound: {
                     type: "number",

package/dist/tools/readiness.d.ts

@@ -20,6 +20,7 @@ export declare function resolveWaitTimeout(timeoutMs?: number): {
     effectiveTimeoutMs: number;
     guardApplied: boolean;
 };
+export declare function hasNonWaitableMissing(missing: string[]): boolean;
 export declare const readinessToolDefinitions: ({
     name: string;
     description: string;

package/dist/tools/readiness.js

@@ -32,9 +32,11 @@ export function resolveWaitTimeout(timeoutMs) {
         guardApplied: requestedTimeoutMs > effectiveTimeoutMs,
     };
 }
-function hasNonWaitableMissing(missing) {
+export function hasNonWaitableMissing(missing) {
+    // Phase 114: clientProspectId is no longer non-waitable. Net-new campaigns
+    // can be created with senderLinkedinUrl instead, with downstream resolution
+    // happening at send-time.
     const nonWaitable = new Set([
-        "clientProspectId",
         "campaignBrief.content",
         "leadSourceType",
         'leadSourceType="new"',

package/dist/tools/sequencer.d.ts

@@ -2,6 +2,7 @@ export type CreateWorkflowTableInput = {
     name: string;
     senderId: string;
     clientProspectId?: string;
+    senderLinkedinUrl?: string;
     sequenceActions?: string[];
 };
 export type CreateWorkflowTableResponse = {
@@ -58,6 +59,10 @@ export declare const sequencerToolDefinitions: ({
                 type: string;
                 description: string;
             };
+            senderLinkedinUrl: {
+                type: string;
+                description: string;
+            };
             sequenceActions: {
                 type: string;
                 items: {
@@ -93,6 +98,7 @@ export declare const sequencerToolDefinitions: ({
             name?: undefined;
             senderId?: undefined;
             clientProspectId?: undefined;
+            senderLinkedinUrl?: undefined;
             sequenceActions?: undefined;
             campaignId?: undefined;
         };
@@ -115,6 +121,7 @@ export declare const sequencerToolDefinitions: ({
             name?: undefined;
             senderId?: undefined;
             clientProspectId?: undefined;
+            senderLinkedinUrl?: undefined;
             sequenceActions?: undefined;
             tableId?: undefined;
             template?: undefined;

package/dist/tools/sequencer.js

@@ -7,7 +7,8 @@ export const sequencerToolDefinitions = [
             "All tables include LinkedIn URL, Name, and Approved. " +
             "Additional columns depend on the planned actions: INVITE/DM -> Message, " +
             "INMAIL_* -> Subject + Message, COMMENT -> Post URL + Comment + Reaction Type. " +
-            "Campaign brief, rubrics, positioning, and prospect linkage remain optional follow-on metadata.",
+            "Campaign brief, rubrics, positioning, and prospect linkage remain optional follow-on metadata.\n\n" +
+            "INPUTS: Pass EITHER clientProspectId OR senderLinkedinUrl. Both optional — if neither is supplied, the table is created without prospect linkage.",
         inputSchema: {
             type: "object",
             properties: {
@@ -21,7 +22,11 @@ export const sequencerToolDefinitions = [
                 },
                 clientProspectId: {
                     type: "string",
-                    description: "Optional client prospect ID (from enrich_sender)",
+                    description: "Optional. EnrichedProspect ID. Pass this OR senderLinkedinUrl.",
+                },
+                senderLinkedinUrl: {
+                    type: "string",
+                    description: "Optional. Sender's LinkedIn profile URL — used to lazy-resolve the prospect at send-time when clientProspectId is not yet available.",
                 },
                 sequenceActions: {
                     type: "array",
@@ -87,6 +92,7 @@ export async function createWorkflowTable(input) {
         name: input.name,
         senderId: input.senderId,
         clientProspectId: input.clientProspectId,
+        senderLinkedinUrl: input.senderLinkedinUrl,
         ...(input.sequenceActions
             ? { sequenceActions: input.sequenceActions }
             : {}),

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -4,6 +4,8 @@ description: Create a Sellable campaign through the approval-gated workflow.
 visibility: public
 allowed-tools:
   - mcp__sellable__get_auth_status
+  - mcp__sellable__start_cli_login
+  - mcp__sellable__wait_for_cli_login
   - mcp__sellable__bootstrap_create_campaign
   - mcp__sellable__get_subskill_prompt
   - mcp__sellable__search_subskill_prompts
@@ -323,14 +325,89 @@ plugin cache paths, MCP namespaces, or runbooks in customer-facing progress
 updates.
 
 1. Call `mcp__sellable__get_auth_status({})`.
-2. If auth is not OK, stop and show the returned guidance.
-3. Detect optional campaign id in the user request (`cmp_...`).
-4. If no campaign id is provided, stay in fresh-create mode and do not call campaign discovery/resume helpers to find one.
+2. If auth is not OK with `error.type === "config"` or `error.type === "auth"`,
+   the user has not signed in yet. Run the FTUX magic-link handoff:
+
+   a. Say to the user verbatim:
+
+   ```text
+   Welcome to Sellable. What's your email?
+   ```
+
+   b. Wait for the user to paste their email in normal chat. Do NOT use
+   `AskUserQuestion` / `request_user_input` for this — it's free-text input.
+
+   c. Call `mcp__sellable__start_cli_login({ email })` with the email the user
+   typed.
+
+   d. If `start_cli_login` returns `ok: false`, surface `error.guidance` to the
+   user and stop. Do not retry automatically.
+
+   e. On `ok: true`, say to the user verbatim (substituting the email exactly
+   as the user typed it):
+
+   ```text
+   Magic link sent to {email}. Click it from your inbox — I'll wait. (If your team already has a Sellable workspace, ask an admin to invite you instead — that gets you straight into their data.)
+   ```
+
+   f. Call `mcp__sellable__wait_for_cli_login({ sessionId })` using the
+   `sessionId` returned by `start_cli_login`.
+
+   - If the result is `error.type === "tool_timeout_guard"`, IMMEDIATELY
+     re-call `mcp__sellable__wait_for_cli_login({ sessionId })` with the
+     SAME sessionId. Do not narrate anything to the user. Do not call
+     `start_cli_login` again — that would send a new magic link and confuse
+     them. Loop on `tool_timeout_guard` until you get a different result.
+
+   - If `error.type === "expired"` or `error.type === "timeout"`, say to the
+     user verbatim and stop:
+
+     ```text
+     That magic link expired. Run /sellable:create-campaign again to retry.
+     ```
+
+   - If `error.type === "already_consumed"` or any other error, surface
+     `error.guidance` and stop.
+
+   - On `ok: true`, the user is signed in and `~/.sellable/config.json` has
+     been written. Your IMMEDIATE next visible message branches on
+     `isReturningUser` from the tool result:
+
+     - If `isReturningUser === true`, prepend ONE line acknowledging the
+       reused workspace, then the locked Step 3 narration verbatim
+       (substituting `activeWorkspaceName` exactly):
+
+       ```text
+       You're in — using your {activeWorkspaceName} workspace.
+
+       Now — paste the LinkedIn profile URL of the person you want to send from.
+       ```
+
+     - If `isReturningUser === false`, prepend ONE line confirming the new
+       workspace, then the locked Step 3 narration verbatim:
+
+       ```text
+       Welcome to Sellable — created {activeWorkspaceName} for you.
+
+       Now — paste the LinkedIn profile URL of the person you want to send from.
+       ```
+
+     No other lines. No "all set", no "signed in", no other acknowledgement.
+
+     After the user pastes the URL, proceed with the existing identity-first
+     sender flow (Step 3 onwards in the v2 subskill prompt — sender
+     enrichment via `fetch_linkedin_profile` / `enrich_sender`).
+
+3. If auth is not OK with `error.type === "workspace"` (token valid, no active
+   workspace), stop and show the returned guidance — that's not a fresh-user
+   scenario; the user needs to run `set_active_workspace`.
+4. Detect optional campaign id in the user request (`cmp_...`).
+5. If no campaign id is provided, stay in fresh-create mode and do not call campaign discovery/resume helpers to find one.
    - Do not call `mcp__sellable__get_campaigns`.
    - Do not call `mcp__sellable__get_campaign` to hunt for IDs.
    - Do not call `mcp__sellable__create_campaign({ campaignId: ... })` unless the user supplied that id.
-5. Call `mcp__sellable__bootstrap_create_campaign({ flowVersion: "v2", campaignId? })`.
-6. If `safeToProceed !== true`, stop and show `blockingErrors` + `nextStep`.
+6. Call `mcp__sellable__bootstrap_create_campaign({ flowVersion: "v2", campaignId? })`.
+7. If `safeToProceed !== true`, stop and show `blockingErrors` + `nextStep`.
 
 ## Execute Workflow
 

package/skills/create-campaign/references/ai-native-tokens.md

@@ -0,0 +1,266 @@
+# AI-Native Tokens
+
+The canonical spec for personalization tokens in Sellable campaign messages.
+
+## Why this exists
+
+Old-school personalization tokens (`{{first_name}}`, `{{company}}`,
+`{{workflow_context}}`) are field substitutions: a string is looked up and
+spliced into a fixed sentence. That works for atomic facts (first name,
+company name). It fails for anything richer — because the _grammatical shape_
+of the surrounding sentence locks in what the substituted value must look
+like, and the rules about what makes a good substitution live in a separate
+"Token Fill Rules" table that the generation model can easily ignore or
+forget.
+
+Concrete failure mode this caused in production: the template
+`Thought of {{company}} because of your {{workflow_context}}.` was filled
+with `Moneyball dashboard for CEOs` for a prospect who _built_ that product
+at his company. The rendered line —
+`Thought of Hatchproof because of your Moneyball dashboard for CEOs.` —
+read as if we mistook the founder for a customer of his own product.
+Field-substitution tokens have no built-in defense against that.
+
+**AI-native tokens fix this.** The token _names what job the line does_ and
+carries its rules _inline_. The model writes a SENTENCE (not fills a slot)
+that satisfies the inline contract, or omits the line entirely. The grammar
+trap disappears because the model is composing the line from scratch instead
+of plugging a noun into a fixed frame.
+
+## The contract
+
+An AI-native token is a bracketed instruction in the message template:
+
+```text
+[ALL_CAPS_NAME — instructions describing what the line should do, with
+DO / DON'T rules and a FALLBACK clause]
+```
+
+Three properties define it:
+
+1. **Named by intent, not by field.** `[PERSONALIZATION_LINE — ...]` says
+   what JOB the line does. `{{workflow_context}}` only names a slot. When
+   the model sees an intent name, it has a target to write toward.
+2. **Rules live inline.** DO / DON'T / FALLBACK appear inside the bracket,
+   adjacent to where the line gets written. The model doesn't have to
+   consult a faraway rules table and remember to apply it.
+3. **Sentence-shaped, not noun-shaped.** The model produces an entire
+   sentence (or no sentence). There is no fixed frame around the token, so
+   no grammar trap. A weak fill is still a complete sentence; a wrong fill
+   is detectable at the sentence level.
+
+The bracket is replaced at generation time by either (a) the rendered
+sentence, or (b) nothing (omit). The brackets themselves never appear in
+the final message.
+
+## Required clauses inside an AI-native token
+
+Every well-specified AI-native token must include four things:
+
+- **Intent.** One sentence on what job this line does in the message. Why
+  the line exists. What it should accomplish for the buyer.
+- **DO.** 2-4 specific shapes the model should produce. Verb-led
+  prescriptions. Examples that work.
+- **DON'T.** 2-4 anti-patterns the model must reject. Failure modes
+  observed in real campaigns. Bad shapes paired with WHY they're bad
+  when the bad-ness isn't obvious from the shape alone.
+- **FALLBACK.** What to do when none of the DO shapes can be satisfied
+  cleanly from the row data. The default fallback is OMIT THE ENTIRE LINE.
+  Aggressive omit beats awkward fill, every time. Never silently
+  substitute a generic noun.
+
+A token without all four clauses is under-specified. The model will
+hallucinate the missing rules from priors, and those priors include
+generic mail-merge failure modes.
+
+## The canonical example
+
+This is the original Sellable gold-standard message. It uses two AI-native
+tokens. Both have the contract baked in (loosely — even an under-specified
+intent-name dramatically beats a field token, but the formal contract makes
+it bulletproof):
+
+```text
+hey [name],
+
+saw you raise your hand for claude + gtm (creepy to reach out based on
+that, i know) - but this felt too on the nose to ignore.
+
+i'm building sellable, the only gtm platform that runs natively on claude
+code.
+
+we're looking for design partners - and [PERSONALIZED REASON - their team
+size, role, or why they're a perfect fit].
+
+two options:
+
+a) 15-min call - i'll show you how you could book more meetings with
+[THEIR ICP - who they want to reach], and if you like it we launch a pilot
+right there
+
+b) i send you the video of me using sellable to write and send this exact
+message to you (yes, it's that meta)
+
+p.s. yes, this message was entirely written and sent via claude code 😊
+```
+
+Note what the tokens DO:
+
+- `[PERSONALIZED REASON - their team size, role, or why they're a perfect fit]`
+  — the brackets name an intent (PERSONALIZED REASON) and offer three
+  acceptable input sources (team size, role, fit reason). The model picks
+  whichever is supported by the row.
+- `[THEIR ICP - who they want to reach]` — names what the slot is FOR
+  ("their ICP") and clarifies in plain English ("who they want to reach"),
+  so the model doesn't need a glossary.
+
+Both feel hand-crafted in every rendered version because the model is
+_writing_, not _filling_.
+
+## The fully-specified contract (use this for new campaigns)
+
+When authoring a new brief, write tokens in the full contract form. The
+canonical Sellable example is loose because it predates the contract; it
+still works because the intent names are crystal clear, but new tokens
+should err toward explicit:
+
+```text
+[PERSONALIZATION_LINE — write ONE short sentence (8-15 words) that anchors
+this message to {{first_name}} as a person. Name what they personally DO,
+write about, focus on, or build TOWARD (not what their company SELLS).
+DO: use verb-led shapes — "Saw your work helping X", "Your writing on Y
+caught my eye", "Your focus on Z is rare in this segment".
+DON'T: name a product their company sells ("your dashboard for X", "your
+platform for Y") — they BUILD the product, they don't have one.
+DON'T: use source-citation phrasing ("Saw your post about", "Your bio
+says").
+DON'T: use generic noun substitutes ("your work", "your stack", "your
+team") — those add no relevance.
+FALLBACK: if you can't satisfy the DOs cleanly from the row data, OMIT
+this entire line. The message reads cleanly without it. Aggressive omit >
+awkward fill.]
+```
+
+That bracket is ~15 lines. It produces ONE sentence in the rendered
+message (or zero). The verbosity inside the bracket is the price of
+predictable output across thousands of rows.
+
+## The grammar test
+
+Every personalization line should pass this test before rendering: read
+`your <X>` (or whatever possessive frame the line uses) out loud. If "X"
+reads as if the recipient _uses_ or _has_ the thing, but the recipient
+actually _builds_ or _sells_ the thing, the fill is wrong → OMIT.
+
+Examples:
+
+| Filled value                              | Pass test?                           |
+| ----------------------------------------- | ------------------------------------ |
+| `your monetization work for AI founders`  | ✅ recipient does this work          |
+| `your founder voice on team performance`  | ✅ recipient has this voice          |
+| `your Moneyball dashboard for CEOs`       | ❌ recipient _builds_ this dashboard |
+| `your monetization layer for AI builders` | ❌ recipient _sells_ this product    |
+| `your AI scoring engine`                  | ❌ product they sell                 |
+| `your work`                               | ❌ generic, adds no relevance        |
+| `your team`                               | ❌ generic, adds no relevance        |
+
+When in doubt, omit. The message must read cleanly without the
+personalization line. If it doesn't, the rest of the message is
+under-specified — fix that, don't paper over it with weak personalization.
+
+## Field-substitution tokens still have a role
+
+AI-native tokens replace personalization sentences. They do NOT replace
+atomic field substitutions like `{{first_name}}` and `{{company}}`. Use
+field tokens when:
+
+- The value is an atomic noun that goes in a fixed slot (greeting:
+  `Hey {{first_name}},`, subject: `{{company}} outbound + ...`)
+- The value comes directly from a row column with no judgment required
+- Failure mode is "missing field" not "wrong shape" — and the fallback is
+  trivial (`there` instead of first name, omit the soft-bridge instead of
+  company)
+
+Use AI-native tokens when:
+
+- The value is a SENTENCE that requires judgment about what to write
+- The value depends on synthesizing multiple row fields (bio + recent
+  posts + company context) into a human-sounding line
+- Failure mode is "wrong shape" or "awkward grammar" — needs rules to
+  prevent
+- The line is optional (you'd rather have NO line than a bad line)
+
+Most campaigns will use both: field tokens for greeting/subject/company,
+AI-native tokens for any personalization or context-bridging lines.
+
+## Brief authoring guide
+
+When writing a campaign brief, document each token in two places:
+
+### 1. In the message template itself
+
+Inline AI-native tokens go directly in the template body:
+
+```text
+Hey {{first_name}},
+
+[FIRST_LINE — opener that anchors to {{company}}'s current situation.
+DO: ... DON'T: ... FALLBACK: ...]
+
+[BODY — ... ]
+```
+
+### 2. In the Token Fill Rules section
+
+A small table cataloging every token, marked by type:
+
+```markdown
+| Token                          | Type      | Source / Instructions                         | Fallback                |
+| ------------------------------ | --------- | --------------------------------------------- | ----------------------- |
+| `{{first_name}}`               | Field     | Sales Nav `firstName`                         | `there`                 |
+| `{{company}}`                  | Field     | Sales Nav `organization.name`; strip suffixes | omit dependent sentence |
+| `[PERSONALIZATION_LINE — ...]` | AI-native | Inline. See bracket.                          | Omit the line.          |
+```
+
+The AI-native row in the table doesn't need to repeat the instructions —
+they live inline. The table just confirms the token exists, what type it
+is, and where the fallback resolves.
+
+## Common authoring mistakes
+
+- **Naming the token by source field instead of intent.**
+  `[LINKEDIN_BIO_PHRASE — ...]` is bad. `[PERSONALIZATION_LINE — ...]` is
+  good. The intent name tells the model what job to do; the source field
+  tells the model where to look but not what good looks like.
+- **Rules in a separate table, intent in the template.** Keep them
+  together. The model's attention budget is finite — separating intent
+  from rules invites the model to forget the rules.
+- **No FALLBACK clause.** Without it, the model assumes a fill is always
+  required and substitutes a generic noun ("your work") rather than
+  omitting. Always include FALLBACK.
+- **Vague DO list.** `DO: be specific and human` is not a DO. Spell out
+  the verb-led shapes: `DO: use "your work helping X", "your writing on
+Y", "Saw you're pushing into Z"`. The model needs prescriptions, not
+  vibes.
+- **DON'T list that only describes obvious failures.** The DON'T clause
+  is most valuable when it names the non-obvious failures: product-noun
+  substitution, source-citation phrasing, mind-reading from signals,
+  generic noun substitutes.
+- **Bracket containing freeform prose.** Keep the bracket's clauses
+  labeled (DO / DON'T / FALLBACK). Prose paragraphs are harder for the
+  model to scan and easier to ignore.
+
+## Cross-references
+
+- `mcp/sellable/skills/generate-messages/SKILL.md` — the skill that
+  invokes this token system at message-generation time. Carries the
+  hard-invariant rules (no product-noun substitution, omit-fallback as
+  default, etc.).
+- `mcp/sellable/skills/create-campaign/references/token-fill-examples.md`
+  — example archive showing good/bad fills across many shapes.
+- `mcp/sellable/skills/create-campaign-brief/references/brief-template.md`
+  — the brief template that authors should populate with AI-native tokens
+  by default.
+- `mcp/sellable/skills/create-campaign-brief/references/phase75-active-runtime-message-pack.md`
+  — the runtime gold examples, including the original Sellable message
+  with `[PERSONALIZED REASON — ...]` and `[THEIR ICP — ...]`.

package/skills/create-campaign/references/token-fill-examples.md

@@ -2,6 +2,16 @@
 
 Use this file when template-style personalization is in play.
 
+> **Read `ai-native-tokens.md` first.** The Sellable canonical token style is
+> AI-native: bracketed `[ALL_CAPS_NAME — instructions]` placeholders that
+> name what JOB the line does and carry DO / DON'T / FALLBACK rules inline.
+> The model writes a sentence (or omits) per the inline contract — it does
+> NOT fill a fixed slot. That spec is the source of truth; this file shows
+> good/bad examples across shapes. Old-style `{{field}}` substitutions still
+> apply for atomic values (first name, company name) but are insufficient for
+> personalization sentences — see the Product-Noun Substitution section
+> below for the failure mode they enable.
+
 ## Good Token Fill
 
 Good token fill feels like a human wrote the sentence after seeing the
@@ -79,3 +89,86 @@ Revvix / security positioning:
 - the token makes the sentence longer without making it better
 - the token sounds like a compliment sandwich
 - the token could be swapped into any message without changing meaning
+
+## Product-Noun Substitution (HARD INVARIANT — block before fill)
+
+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
+recipient personally **does** — their work, focus, or activity. It must NOT
+describe a product their company **builds or sells**.
+
+The grammar test: read `your <filled-value>` out loud. If it reads as if the
+recipient _uses_ or _has_ the thing, but the recipient actually _builds/sells_
+the thing, the fill is wrong → OMIT the entire sentence.
+
+**Allowed (buyer activities):**
+
+- `monetization research for indie devs`
+- `founder-led-sales experiments`
+- `GTM Engineering writing`
+- `outbound work for AI founders`
+- `pricing-strategy advisory`
+- `B2B SaaS GTM background` (history is fine — it describes the person)
+
+**Blocked (product nouns from the prospect's company):**
+
+- `Moneyball dashboard for CEOs` ← the prospect BUILDS this; they do not have one of their own
+- `monetization layer for AI builders` ← product description, not buyer activity
+- `AI scoring engine` / `platform for X` / `tool for X` / `API for X` ← any company-output noun
+- `Series A funding round` ← event, not activity
+
+Why this matters: the personalization line is supposed to make the buyer feel
+recognized as a person. A product-noun fill instead makes the message sound
+like it was written by an enrichment scraper — and worse, it implies we
+mistook the founder for a customer of their own product.
+
+**The omit-fallback is the safe default.** When you cannot produce a
+buyer-activity phrase that survives the grammar test, OMIT the sentence
+entirely. The message must read cleanly without the soft-bridge line. Do NOT
+substitute a generic noun (`your work`, `your stack`, `your team`) — those
+add no relevance and sound mail-merge-y. Aggressive omit > awkward fill.
+
+When the brief defines a `{{workflow_context}}` token (or any
+buyer-activity-shaped token), include this rule verbatim in the brief's Token
+Fill Rules section so per-row generation has the constraint in scope.
+
+## AI-Native Tokens (the canonical Sellable pattern)
+
+Personalization sentences should be authored as AI-native tokens — bracketed
+instructions, not field substitutions. Field substitutions (`{{first_name}}`,
+`{{company}}`) work for atomic values that drop into a fixed slot. But any
+sentence that requires _judgment_ about what to write should be authored as:
+
+```text
+[ALL_CAPS_NAME — Intent. DO: ... DON'T: ... FALLBACK: omit the line.]
+```
+
+The bracket lives inline in the message template. The model writes a sentence
+(or omits the entire line) following the inline contract. The bracket itself
+is replaced by the rendered sentence — or by nothing.
+
+**Why:** every personalization failure documented in this file (mail-merge
+phrasing, product-noun substitution, source-citation, generic noun
+substitutes) shares one root cause: the model was filling a fixed-frame slot
+under rules that lived elsewhere. AI-native tokens fix that by making the
+model COMPOSE a sentence under rules that live INLINE.
+
+**The original Sellable gold message (the canonical example)** uses two
+AI-native tokens:
+
+```text
+we're looking for design partners — and [PERSONALIZED REASON — their team
+size, role, or why they're a perfect fit].
+
+a) 15-min call — i'll show you how you could book more meetings with
+[THEIR ICP — who they want to reach], and if you like it we launch a pilot
+right there
+```
+
+Notice: `[PERSONALIZED REASON]` and `[THEIR ICP]` name what JOB the line
+does. The model produces a different rendered version per row, but every
+version is grammatically clean because the model is _writing_, not
+_filling_.
+
+**Full spec, contract requirements, and brief-authoring guide:** see
+`ai-native-tokens.md` in this same references directory.

package/skills/create-campaign-brief/references/brief-template.md

@@ -162,6 +162,17 @@ next step, not a section the customer needs to study in detail.
 Use 0-3 bullets max. If there is nothing special to note yet, say:
 `None yet — validate from the first lead sample.`
 
+**Personalization tokens — default to AI-native, not field substitution.**
+Atomic field tokens (`{{first_name}}`, `{{company}}`) are fine for greeting,
+subject, and any sentence that drops a single value into a fixed slot. Any
+personalization SENTENCE (a hook line that anchors the message to the
+prospect) should be authored as an AI-native bracket token in the message
+template — `[INTENT_NAME — Intent. DO: ... DON'T: ... FALLBACK: omit the
+line.]` — not as a `{{field}}` slot inside a fixed frame. The model writes
+the sentence per the inline contract; if it can't satisfy the DOs cleanly,
+it omits the entire line. Aggressive omit > awkward fill. Full spec and
+examples: `mcp/sellable/skills/create-campaign/references/ai-native-tokens.md`.
+
 ## Next Steps
 
 Keep this section simple and action-oriented. The customer should understand the