@sellable/mcp 0.1.32 → 0.1.34

package/dist/server.js

@@ -412,7 +412,9 @@ server.setRequestHandler(CallToolRequestSchema, async (request) => {
                 result = await fetchLinkedInPosts(args?.linkedinUrl, args?.limit);
                 break;
             case "fetch_linkedin_profile":
-                result = await fetchLinkedInProfile(args?.linkedinUrl);
+                result = await fetchLinkedInProfile(args?.linkedinUrl, {
+                    full: args?.full === true,
+                });
                 break;
             case "fetch_company":
                 result = await fetchCompany(args?.companyUrl);

package/dist/tools/auth.d.ts

@@ -18,6 +18,14 @@ export type AuthStatus = {
         message: string;
         guidance: string;
     };
+    /**
+     * Verbatim instruction for the AGENT (not the user) when auth is missing.
+     * The agent MUST follow this verbatim and MUST NOT show error.guidance to
+     * the user — that's a non-interactive fallback. This field is the single
+     * source of truth for the FTUX magic-link flow so even a stale skill copy
+     * does the right thing.
+     */
+    agentInstruction?: string;
 };
 export declare const authToolDefinitions: {
     name: string;

package/dist/tools/auth.js

@@ -22,7 +22,7 @@ function appendUpdateNotice(notice, update) {
 export const authToolDefinitions = [
     {
         name: "get_auth_status",
-        description: "Verify Sellable authentication early. Call this before any campaign work. Also performs a cached Sellable package update check. Returns ok=false with clear guidance when the token is missing, revoked, or the active workspace is not set. IMPORTANT: When auth succeeds, ALWAYS tell the user the _userNotice message so they know which workspace is active and whether an update is available.",
+        description: "Verify Sellable authentication early. Call this before any campaign work. Also performs a cached Sellable package update check. Returns ok=false with clear guidance when the token is missing, revoked, or the active workspace is not set. IMPORTANT: When auth succeeds, ALWAYS tell the user the _userNotice message so they know which workspace is active and whether an update is available. CRITICAL: When auth FAILS with a missing/invalid token (error.type is 'config' or 'auth'), the response includes an `agentInstruction` field with the verbatim FTUX magic-link signup flow. Follow agentInstruction VERBATIM. Do NOT show the user error.guidance — that's a fallback for non-interactive contexts only.",
         inputSchema: {
             type: "object",
             properties: {},
@@ -110,6 +110,36 @@ export async function getAuthStatus() {
         };
     }
     catch (error) {
+        // FTUX directive: when the user is not yet signed in, tell the AGENT
+        // (not the user) to run the magic-link CLI handoff verbatim. Treat this
+        // as the single source of truth so even a stale skill does the right
+        // thing instead of dumping the technical fallback guidance.
+        const ftuxAgentInstruction = "AGENT INSTRUCTION (verbatim, do not paraphrase, do not show the user `error.guidance`): " +
+            "The user has not signed in to Sellable yet. Run the magic-link CLI handoff. " +
+            "1) Say to the user verbatim:\\n" +
+            "`Welcome to Sellable! I'll help you launch a LinkedIn outbound campaign right here, all via chat — leads, messages, the whole thing.\\n\\n" +
+            "First, let's connect your Sellable account:\\n\\n" +
+            "  1. Drop your email below\\n" +
+            "  2. I'll send a magic login link to your inbox\\n" +
+            "  3. Click it, come back here, and we'll keep going\\n\\n" +
+            "What email should I use?` " +
+            "2) Wait for the user to type their email in normal chat (do NOT use AskUserQuestion / request_user_input). " +
+            "3) Call `mcp__sellable__start_cli_login({ email })` with that email. " +
+            "4) On `ok: true`, say verbatim (substituting the email exactly as typed):\\n" +
+            "`Magic link sent to {email}.\\n\\n" +
+            "─────────────────────────────────────────────\\n" +
+            "  Your turn — check your inbox\\n" +
+            "─────────────────────────────────────────────\\n\\n" +
+            "  1. Open the email from Sellable\\n" +
+            "  2. Click the magic link\\n" +
+            "  3. Come back here when you're done\\n\\n" +
+            "I'll be waiting right here.\\n\\n" +
+            "  (If your team already uses Sellable, ask an admin to invite you into their shared workspace instead — that gets you straight in.)` " +
+            "5) Call `mcp__sellable__wait_for_cli_login({ sessionId })` using the sessionId returned by start_cli_login. " +
+            "6) If the result is `error.type === 'tool_timeout_guard'`, IMMEDIATELY re-call wait_for_cli_login with the SAME sessionId — do not narrate, do not call start_cli_login again. Loop until you get a different result. " +
+            "7) On `ok: true`, the user is signed in and `~/.sellable/config.json` has been written. Branch on `isReturningUser`: " +
+            "if true, say `You're in — {activeWorkspaceName} workspace, ready to roll.\\n\\nNow — paste the LinkedIn profile URL of the person you'll be sending campaigns from. Usually that's you (the founder), or whoever's voice the messages should sound like.\\n\\ne.g. https://www.linkedin.com/in/your-handle`; " +
+            "if false, say `You're set up — your {activeWorkspaceName} workspace is ready.\\n\\nNow — paste the LinkedIn profile URL of the person you'll be sending campaigns from. Usually that's you (the founder), or whoever's voice the messages should sound like.\\n\\ne.g. https://www.linkedin.com/in/your-handle`";
         if (error instanceof SellableApiError && error.isAuthError) {
             return {
                 ...base,
@@ -120,6 +150,7 @@ export async function getAuthStatus() {
                     guidance: error.guidance ||
                         `Update ${configPath} with a valid token, then retry get_auth_status.`,
                 },
+                agentInstruction: ftuxAgentInstruction,
             };
         }
         const message = error instanceof Error ? error.message : String(error);
@@ -136,6 +167,7 @@ export async function getAuthStatus() {
                 message,
                 guidance,
             },
+            agentInstruction: isConfigError ? ftuxAgentInstruction : undefined,
         };
     }
 }

package/dist/tools/campaigns.js

@@ -123,7 +123,7 @@ export const campaignToolDefinitions = [
     },
     {
         name: "create_campaign",
-        description: 'Create a new campaign offer OR resume an existing one. Low-level write tool: load create-campaign workflow instructions first via get_subskill_prompt({ subskillName: "create-campaign" }) (or bootstrap_create_campaign + nextStep). If campaignId is provided, this tool returns the watchUrl + state for that campaign instead of creating a new campaign.\n\nINPUTS:\n- Pass EITHER `clientProspectId` (if you already have a prospect ID from a prior workflow) OR `senderLinkedinUrl` (the sender\'s LinkedIn profile URL — preferred for net-new campaigns).\n- Passing both is fine; `clientProspectId` wins.\n- Passing neither returns a preflight error.\n\nPREREQUISITES:\n- The /research-sender skill must have been run for this sender (sets the campaign brief).',
+        description: 'Create a new campaign offer OR resume an existing one. Low-level write tool: load create-campaign workflow instructions first via get_subskill_prompt({ subskillName: "create-campaign" }) (or bootstrap_create_campaign + nextStep). If campaignId is provided, this tool returns the watchUrl + state for that campaign instead of creating a new campaign.\n\nINPUTS:\n- `clientProspectId` is REQUIRED for net-new campaigns. It is the EnrichedProspect row ID for the campaign sender (used by ICP scoring, message generation, brief rendering — every downstream consumer reads sender context from `campaign.clientProspect`).\n- To obtain a `clientProspectId`, run the sender-enrichment flow first: this materializes an EnrichedProspect row from the sender\'s LinkedIn profile URL and returns its ID.\n- `senderLinkedinUrl` may be passed as informational metadata but is NOT a substitute for `clientProspectId` — the API will reject the create if `clientProspectId` is missing.\n\nPREREQUISITES:\n- The /research-sender skill must have been run for this sender (produces enrichment data and the EnrichedProspect row whose ID is `clientProspectId`).',
         inputSchema: {
             type: "object",
             properties: {
@@ -137,13 +137,13 @@ export const campaignToolDefinitions = [
                 },
                 clientProspectId: {
                     type: "string",
-                    description: "Optional. Existing EnrichedProspect row ID. Pass this OR senderLinkedinUrl. If both supplied, this wins.",
+                    description: "REQUIRED for net-new campaigns. EnrichedProspect row ID for the campaign sender. Produced by the sender-enrichment flow (research-sender). The API will reject the create with a 400 if this is missing.",
                 },
-                // Phase 114: named `senderLinkedinUrl` (not `linkedinUrl`) to disambiguate from
+                // `senderLinkedinUrl` (not `linkedinUrl`) to disambiguate from
                 // prospect-side `linkedinUrl` fields used in other tools (research-prospect etc.).
                 senderLinkedinUrl: {
                     type: "string",
-                    description: "Optional. Sender's LinkedIn profile URL (e.g. https://www.linkedin.com/in/jane-doe/). Preferred for net-new campaigns. Mutually compatible with clientProspectId (the latter wins if both supplied).",
+                    description: "Optional informational metadata: the sender's LinkedIn profile URL. NOT a substitute for clientProspectId — to materialize a prospect from a URL, run the sender-enrichment flow first.",
                 },
                 offerPositioning: {
                     type: "object",
@@ -597,12 +597,15 @@ export async function createCampaign(input) {
         missing.push("name");
     if (!input.campaignBrief)
         missing.push("campaignBrief");
-    if (!input.clientProspectId && !input.senderLinkedinUrl) {
-        missing.push("clientProspectId-or-senderLinkedinUrl");
+    // clientProspectId is required for net-new campaigns. Every downstream
+    // consumer (ICP scoring, message generation, brief rendering) reads sender
+    // context from `campaign.clientProspect`. senderLinkedinUrl is informational
+    // metadata only — it is NOT a substitute and the API will reject the create
+    // if clientProspectId is missing.
+    if (!input.clientProspectId) {
+        missing.push("clientProspectId");
     }
-    // Phase 114 edge-case fix: cheap URL sanity check on senderLinkedinUrl.
-    // Don't deep-validate; just reject obvious garbage so the downstream
-    // flow doesn't try to fetch a non-LinkedIn URL.
+    // Cheap URL sanity check on senderLinkedinUrl when supplied.
     if (input.senderLinkedinUrl &&
         typeof input.senderLinkedinUrl === "string" &&
         !input.senderLinkedinUrl.includes("linkedin.com")) {
@@ -614,7 +617,7 @@ export async function createCampaign(input) {
             `or all create fields. Missing: ${missing.join(", ")}.\n\n` +
             "Remediation:\n" +
             '- For full workflow, call get_subskill_prompt({ subskillName: "create-campaign" }) and follow it.\n' +
-            '- For net-new campaign creation, call get_subskill_prompt({ subskillName: "research-sender" }), run sender research (parallel batch — no enrich_sender required), call complete_sender_research(...), then call create_campaign with EITHER clientProspectId OR senderLinkedinUrl (the sender\'s LinkedIn profile URL).\n' +
+            "- For net-new campaign creation: run the `research-sender` flow first to materialize an EnrichedProspect for the sender from their LinkedIn profile URL, then pass the resulting prospect ID as `clientProspectId`. The campaign sender context (used by ICP scoring, message generation, brief rendering) is read from `campaign.clientProspect`, so this row must exist before the campaign is minted.\n" +
             "- For resume, call create_campaign with campaignId only.");
     }
     assertNetNewCreateCampaignResearchReady();

package/dist/tools/cli-login.d.ts

@@ -38,6 +38,12 @@ type WaitForCliLoginSuccess = {
     activeWorkspaceId: string;
     activeWorkspaceName?: string;
     configPath: string;
+    /**
+     * True if the server reused the user's existing default workspace
+     * (vs creating a new one). The skill uses this to branch the
+     * post-auth greeting copy.
+     */
+    isReturningUser: boolean;
     /** Locked verbatim string the agent shows the user. */
     humanMessage: string;
 };

package/dist/tools/cli-login.js

@@ -131,7 +131,7 @@ export async function handleStartCliLogin(args) {
         sessionId: body.sessionId,
         confirmUrl: body.confirmUrl,
         expiresInSec: body.expiresInSec,
-        humanMessage: `Magic link sent to ${args.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.)`,
+        humanMessage: `Magic link sent to ${args.email}.\n\n─────────────────────────────────────────────\n  Your turn — check your inbox\n─────────────────────────────────────────────\n\n  1. Open the email from Sellable\n  2. Click the magic link\n  3. Come back here when you're done\n\nI'll be waiting right here.\n\n  (If your team already uses Sellable, ask an admin to invite you into their shared workspace instead — that gets you straight in.)`,
     };
 }
 export async function handleWaitForCliLogin(args) {
@@ -187,6 +187,7 @@ export async function handleWaitForCliLogin(args) {
                         ? { activeWorkspaceName: body.activeWorkspaceName }
                         : {}),
                     configPath,
+                    isReturningUser: body.isReturningUser ?? false,
                     humanMessage: "Signed in. Continuing.",
                 };
             }

package/dist/tools/linkedin.d.ts

@@ -15,6 +15,7 @@ export declare const linkedinToolDefinitions: ({
             };
             postUrl?: undefined;
             sources?: undefined;
+            full?: undefined;
             companyUrl?: undefined;
             sortBy?: undefined;
             linkedin_url?: undefined;
@@ -44,6 +45,7 @@ export declare const linkedinToolDefinitions: ({
                 default: number;
             };
             linkedinUrl?: undefined;
+            full?: undefined;
             companyUrl?: undefined;
             sortBy?: undefined;
             linkedin_url?: undefined;
@@ -61,6 +63,11 @@ export declare const linkedinToolDefinitions: ({
                 type: string;
                 description: string;
             };
+            full: {
+                type: string;
+                description: string;
+                default: boolean;
+            };
             limit?: undefined;
             postUrl?: undefined;
             sources?: undefined;
@@ -85,6 +92,7 @@ export declare const linkedinToolDefinitions: ({
             limit?: undefined;
             postUrl?: undefined;
             sources?: undefined;
+            full?: undefined;
             sortBy?: undefined;
             linkedin_url?: undefined;
             max_posts?: undefined;
@@ -115,6 +123,7 @@ export declare const linkedinToolDefinitions: ({
             linkedinUrl?: undefined;
             postUrl?: undefined;
             sources?: undefined;
+            full?: undefined;
             linkedin_url?: undefined;
             max_posts?: undefined;
         };
@@ -139,6 +148,7 @@ export declare const linkedinToolDefinitions: ({
             limit?: undefined;
             postUrl?: undefined;
             sources?: undefined;
+            full?: undefined;
             companyUrl?: undefined;
             sortBy?: undefined;
         };
@@ -158,6 +168,7 @@ export declare const linkedinToolDefinitions: ({
             limit?: undefined;
             postUrl?: undefined;
             sources?: undefined;
+            full?: undefined;
             companyUrl?: undefined;
             sortBy?: undefined;
             max_posts?: undefined;
@@ -177,7 +188,9 @@ export declare function fetchLinkedInPosts(linkedinUrl: string, limit?: number):
     posts: SerializedPost[];
     count: number;
 }>;
-export declare function fetchLinkedInProfile(linkedinUrl: string): Promise<unknown>;
+export declare function fetchLinkedInProfile(linkedinUrl: string, options?: {
+    full?: boolean;
+}): Promise<unknown>;
 export declare function fetchCompany(companyUrl: string): Promise<unknown>;
 export declare function fetchCompanyPosts(companyUrl: string, limit?: number, sortBy?: "recent" | "top"): Promise<{
     posts: SerializedPost[];

package/dist/tools/linkedin.js

@@ -46,7 +46,7 @@ export const linkedinToolDefinitions = [
     },
     {
         name: "fetch_linkedin_profile",
-        description: "Fetch LinkedIn profile details from Sellable scrape endpoints.",
+        description: "Fetch LinkedIn profile details. Defaults to the cheaper 'main' payload — same envelope shape with most-recent role, headline, about, location, education, top skills, certifications, languages, projects, etc. Pass full=true ONLY when you need the long-tail experience history (positions 6+) or complete skill list (skills 3+) for deep research. Most personalization, qualification, and outreach use cases work with main; reach for full only when the user explicitly asks for full work history or comprehensive skill audit.",
         inputSchema: {
             type: "object",
             properties: {
@@ -54,6 +54,11 @@ export const linkedinToolDefinitions = [
                     type: "string",
                     description: "Full LinkedIn profile URL",
                 },
+                full: {
+                    type: "boolean",
+                    description: "Opt into the full payload (~38% more expensive, slightly slower). Set true only when you specifically need the long-tail experience history or full skill list. Default false (main payload).",
+                    default: false,
+                },
             },
             required: ["linkedinUrl"],
         },
@@ -152,9 +157,12 @@ export async function fetchLinkedInPosts(linkedinUrl, limit = 25) {
         count: posts.length,
     };
 }
-export async function fetchLinkedInProfile(linkedinUrl) {
+export async function fetchLinkedInProfile(linkedinUrl, options = {}) {
     const api = getApi();
     const params = new URLSearchParams({ linkedinUrl });
+    if (options.full) {
+        params.set("full", "true");
+    }
     return api.get(`/api/v1/scrape/linkedin/profile?${params.toString()}`);
 }
 export async function fetchCompany(companyUrl) {

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -331,7 +331,15 @@ updates.
    a. Say to the user verbatim:
 
    ```text
-   Welcome to Sellable. What's your email?
+   Welcome to Sellable! I'll help you launch a LinkedIn outbound campaign right here, all via chat — leads, messages, the whole thing.
+
+   First, let's connect your Sellable account:
+
+     1. Drop your email below
+     2. I'll send a magic login link to your inbox
+     3. Click it, come back here, and we'll keep going
+
+   What email should I use?
    ```
 
    b. Wait for the user to paste their email in normal chat. Do NOT use
@@ -347,7 +355,19 @@ updates.
    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.)
+   Magic link sent to {email}.
+
+   ─────────────────────────────────────────────
+     Your turn — check your inbox
+   ─────────────────────────────────────────────
+
+     1. Open the email from Sellable
+     2. Click the magic link
+     3. Come back here when you're done
+
+   I'll be waiting right here.
+
+     (If your team already uses Sellable, ask an admin to invite you into their shared workspace instead — that gets you straight in.)
    ```
 
    f. Call `mcp__sellable__wait_for_cli_login({ sessionId })` using the
@@ -370,13 +390,33 @@ updates.
      `error.guidance` and stop.
 
    - On `ok: true`, the user is signed in and `~/.sellable/config.json` has
-     been written. Your IMMEDIATE next visible message MUST be the locked
-     Step 3 narration verbatim (no welcome line, no "all set", no "you're
-     signed in", no acknowledgement of any kind):
+     been written. Your IMMEDIATE next visible message branches on
+     `isReturningUser` from the tool result:
 
-     ```text
-     Now — paste the LinkedIn profile URL of the person you want to send from.
-     ```
+     - If `isReturningUser === true`, prepend ONE line acknowledging the
+       reused workspace, then the locked Step 3 narration verbatim
+       (substituting `activeWorkspaceName` exactly):
+
+       ```text
+       You're in — {activeWorkspaceName} workspace, ready to roll.
+
+       Now — paste the LinkedIn profile URL of the person you'll be sending campaigns from. Usually that's you (the founder), or whoever's voice the messages should sound like.
+
+       e.g. https://www.linkedin.com/in/your-handle
+       ```
+
+     - If `isReturningUser === false`, prepend ONE line confirming the new
+       workspace, then the locked Step 3 narration verbatim:
+
+       ```text
+       You're set up — your {activeWorkspaceName} workspace is ready.
+
+       Now — paste the LinkedIn profile URL of the person you'll be sending campaigns from. Usually that's you (the founder), or whoever's voice the messages should sound like.
+
+       e.g. https://www.linkedin.com/in/your-handle
+       ```
+
+     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

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

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

@@ -1064,11 +1064,17 @@ proof:`, `p.s. useful proof:`, `p.s. proof:`, or `p.s. social proof:`.
   `{{psLine}}`, and do not use `{{recent_signal_quote}}`; use fields that exist
   on the enriched prospect row instead.
 - the live body under `## Approved Message Template` must be sender-ready copy.
-  Do not include bracketed instruction placeholders such as `[ROW BRIDGE ...]`,
-  `[insert ...]`, `[generated ...]`, or prose that tells a later step to
-  paraphrase/fill a line. Put per-row generation rules in `## Token Fill Rules`
-  with concrete enriched-row fields, and copy approved good/bad examples into
-  `## Token Fill Examples`, or route to `revise-messaging`.
+  Bracketed text in the body is allowed only when it is a fully-specified
+  AI-native token (`[ALL_CAPS_NAME — Intent. DO: ... DON'T: ... FALLBACK:
+omit the line.]` — see
+  `mcp/sellable/skills/create-campaign/references/ai-native-tokens.md` for the
+  contract). Bracketed instruction placeholders that lack a contract are
+  BLOCKED — including `[ROW BRIDGE ...]`, `[insert ...]`, `[generated ...]`,
+  and any prose that defers per-row composition to a later step without
+  giving the model the rules. Either upgrade the placeholder to a full
+  AI-native token (Intent / DO / DON'T / FALLBACK), put the per-row rules in
+  `## Token Fill Rules` with concrete enriched-row fields, or route to
+  `revise-messaging`.
 - `approval-packet.md` and the live campaign brief passed to `create_campaign`
   must include `## Approved Message Template`, `## Token Fill Rules`, and
   `## Token Fill Examples`. `## Token Fill Examples` must copy the approved
@@ -1391,25 +1397,39 @@ Exact sequence:
    `campaignBrief.content` contains `{{...}}`; without this marker it will
    use full-generation mode and may rewrite the approved message.
    The live template body must contain only sender-ready copy plus supported
-   `{{tokens}}`; no bracketed instructions or placeholder prose may appear in
-   the body.
-   Include `## Token Fill Rules` for every enriched-prospect-row token in the
-   template. Tokens may be row fields such as `{{first_name}}`,
-   `{{company}}`, `{{role}}`, `{{headline}}`, `{{profile_summary}}`,
-   `{{post_context}}`, `{{comment_summary}}`, `{{source_post_topic}}`, or
-   `{{row_proof_note}}` when those exact fields are supported by the
-   row/enrichment data. Do not document static sender identity, product name,
-   proof points, casing style, `{{recent_signal_quote}}`, or abstract slot
-   tokens such as `{{hookLine}}`, `{{painLine}}`, `{{productLine}}`,
-   `{{closeLine}}`, or `{{psLine}}`.
-   Include `## Token Fill Examples` copied from the approved message review and
-   validation artifacts. It must preserve `Good token fill:`, `Good omit:`,
-   `Bad token fill:`, `Why bad:`, `Fallback if missing:`, and
-   `Token fill basis:` so the minted campaign brief teaches future row
-   generation how to fill tokens, what fills are blocked, and what to do when
-   row data is missing. If the brief does not contain `## Token Fill Rules` and
-   `## Token Fill Examples`, do not call `create_campaign`; route back to
-   message review or approval packet generation.
+   tokens. Two token shapes are allowed:
+   - `{{snake_case}}` field-substitution tokens for atomic values that drop
+     directly into a fixed slot (greeting, subject, company name).
+   - `[ALL_CAPS_NAME — Intent. DO: ... DON'T: ... FALLBACK: omit the line.]`
+     AI-native tokens for personalization sentences. The bracket carries
+     the contract inline; the model writes a sentence (or omits the line)
+     per the inline rules. Full spec:
+     `mcp/sellable/skills/create-campaign/references/ai-native-tokens.md`.
+     No other bracketed placeholders are allowed — bracketed prose without an
+     explicit Intent / DO / DON'T / FALLBACK contract (e.g., `[ROW BRIDGE]`,
+     `[insert ...]`, `[generated ...]`) is BLOCKED because it leaves the
+     per-row generation under-specified.
+     Include `## Token Fill Rules` for every token in the template. Field
+     tokens may be row fields such as `{{first_name}}`, `{{company}}`,
+     `{{role}}`, `{{headline}}`, `{{profile_summary}}`, `{{post_context}}`,
+     `{{comment_summary}}`, `{{source_post_topic}}`, or `{{row_proof_note}}`
+     when those exact fields are supported by the row/enrichment data. AI-native
+     tokens are listed in the rules table by name and type with a pointer back
+     to the inline contract (the rules themselves live inside the bracket — do
+     not duplicate them in the table). Do not document static sender identity,
+     product name, proof points, casing style, `{{recent_signal_quote}}`, or
+     abstract slot tokens such as `{{hookLine}}`, `{{painLine}}`,
+     `{{productLine}}`, `{{closeLine}}`, or `{{psLine}}` — those are abstract
+     slots without a contract; convert them to AI-native bracket tokens with
+     real Intent / DO / DON'T / FALLBACK clauses, or cut them.
+     Include `## Token Fill Examples` copied from the approved message review and
+     validation artifacts. It must preserve `Good token fill:`, `Good omit:`,
+     `Bad token fill:`, `Why bad:`, `Fallback if missing:`, and
+     `Token fill basis:` so the minted campaign brief teaches future row
+     generation how to fill tokens, what fills are blocked, and what to do when
+     row data is missing. If the brief does not contain `## Token Fill Rules` and
+     `## Token Fill Examples`, do not call `create_campaign`; route back to
+     message review or approval packet generation.
 3. Call `bootstrap_create_campaign({ flowVersion: "v2" })`. Respect
    `safeToProceed`; on blocking errors, surface and stop.
 4. Call

package/skills/generate-messages/SKILL.md

@@ -1139,6 +1139,44 @@ yours` are not enough when a safe row token would make the line feel more
   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.
+- **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
+  recipient personally **does** — their work, focus, or activity. It must NOT
+  describe a product their company **builds or sells**. Grammar test: read
+  `your <filled-value>` out loud. If it reads as if the recipient _uses_ or
+  _has_ the thing, but they actually _build/sell_ the thing, the fill is wrong
+  → OMIT the entire sentence. Examples: `your monetization layer for AI
+builders` (BLOCKED — product description from the company), `your Moneyball
+dashboard for CEOs` (BLOCKED — the recipient builds this product, doesn't
+  have one of their own), `your AI scoring engine` (BLOCKED — product), vs
+  `your monetization research for AI founders` (ALLOWED — buyer activity),
+  `your founder-led-sales experiments` (ALLOWED — activity), `your GTM
+Engineering writing` (ALLOWED — what they do publicly). The omit-fallback
+  is the safe default. Aggressive omit > awkward fill. Do NOT substitute
+  generic nouns (`your work`, `your stack`, `your team`) — those add no
+  relevance and read as mail merge.
+- **AI-native tokens — write the sentence, don't fill the slot (HARD
+  INVARIANT):** when the message template contains a bracketed instruction
+  token of the form \`[ALL_CAPS_NAME — instructions]\`, that placeholder is
+  NOT a field-substitution slot. It is an inline instruction. Read the
+  contents of the bracket. The bracket will name an Intent, DO shapes,
+  DON'T shapes, and a FALLBACK clause. Your job: COMPOSE a complete
+  sentence (or sentences, if the intent calls for it) that satisfies all
+  the DO rules and avoids all the DON'T rules, then replace the bracket
+  with that rendered sentence. If you cannot satisfy the DOs cleanly from
+  the row data, REPLACE THE BRACKET WITH NOTHING (the entire line is
+  omitted, including any leading/trailing whitespace; the surrounding
+  message must read cleanly without it). Aggressive omit > awkward fill.
+  Never leave the bracket itself in the rendered output. Never substitute
+  a placeholder, ellipsis, or generic noun (\`your work\`, \`your team\`)
+  when the FALLBACK clause says omit. Canonical example from the runtime
+  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.
 - **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