@sellable/mcp 0.1.74 → 0.1.76

package/package.json

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

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

@@ -456,11 +456,22 @@ should test for this campaign. Those can run in parallel and usually take
   message quality gate outputs between `message-validation.md` and
   `approval-packet.md`.
 - Run the dependency chain as a DAG: `create-campaign-brief` -> `find leads`;
-  once `lead-review.md` and `lead-sample.json` exist, run `filter leads` and
-  `message generation` from the same basis (`brief.md`, `lead-review.md`,
-  `lead-sample.json`). Approval waits for both `lead-filter.md` and
-  `message-validation.md`, then reconciles that the selected message basis rows
-  still pass the final filter.
+  once `lead-review.md` and `lead-sample.json` exist, the normal path is the
+  `post-lead-workstreams` step. Launch `filter leads` and `message generation`
+  from the same basis (`brief.md`, `lead-review.md`, `lead-sample.json`) as
+  separate workstreams when the host supports real subagents/background work.
+  In Claude Code, use two Task/Agent subagents in the same assistant message;
+  in Codex, use disjoint worker subagents when the host exposes them. The
+  existing `filter-rubric` and `message-generation` steps remain focused retry
+  and resume targets.
+- Message generation does not need `lead-filter.md` to start. The moment
+  `lead-sample.json` exists with at least 5 probable good-fit rows and the lead
+  source is confirmed or auto-confirmed, start the message-generation
+  workstream from `brief.md`, `lead-review.md`, and `lead-sample.json`. It can
+  prepare proof inventory, token strategy, and candidate angles while
+  filter-leads tightens keep/exclude rules. Approval still waits for both
+  `lead-filter.md` and `message-validation.md`, then reconciles that the
+  selected message basis rows still pass the final filter.
 - `lead-sample.json` from `find leads` is always the message sample source.
   `filter leads` must not create a different message sample or cause message
   generation to fetch new prospects. The filter only marks which find-leads

package/skills/create-campaign-v2/core/flow.v2.json

@@ -548,10 +548,106 @@
         "auto_continue"
       ],
       "transitions": {
-        "lead_review_confirmed": "filter-rubric",
+        "lead_review_confirmed": "post-lead-workstreams",
         "revise_leads": "find-leads",
-        "confirm_with_user": "filter-rubric",
-        "auto_continue": "filter-rubric"
+        "confirm_with_user": "post-lead-workstreams",
+        "auto_continue": "post-lead-workstreams"
+      },
+      "interruptOnly": true
+    },
+    {
+      "id": "post-lead-workstreams",
+      "label": "Post-lead filter and message workstreams",
+      "normalFlow": true,
+      "onEnter": [
+        {
+          "action": "launch_post_lead_workstreams",
+          "mode": "parallel_when_host_supports_subagents",
+          "branches": [
+            {
+              "name": "filter-leads",
+              "target": "filter-leads",
+              "inputs": ["brief.md", "lead-review.md", "lead-sample.json"],
+              "producesArtifacts": ["lead-filter.md"],
+              "optionalProducesArtifacts": ["rubric.json"],
+              "ownership": "lead quality, false-positive patterns, keep/exclude rules, and production rubric translation only"
+            },
+            {
+              "name": "message-generation",
+              "target": "generate-messages",
+              "mode": "DRY MODE",
+              "inputs": ["brief.md", "lead-review.md", "lead-sample.json"],
+              "producesArtifacts": ["message-validation.md"],
+              "optionalProducesArtifacts": [
+                "message-prep.md",
+                "message-candidate-drafts.md"
+              ],
+              "ownership": "proof inventory, token strategy, angle drafting, skeptical-prospect review, and selected winner only"
+            }
+          ],
+          "earlyMessageStartRule": "As soon as lead-sample.json exists with at least 5 probable good-fit rows and the lead source is confirmed or auto-confirmed, launch message-generation from brief.md, lead-review.md, and lead-sample.json. Do not wait for lead-filter.md to begin proof inventory, token planning, or candidate angles.",
+          "finalMessageReconcileRule": "message-validation.md may start before lead-filter.md exists, but before message-review it must cite only lead-sample.json rows that still pass lead-filter.md. If the selected winner depends on a row later excluded by lead-filter.md, revise message-generation before message review.",
+          "claudeRule": "In Claude Code, launch both workstreams with Task/Agent subagents in the same assistant message when Task is available. Do not run filter first and then message generation unless subagents/background work are unavailable.",
+          "codexRule": "In Codex, launch disjoint worker subagents for filter-leads and message-generation when the host exposes subagents for this run. If the host cannot spawn them, run the same branches sequentially and say so.",
+          "fallback": "If real parallel branches are unavailable, run filter-leads and then message-generation in the parent thread. Do not claim background or parallel work in that fallback."
+        },
+        {
+          "action": "wait_for_post_lead_artifacts",
+          "requiredArtifacts": ["lead-filter.md", "message-validation.md"],
+          "optionalArtifacts": [
+            "rubric.json",
+            "message-prep.md",
+            "message-candidate-drafts.md"
+          ],
+          "reconciliationRule": "Before entering message-review, verify lead-filter.md and message-validation.md both came from the same brief.md, lead-review.md, and lead-sample.json. lead-filter.md gates the sample rows; lead-sample.json remains the message sample source."
+        }
+      ],
+      "requiredArtifacts": ["brief.md", "lead-review.md", "lead-sample.json"],
+      "producesArtifacts": ["lead-filter.md", "message-validation.md"],
+      "optionalProducesArtifacts": [
+        "rubric.json",
+        "message-prep.md",
+        "message-candidate-drafts.md"
+      ],
+      "allowedTools": [
+        "get_subskill_prompt",
+        "get_subskill_asset",
+        "Task",
+        "spawn_agent",
+        "AskUserQuestion",
+        "request_user_input"
+      ],
+      "toolRules": [
+        "The post-lead workstreams are disjoint: filter-leads owns lead-filter.md/rubric.json; message-generation owns message-validation.md/message-prep.md/message-candidate-drafts.md.",
+        "message-generation can start before lead-filter.md, but message-review cannot start until both lead-filter.md and message-validation.md exist and reconcile against the same lead-sample.json.",
+        "Do not let filter-leads create a new message sample. Do not let message-generation fetch new prospects.",
+        "Before writing message-validation.md, message-generation must read 100% of the real generate-messages prompt via chunked get_subskill_prompt({ subskillName: \"generate-messages\", offset, limit }) calls."
+      ],
+      "doNotAllow": [
+        "create_campaign",
+        "save_rubrics",
+        "import_leads",
+        "confirm_lead_list",
+        "update_campaign",
+        "queue_cells",
+        "start_campaign",
+        "check_rubric",
+        "generate_messages"
+      ],
+      "watchRequired": false,
+      "waitFor": [
+        "post_lead_workstreams_ready",
+        "revise_leads",
+        "revise_rubric",
+        "revise_messaging",
+        "confirm_with_user"
+      ],
+      "transitions": {
+        "post_lead_workstreams_ready": "message-review",
+        "revise_leads": "find-leads",
+        "revise_rubric": "filter-rubric",
+        "revise_messaging": "message-generation",
+        "confirm_with_user": "message-review"
       },
       "interruptOnly": true
     },

