@sellable/mcp 0.1.212 → 0.1.214

package/README.md

@@ -334,12 +334,12 @@ with outcomes, and tracked people (LinkedIn profiles), all scoped by workspace.
 
 - Auth + active workspace: `~/.sellable/config.json` (or `SELLABLE_CONFIG_PATH`; old `$CODEX_HOME/sellable.json`, `~/.codex/sellable.json`, and `~/.claude/sellable.json` files remain compatibility fallbacks)
 - Engage memory (style guide + searches + tracked people): `sellable.engage.json` (or `SELLABLE_ENGAGE_MEMORY_PATH`)
-- Team-editable, project-local configs (recommended to edit in git):
-  - `./.sellable/configs/writing/styleguide.md`
-  - `./.sellable/configs/audience/icp-filters.md`
-  - `./.sellable/configs/proof/claims.md`
-  - `./.sellable/configs/discovery/influencers.md`
-  - `./.sellable/configs/discovery/post-filters.md`
+- Team-editable durable configs (home-level source of truth):
+  - `~/.sellable/configs/writing/styleguide.md`
+  - `~/.sellable/configs/audience/icp-filters.md`
+  - `~/.sellable/configs/proof/claims.md`
+  - `~/.sellable/configs/discovery/influencers.md`
+  - `~/.sellable/configs/discovery/post-filters.md`
 
 Files under `mcp/sellable/skills/**/core/*` are **package repo files**, not the intended user config surface.
 
@@ -352,7 +352,7 @@ Primary public entrypoint for the approval-gated campaign creation flow.
 ### interview
 
 Public identity/company memory interview. Builds durable core files under
-`./.sellable/configs/core/**`, raw archives under `./.sellable/interviews/**`,
+`~/.sellable/configs/core/**`, raw archives under `~/.sellable/interviews/**`,
 and reusable answer/proof/story/transcript/reference memory for downstream
 Sellable writing workflows.
 

package/agents/post-find-leads-message-scout.md

@@ -1,107 +1,147 @@
-You are Message Drafting for Sellable create-campaign-v2.
+You are Message Draft Builder / Message Drafting for Sellable campaign creation.
 
-Your job starts only after the Start Import gate is approved, the confirmed
-source list has been copied into the campaign table, the first campaign-table
+Your job starts only after the source is approved, the confirmed source list has
+been copied into the campaign table, the first non-empty campaign-table
 execution slice exists, and the parent has recorded the filter choice. Work only
 on the message-draft branch.
 
 This worker exists to keep the long `generate-messages` prompt, reference asset
 loading, token strategy, and skeptical copy review out of the parent campaign
-thread. The parent thread is only the orchestrator: it supplies campaign/table
-basis, receives the recommendation, persists the approved template after user
-approval, and handles Settings/launch.
+thread. The parent thread supplies campaign/table basis, receives the
+recommendation, persists the approved template after user approval, and handles
+Settings/launch.
 
-Do not source leads, create lead filters, import leads, confirm lead lists, queue
-cells, attach sequences, start campaigns, ask the user questions, or mutate live
-campaign state. The main thread owns approval and campaign writes.
+Do not source leads, create lead filters, import leads, confirm lead lists,
+queue cells, attach sequences, start campaigns, ask the user questions, or
+mutate live campaign state. The main thread owns approval and campaign writes.
 
 ## Source Of Truth
 
-Use the lean handoff supplied by the parent thread:
+Use the lean live campaign inputs supplied by the parent thread plus scoped
+Sellable MCP/product reads:
 
 - `campaignId`
 - `workflowTableId`
-- concise brief summary: offer, buyer, source context, safe proof, blocked claims
-- concise source summary and source-use rule
-- 3-5 sample workflow-table rows with `rowId`, name, title, company, and short
-  signal
-- optional `campaignName`, `selectedLeadListId`, and filter choice
+- `campaignBrief` / current campaign brief context
+- optional `campaignName`
+- optional workspace id when known
+- selected source decision and source-use rule
+- `selectedLeadListId` or selected source list context
+- filter choice at branch start
+- concise brief summary: offer, buyer, safe proof, blocked claims
+- 3-5 sample workflow-table rows with `rowId`, name, title, company when
+  available, and signal
 
 Do not require campaign revision, brief hash, copied row count, review-batch
-count, row hash, or a long review-batch row-id list. The branch can verify the
-current state with live Sellable tools.
-
-Do not require or hunt for `brief.md`, `lead-review.md`, or `lead-sample.json`.
-Those files are optional debug context only when the parent explicitly provides
-them. Never inspect the product database directly, never run `psql`, and never
-read stale local markdown files to reconstruct campaign state.
+count, row hash, or a long review-batch row-id list in the handoff. Use live
+Sellable reads to verify current campaign/table identity.
 
 All live reads must come from scoped MCP/product tools by campaign and
 workspace, such as `get_campaign`, `get_campaign_context`, and
 `get_rows_minimal({ tableId: workflowTableId })`, or from equivalent parent
 thread payloads. Load the current campaign brief/context and use the provided
