@sellable/mcp 0.1.450 → 0.1.452

package/dist/tools/setup-evergreen-campaigns.js

@@ -6,7 +6,7 @@ async function postSetupEvergreenCampaigns(body) {
 export const setupEvergreenCampaignsToolDefinitions = [
     {
         name: "setup_evergreen_campaigns",
-        description: "Evergreen campaign setup plan/verify command. Use plan mode first to inspect exact workspace/sender/campaign/table/source state and receive immutable lane packets. `selectedSenderIds` is a legacy shorthand for both scopes; prefer `postEngagerSenderIds` for the Post Engagers sender scope and `sharedSenderIds` for the shared lane sender scope when they differ. If a protected existing Post Engagers campaign must stay unchanged and the operator requested only shared lane execution, pass postEngagerSenderIds:[] and sharedSenderIds; do not include the protected active Post Engagers lane as a reuse packet because it can make the yolo plan non-autoExecutable. The command plans one Post Engagers lane per post-engager sender plus shared Signal Discovery and Shared Cold Fallback lanes for the shared sender set. yolo is only a parent-skill auto-execution hint for safe lane packets; pass yolo only in plan mode and never include yolo on mode:\"verify\" calls. This backend command remains read-only in plan mode and verifies receipts in verify mode. Package-backed prompt authority: the installed public wrapper can be the local Codex skill entrypoint, but lane workers must use get_subskill_prompt and get_subskill_asset for nested `$sellable:create-campaign`, create-campaign-v2, generate-messages, validation, and assets; nested filesystem prompt fallback is a failed UAT. Use mcp__sellable only for workspace selection and product mutations/readbacks. Do not use mcp__sellable_admin, direct DB, Prisma, SQL, built-in web search, browser search, web.run, or any external browsing/search tool as execution or research proof; if Sellable MCP research tools are insufficient, write a blocked receipt instead of browsing externally. Worker-local replans are read-only drift checks and must preserve the exact parent sender scopes, including postEngagerSenderIds:[] when intentionally empty and the exact sharedSenderIds array; if scope, planRevision, actionId, or laneKey drifts, stop with blocked:worker_plan_scope_drift before mutation. Each lane packet includes workerDispatch with preferredRuntime, runtimeFallbackOrder, acceptedRuntimes, rejectedRuntimes, requiresVisibleThreadOrDurableReceipt, receiptArtifactHint, receiptRunId, and receiptMustBeWrittenAfter; pre-existing receipts at old deterministic paths are stale and must not be used, so stop with blocked:stale_receipt_artifact if the receipt was not freshly written for the current receiptRunId. `multi_agent_v1.spawn_agent`/opaque spawn_agent is not accepted for mutating command proof unless the parent has visible thread or durable receipt proof. In local Codex, default to `workerDispatch.preferredRuntime` (`visible-codex-app-thread`): discover Codex app thread tools if needed, then call `codex_app.list_projects` and `codex_app.create_thread` with a local project target; do not create a worktree for lane execution. If Codex app thread tools are unavailable but local Codex CLI is available, use durable streaming workers with `codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -` and include preferredRuntimeAttempt plus fallbackReason in createCampaignWorkflowReceipt; approval, sandbox, and reasoning-effort config flags must appear before `exec`, and current customer CLI installs reject `codex exec --ask-for-approval never` and `codex exec -a never`. Do not rely on default model or default reasoning effort: copy the parent model such as `gpt-5.5` into `-m` and always pass `-c model_reasoning_effort=xhigh`; a child worker that reports GPT 5.5 with high reasoning is a launcher bug to relaunch before mutation, not a user-continue path. Plan responses include approvalSummary; render approvalSummary when asking for bounded delegated approval because it explicitly lists campaignsToCreate, campaignsToUpdate, campaignsToVerifyOnly, campaignsLeftUntouched, attachedSenders, selectedActionIds, allowedSideEffects, forbiddenSideEffects, blockers, and approvalQuestion. When safe-yolo needs normal setup work, the parent skill may ask for bounded delegated approval: one approval over the current planRevision, selected action ids, caps, allowed side-effect classes, and stop conditions lets lane workers execute without per-substep approval while staying inside that packet. In exec/automation mode, do not call request_user_input; if yolo plan autoExecutable:false and no interactive approval can be received, stop with blocked:bounded_approval_unavailable_in_exec_mode before any mutation. Lane workers must explicitly load and use the installed `$sellable:create-campaign` wrapper as the nested workflow entrypoint, then load `create-campaign-v2` and `create-campaign-v2/core/flow.v2.json`; they must execute creation, source import, create-campaign workflow steps, generate-messages, sequence attachment, pause_campaign review-state transition when the current table is still DRAFT, and review readiness through that existing create-campaign workflow/subskills, then return receipts here for verification. Customer-visible verify receipts must set status:'succeeded' or status:'completed'; status:'passed', status:'pass', and status:'passed_with_warnings' are rejected as primary success statuses. Exception: a Post Engagers lane may write status:'blocked' with blocker:'post_engagers_no_sender_posts', 'post_engagers_no_recent_sender_posts', 'post_engagers_no_sender_owned_posts', or 'post_engagers_source_author_mismatch' when Sellable MCP readback proves no usable sender-authored posts/source exists; verify returns these as acceptedLaneBlockers so the parent can report the no-op instead of retrying invalid source repair. Any other blocked receipt, including model-quality/preflight or worker model availability blockers, is not a goal-complete success condition and must not let the parent report evergreen completion. Receipts must include createCampaignStepReceipt with setupPlanCall, createCampaignWorkflowReceipt, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall nested inside createCampaignStepReceipt; top-level-only copies of those objects are not enough and are not promoted by verify. setupPlanCall must use canonical keys: planRevision, actionId, laneKey, workspaceId, senderIds, campaignId, tableId, createIntent. Do not use laneActionId, lanePacketActionId, delegatedPlanRevision, delegatedActionId, or requestedCall text as a substitute for those canonical fields. createCampaignWorkflowReceipt must include skillCommand:'$sellable:create-campaign', skillName:'create-campaign', wrapperSkillLoaded:true, workflowPromptName:'create-campaign-v2', workflowPromptLoadedToHasMoreFalse:true, workflowAssetPath:'create-campaign-v2/core/flow.v2.json', workflowAssetLoaded:true, workerRuntime, workerThreadId or receiptArtifactPath, durableReceiptWritten when using a receipt file, and notAdHoc:true; CLI durable fallback runtimes must also include preferredRuntimeAttempt for visible-codex-app-thread and fallbackReason. messageDraftingReceipt must use exactly statusSource:'branch' or statusSource:'packaged-generate-messages-worker'; descriptive aliases such as statusSource:'package-readback-local-thread' are rejected. It must include proof that generate-messages was loaded, start_campaign_message_preparation/get_campaign_message_preparation_status ran when the packaged worker path is used, validationResult:'passed', a passed qualityReview, and at least 3 concrete sampleMessages with rowId, generatedMessageText, verdict, and issues; Do not substitute `message` for `generatedMessageText`; Do not substitute `passVerdict` for `verdict`. Before writing durable receipts, run a receipt self-check: top-level `planRevision`, `actionId`, `laneKey`, `laneType`, `workspaceId`, and `senderIds` must exist; if the self-check fails, fix the receipt before ending. Use start_campaign_message_preparation with approvalMode:\"mark_ready\" only for evergreen setup. Never call `start_campaign_message_preparation` with `approvalMode:\"approve\"`; approve exactly one semantic Approved cell through select_campaign_cells/update_cell and final proof must show approvedGeneratedMessageCount exactly 1. Shared Cold Fallback samples with a standalone name followed by 'Hey there' are rejected. This command does not launch campaigns, does not schedule sends, does not assign scheduler-owned send fields, does not raw-write campaign status, does not archive/delete cleanup targets, and does not spend paid credits.",
+        description: "Evergreen campaign setup plan/verify command. Use plan mode first to inspect exact workspace/sender/campaign/table/source state and receive immutable lane packets. `selectedSenderIds` is a legacy shorthand for both scopes; prefer `postEngagerSenderIds` for the Post Engagers sender scope and `sharedSenderIds` for the shared lane sender scope when they differ. If a protected existing Post Engagers campaign must stay unchanged and the operator requested only shared lane execution, pass postEngagerSenderIds:[] and sharedSenderIds; do not include the protected active Post Engagers lane as a reuse packet because it can make the yolo plan non-autoExecutable. The command plans one Post Engagers lane per post-engager sender plus shared Signal Discovery and Shared Cold Fallback lanes for the shared sender set. yolo is only a parent-skill auto-execution hint for safe lane packets; pass yolo only in plan mode and never include yolo on mode:\"verify\" calls. This backend command remains read-only in plan mode and verifies receipts in verify mode. Package-backed prompt authority: the installed public wrapper can be the local Codex skill entrypoint, but lane workers must use get_subskill_prompt and get_subskill_asset for nested `$sellable:create-campaign`, create-campaign-v2, generate-messages, validation, and assets; nested filesystem prompt fallback is a failed UAT. Use mcp__sellable only for workspace selection and product mutations/readbacks. Do not use mcp__sellable_admin, direct DB, Prisma, SQL, built-in web search, browser search, web.run, or any external browsing/search tool as execution or research proof; if Sellable MCP research tools are insufficient, write a blocked receipt instead of browsing externally. Worker-local replans are read-only drift checks and must preserve the exact parent sender scopes, including postEngagerSenderIds:[] when intentionally empty and the exact sharedSenderIds array; if scope, planRevision, actionId, or laneKey drifts, stop with blocked:worker_plan_scope_drift before mutation. Each lane packet includes workerDispatch with acceptedRuntimes, rejectedRuntimes, requiresVisibleThreadOrDurableReceipt, receiptArtifactHint, receiptRunId, and receiptMustBeWrittenAfter; pre-existing receipts at old deterministic paths are stale and must not be used, so stop with blocked:stale_receipt_artifact if the receipt was not freshly written for the current receiptRunId. `multi_agent_v1.spawn_agent`/opaque spawn_agent is not accepted for mutating command proof unless the parent has visible thread or durable receipt proof. In local Codex, prefer `codex_app.list_projects` then `codex_app.create_thread` with a local project target; do not create a worktree for lane execution. If Codex app thread tools are unavailable but local Codex CLI is available, use durable streaming workers with `codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`; approval, sandbox, and reasoning-effort config flags must appear before `exec`, and current customer CLI installs reject `codex exec --ask-for-approval never` and `codex exec -a never`. Do not rely on default model or default reasoning effort: copy the parent model such as `gpt-5.5` into `-m` and always pass `-c model_reasoning_effort=xhigh`; a child worker that reports GPT 5.5 with high reasoning is a launcher bug to relaunch before mutation, not a user-continue path. Plan responses include approvalSummary; render approvalSummary when asking for bounded delegated approval because it explicitly lists campaignsToCreate, campaignsToUpdate, campaignsToVerifyOnly, campaignsLeftUntouched, attachedSenders, selectedActionIds, allowedSideEffects, forbiddenSideEffects, blockers, and approvalQuestion. When safe-yolo needs normal setup work, the parent skill may ask for bounded delegated approval: one approval over the current planRevision, selected action ids, caps, allowed side-effect classes, and stop conditions lets lane workers execute without per-substep approval while staying inside that packet. In exec/automation mode, do not call request_user_input; if yolo plan autoExecutable:false and no interactive approval can be received, stop with blocked:bounded_approval_unavailable_in_exec_mode before any mutation. Lane workers must explicitly load and use the installed `$sellable:create-campaign` wrapper as the nested workflow entrypoint, then load `create-campaign-v2` and `create-campaign-v2/core/flow.v2.json`; they must execute creation, source import, create-campaign workflow steps, generate-messages, sequence attachment, pause_campaign review-state transition when the current table is still DRAFT, and review readiness through that existing create-campaign workflow/subskills, then return receipts here for verification. Customer-visible verify receipts must set status:'succeeded' or status:'completed'; status:'passed', status:'pass', and status:'passed_with_warnings' are rejected as primary success statuses. Exception: a Post Engagers lane may write status:'blocked' with blocker:'post_engagers_no_sender_posts', 'post_engagers_no_recent_sender_posts', 'post_engagers_no_sender_owned_posts', or 'post_engagers_source_author_mismatch' when Sellable MCP readback proves no usable sender-authored posts/source exists; verify returns these as acceptedLaneBlockers so the parent can report the no-op instead of retrying invalid source repair. Any other blocked receipt, including model-quality/preflight or worker model availability blockers, is not a goal-complete success condition and must not let the parent report evergreen completion. Receipts must include createCampaignStepReceipt with setupPlanCall, createCampaignWorkflowReceipt, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall nested inside createCampaignStepReceipt; top-level-only copies of those objects are not enough and are not promoted by verify. setupPlanCall must use canonical keys: planRevision, actionId, laneKey, workspaceId, senderIds, campaignId, tableId, createIntent. Do not use laneActionId, lanePacketActionId, delegatedPlanRevision, delegatedActionId, or requestedCall text as a substitute for those canonical fields. createCampaignWorkflowReceipt must include skillCommand:'$sellable:create-campaign', skillName:'create-campaign', wrapperSkillLoaded:true, workflowPromptName:'create-campaign-v2', workflowPromptLoadedToHasMoreFalse:true, workflowAssetPath:'create-campaign-v2/core/flow.v2.json', workflowAssetLoaded:true, workerRuntime, workerThreadId or receiptArtifactPath, durableReceiptWritten when using a receipt file, and notAdHoc:true. messageDraftingReceipt must use exactly statusSource:'branch' or statusSource:'packaged-generate-messages-worker'; descriptive aliases such as statusSource:'package-readback-local-thread' are rejected. It must include proof that generate-messages was loaded, start_campaign_message_preparation/get_campaign_message_preparation_status ran when the packaged worker path is used, validationResult:'passed', a passed qualityReview, and at least 3 concrete sampleMessages with rowId, generatedMessageText, verdict, and issues; Do not substitute `message` for `generatedMessageText`; Do not substitute `passVerdict` for `verdict`. Before writing durable receipts, run a receipt self-check: top-level `planRevision`, `actionId`, `laneKey`, `laneType`, `workspaceId`, and `senderIds` must exist; if the self-check fails, fix the receipt before ending. Use start_campaign_message_preparation with approvalMode:\"mark_ready\" only for evergreen setup. Never call `start_campaign_message_preparation` with `approvalMode:\"approve\"`; approve exactly one semantic Approved cell through select_campaign_cells/update_cell and final proof must show approvedGeneratedMessageCount exactly 1. Shared Cold Fallback samples with a standalone name followed by 'Hey there' are rejected. This command does not launch campaigns, does not schedule sends, does not assign scheduler-owned send fields, does not raw-write campaign status, does not archive/delete cleanup targets, and does not spend paid credits.",
         inputSchema: {
             type: "object",
             properties: {

package/package.json

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

package/skills/create-campaign-v2/references/gold-standard-message-examples.md

@@ -446,22 +446,60 @@ Tokenized shape:
 
 Hey there
 
-Thanks for the support on my post about {{post_topic_line}}
+Saw you pop up on my post about {{post_topic_line}}
+
+This one
+{{post_url}}
+
+Looks like you lead {{plain_buyer_function}} at {{company_name}}, right?
+
+{{custom_closed_question}}
 ```
 
 Transfer rules:
 
 - Do not hardcode a post topic. Fill `{{post_topic_line}}` from the actual
-  selected sender-authored post or use a safer source-specific phrase.
-- Do not add a relevance question, CTA, product line, or extra paragraph after
-  the thank-you line. The reply-rate lesson is the casual warm acknowledgment,
-  not a cold pitch appended to it.
+  selected sender-authored post or use a safer source-specific phrase. The best
+  lines sound like Justin's CXConnect example: a specific topic in normal human
+  words plus a light aside after a hyphen.
+- Include the engaged post URL on its own line after `This one` when row/source
+  data has it. The link reminds the prospect why the message is relevant and
+  keeps this clearly in the Post Engagers motion instead of feeling like generic
+  Signal Discovery.
+- Fill `{{plain_buyer_function}}` with an easy-to-understand buyer function or
+  category, such as `customer success`, `CX operations`, `founder-led sales`,
+  `sales`, `growth`, or `LinkedIn outbound`. Do not turn this line into a
+  feature list or internal workflow description.
+- Fill `{{custom_closed_question}}` from the post topic, buyer function, company
+  context, and the current offer category. The question should be easy to answer,
+  closed-ended, and specific to that prospect. Do not reuse the same generic
+  question across every row.
+- Good `{{custom_closed_question}}` examples:
+  - `Are you guys trying to make LinkedIn outbound a real founder-led channel, or is it still mostly ad hoc?`
+  - `Are you using LinkedIn to reach sales leaders directly, or is most pipeline still coming from intros and email?`
+  - `Are you actively testing outbound for growth teams right now, or is LinkedIn still more of a founder-network channel?`
+  - `Are you trying to turn customer feedback into account-risk signals, or is that still mostly manual check-ins?`
+  - `Are you looking at support conversations as a source of churn risk, or does that still mostly live in tickets and surveys?`
+  - `Are you building a repeatable sales motion yet, or is most of it still founder-led experimentation?`
+  - `Are you treating LinkedIn as a sales channel this year, or mostly as brand and founder content?`
+- Bad `{{custom_closed_question}}` examples:
+  - `Are you trying to avoid manual research + follow-up process?`
+  - `Are you interested in seeing Sellable?`
+  - `Open to seeing how this would work?`
+  - `Do you need more leads, filters, messages, and sequence setup?`
+- The product/category wording in the question should be plain and immediately
+  legible, for example `LinkedIn outbound`, `customer success`, `CX operations`,
+  `support`, or `post-sales`. Avoid feature-heavy phrasing such as `manual
+  research + follow-up process`, `lead filters`, `workflow`, `sequence setup`,
+  or internal mechanism language.
+- Do not add a meeting ask, product pitch, proof block, or extra paragraph after
+  the custom closed question. The reply-rate lesson is the casual warm
+  acknowledgment, concrete post reminder, and low-friction custom question, not a
+  cold pitch appended to it.
 - Do not use "showing some love"; it reads too casual for executive/VP/director
   contacts.
-- Keep the thank-you line. The point of this motion is acknowledging real
-  sender-owned support without appending a cold relevance question. Do not
-  flatten it back to "saw you pop up" unless the sender specifically asks for
-  that wording.
+- Keep the post-engager acknowledgment. The point of this motion is acknowledging
+  real sender-owned support without pretending this is generic cold outreach.
 - Do not copy this shape into shared lanes, third-party thread sources, or cold
   fallback campaigns.
 - Do not pitch, ask for a meeting, or mention internal product vocabulary in

package/skills/create-evergreen-campaigns/SKILL.md

@@ -387,13 +387,10 @@ before completion.
 Short form: Workers must preserve parent postEngagerSenderIds even for shared lanes.
 Short form: Never run a shared-lane worker-local plan with `postEngagerSenderIds:[]` unless the parent `postEngagerSenderIds` is exactly `[]`.
 
-Worker fan-out must use visible or durable execution. In local Codex, the
-default and preferred runtime is `workerDispatch.preferredRuntime:
-"visible-codex-app-thread"`. The parent must attempt a visible Codex app thread
-first with the actual Codex app thread tools: if `codex_app.create_thread` is
-not already visible, use tool discovery for the Codex app thread tools; then
-call `codex_app.list_projects`, select the current repo project, and call
-`codex_app.create_thread` with `target:{type:"project", projectId,
+Worker fan-out must use visible or durable execution. Preferred in local Codex
+is a visible Codex thread created with the actual Codex app thread tools:
+first call `codex_app.list_projects`, select the current repo project, then
+call `codex_app.create_thread` with `target:{type:"project", projectId,
 environment:{type:"local"}}`. Do not create a worktree target for evergreen
 UAT or lane execution. The parent must record the returned thread id, pass
 exactly one lane packet into that thread, and require the worker to write the
@@ -407,10 +404,9 @@ worker exits, and contain the current `planRevision`, `actionId`, `laneKey`,
 `receiptArtifactPath`, and `durableReceiptWritten:true`. If a receipt predates
 the current run, uses an old path without `receiptRunId`, or was not freshly
 written by the current worker, stop with `blocked: stale_receipt_artifact`
-before parent verify or completion. A streaming worker or branch worker is a
-fallback only when app thread tools are unavailable; the receipt must include
-`preferredRuntimeAttempt` for `visible-codex-app-thread` and a non-empty
-`fallbackReason`, or backend verify rejects it.
+before parent verify or completion. A streaming worker or branch worker is
+acceptable only when it writes a fresh durable per-lane receipt artifact as it
+works.
 When visible Codex app thread tools are unavailable but local Codex CLI is
 available, the accepted durable streaming-worker command shape is:
 `codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
@@ -720,11 +716,7 @@ not a parent-thread summary. The receipt must include:
   `workflowAssetPath:"create-campaign-v2/core/flow.v2.json"`,
   `workflowAssetLoaded:true`, the real `workerRuntime`, a visible
   `workerThreadId` or durable `receiptArtifactPath`, `durableReceiptWritten:true`
-  when using a receipt file, and `notAdHoc:true`. If `workerRuntime` is
-  `streaming-worker-with-durable-receipt` or
-  `branch-worker-with-durable-receipt`, also include
-  `preferredRuntimeAttempt` proving the parent attempted
-  `visible-codex-app-thread` first and a non-empty `fallbackReason`.
+  when using a receipt file, and `notAdHoc:true`.
 - `researchSenderReceipt`: `research-sender` prompt load proof,
   `complete_sender_research` result, sender LinkedIn identity basis, and the
   notes/proof counts used before the net-new `create_campaign` call. It must
@@ -919,7 +911,7 @@ verification unless the same object also appears inside
       "workflowPromptLoadedToHasMoreFalse": true,
       "workflowAssetPath": "create-campaign-v2/core/flow.v2.json",
       "workflowAssetLoaded": true,
-      "workerRuntime": "visible-codex-app-thread",
+      "workerRuntime": "separate-codex-thread",
       "workerThreadId": "<visible local Codex thread id>",
       "receiptArtifactPath": "<receiptArtifactPath from workerDispatch.receiptArtifactHint>",
       "durableReceiptWritten": true,
@@ -1338,21 +1330,35 @@ Message, and verify current-revision sample messages before final completion.
      Short form: Shared lanes must reject internal workflow vocabulary.
      Short form: revise or rerun the packaged create-campaign/generate-messages path.
    - **Post Engagers** first-message style: short, casual, references the
-     sender-authored post they engaged with, and stops after the thank-you
-     line. Use **no internal vocabulary, no pitch, no meeting ask, no product
-     line, and no relevance question** in message one:
+     sender-authored post they engaged with, includes the post URL as a concrete
+     reminder, uses an easy buyer-function/category line, and ends with one
+     row-custom closed question. Use **no internal vocabulary, no meeting ask,
+     no proof block, no feature-stack category, and no generic static question**
+     in message one:
 
      ```
      {{first_name}}
 
      Hey there
 
-     Thank you for the support on my post about {{post_topic_line}}
+     Saw you pop up on my post about {{post_topic_line}}
+
+     This one
+     {{post_url}}
+
+     Looks like you lead {{plain_buyer_function}} at {{company_name}}, right?
+
+     {{custom_closed_question}}
      ```
 
-     Do not add any paragraph after the thank-you line. In particular, do not
-     append `curious, are you trying...`, `open to...`, `worth seeing...`, or
-     Sellable/product copy to a Post Engagers first message.
+     `{{custom_closed_question}}` must be specific to the post topic, buyer
+     function, company context, and current offer category. The category should
+     be easy to understand, for example `LinkedIn outbound`, `customer success`,
+     `CX operations`, `support`, `sales`, or `growth`; do not use feature-heavy
+     phrasing like `manual research + follow-up process`, `lead filters`, or
+     `sequence setup`. Do not add any paragraph after the custom closed question.
+     In particular, do not append `open to...`, `worth seeing...`, a meeting ask,
+     proof block, or Sellable/product copy to a Post Engagers first message.
 
    - **Shared Signal Discovery** first-message style: short, casual, starts
      from the real public business theme or buyer problem supported by the row.

package/skills/generate-messages/SKILL.md

@@ -227,17 +227,24 @@ when those shared lanes were sourced from engagement-like signals. Shared lanes
 must choose a signal-led, event-led, job-post-led, or proof-led motion from the
 current brief and row evidence instead of inheriting a preset first-message
 template.
-Post-engager first messages should thank the prospect for the support on the
-sender-owned post and then stop. Do not add a relevance question, CTA, product
-line, meeting ask, or extra paragraph after the thank-you opener unless the
-operator explicitly asks for a longer first message. Prefer the gold shape
-`Thanks for the support on my post about {{post_topic_line}}` over
-surveillance-flavored wording like `saw you pop up`, unless the sender explicitly
-asks for that older wording.
+Post-engager first messages should follow the CXConnect warm shape: acknowledge
+the sender-owned post engagement, include the engaged post URL after a `This one`
+line when row/source data has it, add a plain buyer-function/category check, and
+ask one custom closed question. The question must be specific to the post topic,
+buyer function, company context, and current offer category; do not reuse one
+generic feature-stack question across every row. Product/category wording should
+be immediately legible, such as `LinkedIn outbound`, `customer success`, `CX
+operations`, `support`, `sales`, `growth`, or `post-sales`, not internal
+workflow/mechanism language like `manual research + follow-up process`, `lead
+filters`, or `sequence setup`. Do not add a meeting ask, product pitch, proof
+block, or extra paragraph after the custom closed question unless the operator
+explicitly asks for a longer first message.
 Short form: use the CXConnect Post-Engager Warm Reply-Rate Pattern only when the source is sender-owned Post Engagers.
 Short form: Never use that warm post-engager pattern for Shared Signal Discovery or Shared Cold Fallback.
-Short form: Post-engager warm first messages stop after the thank-you line.
-Short form: Do not add `curious`, `open to`, `trying to`, product copy, or a CTA after the post-engager thank-you line.
+Short form: Post-engager warm first messages use `This one` plus the post URL when available.
+Short form: Post-engager warm first messages need a row-custom closed question.
+Short form: Use plain category words, not feature-stack wording.
+Short form: Do not add `open to`, `worth seeing`, product copy, proof blocks, or a meeting CTA after the custom closed question.
 
 ### Shared Cold Fallback quality bar