package/skills/generate-messages/SKILL.md

@@ -66,8 +66,11 @@ Use this mode when the caller explicitly says `DRY MODE`, `Phase 84`,
 `create-campaign-v2`, or provides:
 
 - `brief.md`
-- `lead-filter.md`
 - `lead-sample.json`
+- `lead-filter.md` when available. In the create-campaign-v2
+  `post-lead-workstreams` step, message generation may start before
+  `lead-filter.md` exists so it can prepare proof inventory, token strategy,
+  and candidate angles while filter-leads runs.
 
 Required dry-mode contract:
 
@@ -78,12 +81,22 @@ Required dry-mode contract:
 - do not call `mcp__sellable__update_campaign_brief`
 - do not mutate DB-backed campaign state
 - do not fetch fresh web or LinkedIn research
-- use only `brief.md`, `lead-filter.md`, and `lead-sample.json`
+- use only `brief.md`, `lead-sample.json`, and `lead-filter.md` when present
 - treat `lead-sample.json` from find-leads as the message sample source; do not
   ask filter-leads for a new sample, create a new sample, or fetch additional
   prospects for dry-mode message generation
-- use `lead-filter.md` only to decide which find-leads sample rows remain valid
-  for the final winner and which false-positive patterns must be avoided
+- if `lead-filter.md` is not present yet, do the expensive early work only:
+  proof inventory, token rules, strategy map, candidate angle drafting, and
+  provisional sample fills. Prefer writing `message-prep.md` and
+  `message-candidate-drafts.md` while waiting for the filter branch.
+- 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
 - generate 2-3 sample messages inline
 - write findings to `message-validation.md`
 - start `message-validation.md` with `Mode: DRY MODE (no DB mutation)`
@@ -98,9 +111,13 @@ Dry mode validates message quality before campaign mint.
 Read:
 
 - `brief.md`
-- `lead-filter.md`
 - `lead-sample.json` from the find-leads step; this is the only allowed sample
   source for dry-mode message generation
+- `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`
@@ -108,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 →
@@ -522,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:
 
@@ -1143,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
@@ -1180,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
@@ -1937,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
@@ -1946,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
@@ -1964,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