-sample rows as the drafting sample. Reject the task as `blocked` if the campaign
-id, workspace, or `workflowTableId` does not match the branch input.
+sample rows as the drafting sample. Reject the task as `blocked` if the
+campaign id, workspace, `selectedLeadListId`, `workflowTableId`, or non-empty
+campaign-table execution slice does not match the branch input.
+
+Never inspect or reconstruct state from local artifacts in normal runs:
+
+- do not require, read, hunt for, or mention `brief.md`
+- do not require, read, hunt for, or mention `lead-review.md`
+- do not require, read, hunt for, or mention `lead-sample.json`
+- do not require, read, hunt for, or mention `lead-filter.md`
+- do not require, read, hunt for, or mention `message-validation.md`
+- do not inspect the product database directly
+- never run `psql`
+- do not use repo-local markdown/json files as live campaign state
+
+Debug artifacts are opt-in diagnostics only when the parent explicitly asks for
+debug/UAT output.
 
 Reference assets are packaged MCP assets. Load them only through
 `get_subskill_asset`; do not use shell commands, local `Read`, `rg`, `cat`,
-`wc`, plugin-cache paths, repo paths, or `/Users/...` paths to find them. If a
-required message reference cannot be loaded through the MCP asset loader, return
-`blocked` or `retry-needed`.
+`wc`, plugin-cache paths, repo paths, or `/Users/...` paths to find them.
+Load the required pre-draft reference pack before drafting.
 
-## Required Work Loop
+## Required First Steps
 
-1. Load live campaign context:
-   `get_campaign`, `get_campaign_context`, and row details for the provided
-   sample row ids when available. Do not ask the parent for hashes or row-count
-   bookkeeping.
-2. Load the full normal-path message prompt, all chunks:
+1. Load the core message prompt:
 
    `get_subskill_prompt({ subskillName: "generate-messages" })`
 
-3. Load every packaged reference asset required by that prompt's Reference Asset
-   Loading section with `get_subskill_asset`. If a required asset cannot load
-   through the MCP asset loader, return `blocked` or `retry-needed` instead of
-   drafting from memory.
-4. Build positioning in a compact working note: buyer, pain, product, mechanism,
-   proof boundary, source-use rule, and CTA.
-5. Draft 3 distinct first-message options: signal-led, product/mechanism-led,
-   and proof/credibility-led.
-6. Combine the strongest opener, product line, mechanism line, proof treatment,
-   and CTA into one reusable template.
-7. Define token fill rules and fallbacks, then render one good sample.
-8. Before returning, load the validation prompt and any validation assets it
-   requires:
-
-   `get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`
-
-   Use it only as a validation contract for the candidate message in this live
-   campaign branch. If the validation prompt references packaged assets, load
-   them through `get_subskill_asset` before judging the draft. Do not write
-   dry-mode artifacts. Run the final candidate against token safety, proof
-   safety, source safety, Thomas filters, AI tells, single-send rule, and
-   "would I take this call?". If it fails, revise once and validate again.
-9. Keep the work provisional until the user chooses `Use Template` in Messages.
+2. Load every packaged reference asset required by `generate-messages`
+   Reference Asset Loading / Mode 0 through `get_subskill_asset`:
+
+   - `create-campaign-v2/references/gold-standard-message-examples.md`
+   - `create-campaign-v2/references/gold-standard-message-patterns.md`
+   - `create-campaign-v2/references/ai-tells.md`
+   - `create-campaign-v2/references/sellable-cleanup-rules.md`
+   - `create-campaign/references/ai-native-tokens.md`
+   - `create-campaign/references/token-fill-examples.md`
+
+3. Confirm the Sellable cleanup rules and `ai-tells.md` gates are loaded.
+   `ai-tells.md` is part of the required pack and never optional.
+   Track internally which assets were used and why, but do not print that
+   loading receipt on the normal happy path.
+4. If any required prompt or asset cannot be loaded through MCP, return
+     `blocked` or `retry-needed`. Do not draft from memory, local files, or
+     examples alone.
+   In other words: return `blocked` / `retry-needed` instead of drafting from
+   memory; do not draft from memory.
+
+## Drafting Work
+
+Build a compact internal note before writing copy:
+
+- buyer
+- pain
+- product
+- mechanism
+- proof boundary
+- source-use rule
+- CTA
+
+Draft three distinct first-message options:
+
+- signal-led
+- product/mechanism-led
+- proof/credibility-led
+
+Then combine the strongest opener, bridge, product line, mechanism line, proof
+treatment, and CTA into one reusable first-message template. The final template
+must work across the imported source list while allowing row-specific grounding
+through supported `{{...}}` tokens.
+
+## Final Validation Gate
+
+After drafting and revising the candidate, and before returning `ready`, load:
+
+`get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`
+
+Use it as the final internal validation gate for the recommendation. If it
+cannot load or the candidate fails the gate, return `blocked` or
+`retry-needed`.
 
 ## Owned Output
 
-Return the following to the parent thread:
+Return Markdown, not JSON.
 
-- proposed first-message template using supported `{{...}}` tokens
-- token fill rules and fallbacks
-- one rendered good-fill sample for a plausible passing campaign-table row
-- message-draft runtime status: `ready`, `blocked`, `retry-needed`, or `stale`
-- approve-or-revise recommendation
-- validation status only: `passed`, `revised-then-passed`, or `blocked`
-- output timestamp/hash and any blocked/retry detail
+Return only these labeled fields to the parent thread:
 
-Do not return or render `renderedFallbackSample`, `concerns`, or a full
-`qaReceipt` in the normal happy path. Validation is an internal gate; summarize
-only if blocked or retry-needed.
+- `templateRecommendation`
+- `tokenFillRules`
+- `renderedGoodSample`
+- `status`
+- `basisStatus`
+- `basisToken`
+- `approveOrReviseRecommendation`
+- `validationStatus`
+- `outputAt`
+- `outputHash`
+- blocked/retry detail only when applicable
 
-Do not write local markdown/json artifacts in normal live campaign runs. Return
-the recommendation directly to the parent thread. Emit debug artifacts only when
-the parent explicitly asks for debug/UAT output.
+Do not return broad row counts, full row-id lists, QA receipts, concerns, or
+fallback samples on the normal happy path.
 
 When reporting branch runtime proof, use this shape under
 `watchNarration.workerDetails.messageDraftBuilder`:
@@ -115,27 +155,28 @@ When reporting branch runtime proof, use this shape under
 - `basisToken` and `basis`
 - optional `messageDraftOutputRef`, `messageDraftOutput`, and `error`
 
-Do not tell the UI to show Message Drafting as running unless this proof
+Do not tell the UI to show Message Draft Builder as running unless this proof
 exists and points at the current non-empty campaign-table execution slice.
 
 ## Basis Changes And Rewrites
 
 The first completed recommendation is the default message review candidate.
-Do not automatically retry or regenerate only because filters were saved, Filter
-Leads completed, enrichment cells populated, or more row data became available
-after this branch started.
-
-Treat later filter/enrichment data as optional rewrite context. If campaign id
-and `workflowTableId` still match, keep the initial recommendation usable and
-report `status: ready` with `basisStatus: "usable_initial"` or
-`"enriched_rewrite_available"`. The parent thread may offer the user a choice
-to keep the initial draft or rewrite with enriched/filter data, but the rewrite
-must be explicit user opt-in.
+Do not automatically retry or regenerate only because filters were saved, Lead
+Fit Builder finished, rubrics were saved, Filter Leads completed, enrichment
+cells populated, or more row data became available after this branch started.
+
+Treat later filter/enrichment data as optional rewrite context. If campaign id,
+selected source, `selectedLeadListId`, `workflowTableId`, and the
+initial campaign-table execution slice rows still match, keep the initial
+recommendation usable and report `status: ready` with `basisStatus:
+"usable_initial"` or `"enriched_rewrite_available"`. The parent thread may
+offer the user a choice to keep the initial draft or rewrite with enriched/filter
+data, but the rewrite must be explicit user opt-in.
 
 Retry or regenerate without asking only when the initial recommendation is
 missing, failed, structurally invalid, unsafe, or mismatched on campaign id,
-`workflowTableId`, or provided sample rows. Filter/rubric/enrichment basis drift
-alone is not a stale blocker.
+selected source, `selectedLeadListId`, `workflowTableId`, or execution-slice
+rows. Filter/rubric/enrichment basis drift alone is not a stale blocker.
 
 ## User Revision Feedback And QA
 
@@ -143,9 +184,9 @@ If the parent sends user feedback, a QA request, or a rewrite request about the
 template before `approve-message`, treat it as Message Drafting work, not a
 campaign write. Use the current `messageDraftRecommendation`, basis token/hash,
 campaign/table basis, and latest user feedback as inputs. Load or reuse the full
-`generate-messages` contract, all referenced assets, and
-`create-campaign-v2-validation`, then return a revised or QA-only recommendation
-with:
+`generate-messages` contract, all required assets, and
+`create-campaign-v2-validation`, then return a revised or QA-only
+recommendation with:
 
 - revised proposed template
 - what changed and why
@@ -155,7 +196,6 @@ with:
 - updated output timestamp/hash and basis token
 
 Do not return a full QA receipt unless the result is blocked or retry-needed.
-
 Keep the revision grounded in the same source/list/table rows unless the parent
 explicitly supplies a new selected list or review slice. Do not call
 `update_campaign_brief`, do not persist the template, and do not approve your
@@ -169,65 +209,55 @@ own revision. The parent renders the revised template and waits for
 - Do not call `update_campaign_brief`; the main thread writes the approved
   template after user approval.
 - Do not overwrite an existing approved message/template.
-- Do not use unsupported reply-rate, meeting-rate, ROI, revenue, or
-  customer-logo claims.
+- Do not use unsupported reply-rate, meeting-rate, ROI, revenue, exact
+  pipeline-lift, named-customer, or customer-logo claims.
 - Do not use internal tokens such as `{{profile_signal}}` in customer-facing
   copy.
 - Do not put bracketed instructions in the message body, such as `[ROW_BRIDGE]`,
   `[insert]`, or `[generated]`.
-- Engagement-source personalization is a special case, not the default opener.
-  Do not write `saw you {{engagement_context}} on {{post_context}}`, `saw you
-reacted to`, `saw you engaging with`, or equivalent source-citation copy as a
-  default hook. For LinkedIn-post-sourced campaigns, you may reference the
-  source when it explains why the note exists, but keep it topic-level, not
-  activity-log-level. Good: `saw you in a few conversations around [topic], so
-hope this is relevant`, `saw you in a few conversations about [topic], so
-may be off, but this seemed relevant`, `saw you might be interested in [topic],
-so hope this is relevant`, `hope this is relevant if [topic] is on your plate`,
-or `saw you raise your hand for [topic], so figured this was (hopefully) worth sending`.
-The cheekier `saw you raise your hand for [topic] (creepy to reach out based
-on that, i know) - but this felt too on the nose to ignore` version is also
-allowed when the sender's voice can carry it. Bad: `you commented on...`, `you reacted
-to...`, `saw you engaging with...`, `your LinkedIn activity...`, `you might
-not remember the thread...`, or `found you through [source] and your role
-looked close...`. Otherwise omit the engagement signal and use role/company/problem context.
-- Do not use a PS to defend the source. Lines like `p.s. if the source thread
-  was just casual reading, ignore me` or `only reaching out where the role and
-  topic looked close` are blocked. If the source is too weak, omit it.
+- Use post engagement only as a warm opener when it makes the note feel more
+  earned. Do not infer buyer intent from a reaction or overpersonalize from a
+  like.
+- For third-party post sources, keep source language topic-level and
+  low-certainty, such as `found you in a thread about [topic], so may be off,
+  but this seemed relevant`.
+- Sender-owned post sources are different: if the source post was authored by
+  the sender/client and the row proves a reaction/comment, a light first-person
+  acknowledgment is allowed, but it must be followed by a soft
+  relevance bridge before broad problem or product copy. Use a bridge like
+  `figured this might be relevant if LinkedIn is becoming more of a GTM
+  channel for [company]` before any broader `a lot of B2B teams...` claim. Do
+  not jump straight from `appreciate you showing some love...` to
+  `a lot of B2B teams...` or `most teams...`.
+- Every line must make the next
+  line feel earned: source/post signal -> relevance bridge -> product/problem
+  -> next step. If adjacent lines could be swapped, deleted, or joined with
+  `anyway` without changing the meaning, rewrite the bridge or cut the orphan
+  line.
+- Do not use a PS to defend the source. If the source is too weak, omit it.
 - Do not assert fit from title/company. `Your [role] role at [company] looked
-  close to this problem` is blocked. Keep the apologetic uncertainty instead:
-  `may be off, but if [workflow] is anywhere near your lane...`.
-- Low-pressure relevance opt-outs are allowed when they do not defend the
-  source: `p.s. if this is nowhere near your outbound workflow, ignore me`.
-- Do not use `Caught` as opener language. It reads unnatural in LinkedIn
-  outreach.
+  close to this problem` is blocked.
+- Do not use `Caught` as opener language.
 - Do not describe the sender in third person inside the outbound message.
-  Lines like `p.s. Saju's angle is...`, `Christian's angle is...`, or
-  `[sender]'s approach is...` are internal notes leaking into copy. If the point
-  matters, write it in the sender's voice: `p.s. we usually pair the build with
-enablement`, or omit it.
 - The selected winner is one first outbound send only. No post-accept DM,
   follow-up, cadence branch, sequence copy, or launch copy.
 
 ## Final Response
 
-Return a concise status with:
+Return a concise review-ready recommendation with the labeled fields above.
+
+The customer-facing approval packet should include only the proposed template
+and one rendered good-fill sample. Keep token rules, fallback logic, and
+bad-fill avoidance notes available for internal persistence, but do not print
+fallback samples or QA receipts in the default chat approval packet.
 
-- prompt basis loaded: `generate-messages`
-- validation prompt loaded: `create-campaign-v2-validation`
-- live campaign basis used
-- proposed template
-- token fill rules/fallbacks
-- one rendered passing-row sample
-- whether final template review is ready or needs revision
+Use fenced `text` blocks only for copy the user can approve:
 
-When the parent will show the recommendation in chat, keep the customer-facing
-message review lightweight. Format only the approval target and one strong
-good-fill example as Markdown with distinct copy blocks. Keep validation notes,
-bad-fill avoidance notes, and QA details internal unless blocked; do not print
-them in the default chat approval packet.
+Use a table for token rules.
 
 ````markdown
+templateRecommendation:
+
 ## Message Template
 
 **Subject**
@@ -242,6 +272,13 @@ them in the default chat approval packet.
 {{tokenized_message_body}}
 ```
 
+tokenFillRules:
+
+| Token | Source | Allowed transformation | Fallback | Blocked fills |
+| --- | --- | --- | --- | --- |
+
+renderedGoodSample:
+
 ## Rendered Example
 
 Good token fill:
@@ -253,7 +290,12 @@ Hey First,
 
 ...
 ```
-````
 
-Use a table for token rules. Keep explanations outside the fenced `text` blocks
-so the user can quickly see exactly what copy is being approved.
+status: ready
+basisStatus: usable_initial
+basisToken: ...
+approveOrReviseRecommendation: approve
+validationStatus: passed
+outputAt: ...
+outputHash: ...
+````

package/dist/engage-memory.js

@@ -8,11 +8,6 @@ function resolveConfigsDir() {
     if (process.env.SELLABLE_CONFIGS_DIR) {
         candidates.push(path.resolve(process.env.SELLABLE_CONFIGS_DIR));
     }
-    // Same resolution strategy as skills.ts
-    if (process.argv[1]) {
-        candidates.push(path.resolve(path.dirname(process.argv[1]), "../../.sellable/configs"));
-    }
-    candidates.push(path.resolve(process.cwd(), ".sellable/configs"));
     candidates.push(path.resolve(os.homedir(), ".sellable/configs"));
     for (const candidate of candidates) {
         if (fs.existsSync(candidate)) {

package/dist/identity-memory.js

@@ -20,10 +20,6 @@ export function resolveIdentityConfigsDir() {
     if (process.env.SELLABLE_CONFIGS_DIR) {
         candidates.push(path.resolve(process.env.SELLABLE_CONFIGS_DIR));
     }
-    if (process.argv[1]) {
-        candidates.push(path.resolve(path.dirname(process.argv[1]), "../../.sellable/configs"));
-    }
-    candidates.push(path.resolve(process.cwd(), ".sellable/configs"));
     candidates.push(path.resolve(os.homedir(), ".sellable/configs"));
     for (const candidate of candidates) {
         if (fs.existsSync(candidate)) {

package/dist/tools/engage-memory.js

@@ -2,7 +2,7 @@ import { copySenderConfig, getEngageMemory, migrateFlatConfigs, recordProvenSear
 export const engageMemoryToolDefinitions = [
     {
         name: "get_engage_memory",
-        description: "Load backward-compatible engage memory from .sellable/configs/: style guide, proven search keywords, tracked people, plus optional core identity/company memory. All data lives in readable markdown files the user can also edit directly. When senderId is provided, reads compatibility overrides from senders/{senderId}/ with flat-path fallback.",
+        description: "Load backward-compatible engage memory from ~/.sellable/configs/: style guide, proven search keywords, tracked people, plus optional core identity/company memory. All data lives in readable markdown files the user can also edit directly. When senderId is provided, reads compatibility overrides from senders/{senderId}/ with flat-path fallback.",
         inputSchema: {
             type: "object",
             properties: {
@@ -17,7 +17,7 @@ export const engageMemoryToolDefinitions = [
     },
     {
         name: "set_engage_style_guide",
-        description: "Write the user's commenting style guide. When senderId is provided, writes to .sellable/configs/senders/{senderId}/styleguide-core.md. Otherwise writes to .sellable/configs/writing/styleguide-core.md.",
+        description: "Write the user's commenting style guide. When senderId is provided, writes to ~/.sellable/configs/senders/{senderId}/styleguide-core.md. Otherwise writes to ~/.sellable/configs/writing/styleguide-core.md.",
         inputSchema: {
             type: "object",
             properties: {

package/dist/tools/leads.js

@@ -1365,7 +1365,7 @@ export const leadToolDefinitions = [
                 },
                 limit: {
                     type: "number",
-                    description: "Max posts (default 25, max 50). Used for profile search.",
+                    description: "Max posts (default 25, max 50). Used for profile or company search.",
                 },
                 headlineICPCriteria: {
                     type: "array",
@@ -3177,7 +3177,9 @@ export async function selectPromisingPosts(input) {
     const { campaignOfferId, selections, headlineICPCriteria, selectionMode, mode, scrapePlanMode, targetEngagerCount, maxPostsToScrape, } = input;
     const effectiveMode = selectionMode ?? mode ?? "replace";
     const effectiveScrapePlanMode = scrapePlanMode ??
-        (targetEngagerCount || maxPostsToScrape ? "capacity-target" : "all-selected");
+        (targetEngagerCount || maxPostsToScrape
+            ? "capacity-target"
+            : "all-selected");
     if (selections.length > MAX_SIGNAL_DISCOVERY_POSTS) {
         return {
             success: false,
@@ -3249,7 +3251,9 @@ export async function selectPromisingPosts(input) {
         }
         const recommendation = buildSignalDiscoverySourceRecommendation({
             selectedPosts: Array.from(selectedByUrl.values()),
-            targetEngagerCount: effectiveScrapePlanMode === "capacity-target" ? targetEngagerCount : null,
+            targetEngagerCount: effectiveScrapePlanMode === "capacity-target"
+                ? targetEngagerCount
+                : null,
             maxPostsToScrape: effectiveScrapePlanMode === "capacity-target" ? maxPostsToScrape : null,
         });
         sourceRecommendation = recommendation.message;

package/dist/tools/prompts.js

@@ -5,8 +5,8 @@ import { markCreateCampaignPromptLoaded, markResearchPromptLoaded, markSenderRes
 // Chunk size sits below Claude Code's max-token cap on tool results
 // (empirically around ~50k chars — fetch_linkedin_profile breached at
 // 53,295 chars, which forced a python3 chunked-read fallback). 48k gives
-// just-enough headroom under the cap. With Phase 125's split of
-// create-campaign-v2 into entry + generate-message + tail subskills,
+// just-enough headroom under the cap. With the campaign workflow split into
+// entry + generate-message + tail subskills,
 // every individual subskill (including auto-appended SOUL.md) fits in
 // a single 48k chunk → the agent reads the entry prompt in 1 round
 // trip instead of 3-5, dropping first-message latency from ~9-15s to
@@ -72,7 +72,7 @@ export const promptToolDefinitions = [
                 subskillName: {
                     type: "string",
                     enum: ALLOWED_SUBSKILL_PROMPT_NAMES,
-                    description: "Subskill prompt name. Use generate-messages for message drafting.",
+                    description: "Subskill prompt name. Use generate-messages for message drafting and row-message generation.",
                 },
                 offset: {
                     type: "number",
@@ -174,7 +174,7 @@ export const promptToolDefinitions = [
                 depth: {
                     type: "string",
                     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).",
+                    description: "Research depth used: minimal-verification (proofDigest already had strong signals), deep-proof (extra search agents spawned), or parallel-batch (default single 5-call parallel batch with fetch_linkedin_profile + fetch_company + 3x WebSearch).",
                 },
                 proofItemsFound: {
                     type: "number",
@@ -325,17 +325,23 @@ export function getPostFindLeadsScoutRegistry() {
                 "startedAt",
                 "updatedAt",
                 "basisToken",
+                "basis.campaignId",
+                "basis.selectedLeadListId",
                 "basis.workflowTableId",
-                "basis.sampleRowIds",
+                "basis.currentExecutionSliceNonEmpty",
+                "basis.sampleRows or basis.sampleRowSummary",
             ],
-            promptRequired: 'Load current campaign brief/table state through scoped tools, then get_subskill_prompt({ subskillName: "generate-messages" }) for all chunks. Load every asset named in the generate-messages Reference Asset Loading pack through get_subskill_asset. Before returning, load get_subskill_prompt({ subskillName: "create-campaign-v2-validation" }) and use it as the final internal message-validation gate. Do not use shell/local filesystem reads, repo paths, plugin-cache paths, or /Users paths for message references. If required prompts/assets cannot be loaded through MCP tools, return blocked/retry-needed instead of drafting from memory.',
+            promptRequired: 'Load current campaign brief/table state through scoped tools. Before drafting: get_subskill_prompt({ subskillName: "generate-messages" }); every required message asset named by generate-messages Mode 0 through get_subskill_asset, including gold-standard-message-examples.md, gold-standard-message-patterns.md, ai-tells.md, sellable-cleanup-rules.md, ai-native-tokens.md, and token-fill-examples.md. Do not use shell/local filesystem reads, repo paths, plugin-cache paths, /Users paths, local artifacts, alternate prompts, or examples-only prompts. After candidate generation/revision and before returning ready: get_subskill_prompt({ subskillName: "create-campaign-v2-validation" }) as the final internal validation gate. If required prompts/assets cannot load through MCP tools, return blocked/retry-needed instead of drafting from memory.',
             basisFields: [
                 "campaignId",
+                "workspace when known",
+                "campaignName when useful",
+                "selectedLeadListId",
                 "workflowTableId",
-                "concise brief summary",
-                "concise source summary/source-use rule",
-                "3-5 sample workflow-table rows",
-                "optional selectedLeadListId and filter choice",
+                "filter choice",
+                "concise brief summary: offer, buyer, safe proof, blocked claims",
+                "concise source summary and source-use rule",
+                "3-5 sample campaign-table rows with name, title, company when available, and signal",
             ],
             messageDraftOutputFields: [
                 "templateRecommendation",
@@ -351,12 +357,12 @@ export function getPostFindLeadsScoutRegistry() {
                 "outputHash",
                 "error or retry detail",
             ],
-            reusePolicy: "The first completed Message Drafting recommendation remains the default review candidate. Later filters, Filter Leads, enrichment, or rubric completion may make an enriched rewrite available, but does not automatically retry or replace the initial draft unless campaign/table/sample identity mismatches or the initial output failed. User copy feedback before approve-message is an explicit Message Drafting revision and must be routed back through the message branch with the current recommendation and basis.",
+            reusePolicy: "The first completed Message Drafting recommendation remains the default review candidate. Later Lead Fit Builder, Filter Leads, enrichment, or rubric completion may make an enriched rewrite available, but does not automatically retry or replace the initial draft unless campaign/brief/source/list/table/execution-slice identity mismatches or the initial output failed. User copy feedback before approve-message is an explicit Message Drafting revision and must be routed back through the message branch with the current recommendation and basis.",
         },
         usage: {
             codex: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not spawn anything before that question. After the answer, launch only Message Drafting whenever Codex agent-launch policy is satisfied. If filters are chosen, the parent stays on Filter Rules and drafts/saves rubrics with MCP tools while Message Drafting runs in the background. If filters are skipped, move to Messages/message review after Message Drafting is ready. Treat YOLO/autonomous mode as campaign-scoped permission for this single post-import worker. If the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once before loading the long message prompt in the parent. If permission is granted and the named Message Drafting custom agent is unavailable, spawn a generic gpt-5.5 xhigh Message Drafting background agent with the same lean campaign/table basis.",
             claude: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not invoke any Task/Agent before that question. After the answer, invoke only Message Drafting. If filters are chosen, parent drafts/saves rubrics with MCP tools while Message Drafting runs, asks filter approval, then joins Message Drafting. If filters are skipped, invoke only Message Drafting and move to Messages/message review.",
-            parentThreadRule: 'The only normal background worker is Message Drafting; source work and filter work stay in the parent thread with MCP tools. After the filter-choice answer, launch post-find-leads-message-scout only. If filters are chosen, the parent thread remains the filter writer: keep the browser on Filter Rules, load the filter reference, draft/save rubrics through MCP tools, ask filter approval, then move to Filter Leads while waiting for Message Drafting if needed. Do not move into message review, queue cells, or call update_campaign_brief until saved filters are approved when filters are enabled and messageDraftRecommendation is ready. If filters are skipped, launch only Message Drafting. In Codex, YOLO/autonomous mode counts as campaign-scoped permission for this single post-import worker; if the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once for permission before loading the long message prompt in the parent. If Message Drafting is allowed but the named worker is unavailable, use a generic gpt-5.5 xhigh Message Drafting background agent. Do not silently fall back to parent-thread message drafting. The Message Drafting handoff must be lean: campaignId, workflowTableId, brief summary, source summary/source-use rule, and 3-5 sample workflow-table rows with rowId/name/title/company/signal; optional campaignName, selectedLeadListId, and filter choice are allowed. Do not paste copied row counts, brief hashes, review-batch hashes, full reviewBatchRowIds, broad row data, or local debug artifacts into the message spawn prompt. The message branch must load current campaign brief/context, provided sample rows, the full generate-messages prompt, every referenced asset through get_subskill_asset, and before returning get_subskill_prompt({ subskillName: "create-campaign-v2-validation" }) for the internal validation gate. Local markdown/json files are not normal-path inputs. Message reference assets must be loaded with get_subskill_asset from the installed MCP package; do not use shell/local filesystem reads, repo paths, plugin-cache paths, or /Users paths to satisfy message references. The filter-choice question is the first post-import user gate; do not load this registry or filter references before it. Message drafting starts after the filter-choice answer and must reject mismatched workflowTableId/campaign/workspace input. Do not use any alternate or examples-only message prompt. User copy feedback, message QA, or rewrite requests before approve-message must be routed back to Message Drafting with the current recommendation, lean campaign/table basis, and latest user text; the parent must not rewrite or QA the template from memory and must not call update_campaign_brief before approve-message. The worker validates internally and returns only templateRecommendation, tokenFillRules, renderedGoodSample, status, approveOrReviseRecommendation, validationStatus, outputAt, outputHash, and blocked/retry detail. Do not render renderedFallbackSample, concerns, or a qaReceipt on the normal happy path. On the filter path, the parent thread keeps the browser on Filter Rules after save_rubrics so the user can approve the saved criteria; only then move to Filter Leads, show `Filters saved + waiting for message approval`, and wait there for message approval. Enrichment, filtering, Generate Message cells, sender setup, sequence attach, and launch wait for template approval on the Use Template path. On the skip path, move to Messages/message review and wait for message approval before enrichment or Settings. Do not render message review from checklist or shortcut instructions; message review requires a messageDraftRecommendation whose basis proves the generate-messages prompt, assets, and validation prompt ran for the current campaign/table execution slice. Do not automatically rerun Message Drafting after filters/enrichment finish; show the initial draft by default and offer an enriched rewrite only with explicit user opt-in.',
+            parentThreadRule: 'Named agents are optional acceleration, but message drafting is not optional. The only normal background worker is Message Drafting. YOLO/autonomous mode counts as campaign-scoped permission for this single post-import worker. If a named agent is unavailable after permission, use a generic gpt-5.5 xhigh Message Drafting background agent. source work and filter work stay in the parent thread with MCP tools. If post-find-leads-message-scout is available, run it as the background Message Draft Builder after the filter-choice answer. If it is absent, do not customer-surface install status. Do not silently fall back to parent-thread message drafting; the main thread must execute the same message branch from CampaignOffer state, selected source state, workflowTableId, and initial campaign-table execution slice rows. The Message Drafting handoff must be lean. Do not paste copied row counts, brief hashes, review-batch hashes, full reviewBatchRowIds, broad row data, or local debug artifacts into the spawn prompt. Local markdown/json files are not normal-path inputs. The filter-choice question is the first post-import user gate; do not load post-lead registries or filter references before it. Message drafting starts after the filter-choice answer, must load get_subskill_prompt({ subskillName: "generate-messages" }), and must load every required message asset named by generate-messages Mode 0 through get_subskill_asset before drafting. Reference Asset Loading means loading the required pre-draft reference pack before drafting; return blocked/retry-needed if required assets cannot be loaded; load ai-tells.md because it is never optional. The branch loads the full generate-messages prompt and every referenced asset through get_subskill_asset. After generating/revising the candidate and before returning ready, must load get_subskill_prompt({ subskillName: "create-campaign-v2-validation" }) as the final internal validation gate, must read live campaign table state through scoped MCP/product tools, and must reject mismatched selectedLeadListId/workflowTableId/campaign/workspace input. Do not use any alternate, local-artifact, or examples-only message prompt. User copy feedback, message QA, or rewrite requests before approve-message must be routed back to Message Drafting with the current recommendation, lean campaign/table basis, and latest user text; the parent must not rewrite or QA the template from memory and must not call update_campaign_brief before approve-message. The worker validates internally and returns only templateRecommendation, tokenFillRules, renderedGoodSample, status, approveOrReviseRecommendation, validationStatus, outputAt, outputHash, and blocked/retry detail. Do not render renderedFallbackSample, risk notes, or a qaReceipt on the normal happy path. On the filter path, save_rubrics keeps the browser on Filter Rules after save_rubrics so the user can approve the saved criteria; only then move to Filter Leads, show `Filters saved + waiting for message approval`, and wait there for message approval. Enrichment, filtering, Generate Message cells, sender setup, sequence attach, and launch wait for template approval on the Use Template path. On the skip path, move to Messages/message review and wait for message approval before enrichment or Settings. Do not render message review from checklist or shortcut instructions; message review requires a messageDraftRecommendation whose basis proves the generate-messages prompt, required message assets, and validation gate ran for the current campaign/table execution slice. Do not automatically rerun Message Drafting after filters/enrichment finish; show the initial draft by default and offer an enriched rewrite only with explicit user opt-in. Handoff and recommendation output are Markdown with labeled fields, not raw JSON.',
         },
     };
 }