@sellable/mcp 0.1.142 → 0.1.144

package/skills/create-campaign-v2/references/final-handoff-contract.md

@@ -33,8 +33,8 @@ order (all before waiting for the user):
    `get_campaign_navigation_state` when available so the watch link visibly
    lands on Settings before sender setup.
 4. Explain sender setup and Slack in normal customer language: Sellable needs a
-   connected LinkedIn sender before anything can send, and Slack reply review
-   matters because replies and approvals need a channel the team will monitor.
+   connected LinkedIn sender for launch, and Slack reply review matters because
+   replies and approvals need a channel the team will monitor.
 5. If no connected sender exists, surface the campaign Settings link
    `/campaign-builder/{campaignId}/settings?mode=claude`, tell the user to
    connect a sender there, and STOP. Do not attach sequence and do not start.
@@ -70,7 +70,7 @@ The final handoff must answer five customer questions in plain language:
 - why the selected LinkedIn sender and Slack reply review matter before launch
 - what clicking Start does (approves/starts the campaign send path)
 - how to revise (reply with what to change, or use the campaign UI)
-- whether anything has started yet (nothing sends until the user starts)
+- current launch status and what the final Start action does
 
 When `lead-source-intake.json` exists, also answer:
 
@@ -84,8 +84,8 @@ When `lead-source-intake.json` exists, also answer:
 
 Use the exact state name `awaiting-user-greenlight` so logs and UX artifacts
 can verify the state-machine stop point, but explain it in normal words: the
-campaign is built, sender/sequence setup is being completed, and nothing sends
-until the user's final start decision. The watched UI may advance through
+campaign is built, sender/sequence setup is being completed, and the final
+start decision is still ahead. The watched UI may advance through
 Settings, Sequence, and Send while this state-machine step remains the final
 handoff.
 

package/skills/create-campaign-v2/references/message-review-safety-gate.md

@@ -17,20 +17,26 @@ instead of pulling the long prompt into the main thread.
 
 ## Required Workflow
 
-1. Read `brief.md`, `lead-review.md`, `lead-sample.json`, and `lead-filter.md`
-   when present.
-2. Pick 2-3 sample rows from `lead-sample.json`, preferring rows that pass the
-   filter or are likely to pass. Do not invent new rows.
-3. Build the message from the approved brief and the sampled rows. Use only
-   proof that appears in the brief, source review, sample, or explicit user
-   answers. Unsupported reply-rate, meeting-rate, ROI, revenue, and customer-logo
-   claims are blocked.
-4. Produce `message-validation.md` with the required sections below.
-5. Produce `message-review.md` as the customer-facing checkpoint.
+1. Read the live campaign basis: campaign id, campaign revision or
+   `campaignUpdatedAt`, campaign brief content, selected source decision,
+   selected lead list/source state, `workflowTableId`, imported review-batch
+   row ids/hash, and any saved rubric/filter summary supplied by the parent.
+2. Pick 2-3 sample rows from the imported review-batch rows, preferring rows
+   that pass the saved rubrics or are likely to pass. Do not invent new rows.
+3. Build the message from the approved campaign brief, selected source context,
+   sampled rows, and explicit user answers. Use only proof that appears in that
+   live basis. Unsupported reply-rate, meeting-rate, ROI, revenue, and
+   customer-logo claims are blocked.
+4. Return a compact message recommendation to the parent thread. Do not write
+   local markdown/json artifacts in normal customer runs; emit debug artifacts
+   only when the parent explicitly asks for debug/UAT output.
+5. Render the customer-facing message review in chat before asking for approval.
+   After approval, the parent persists template and token rules into campaign
+   state with `update_campaign_brief`.
 6. Ask exactly `approve-message` or `revise-messaging`. Do not import, queue,
    attach sequence, or start before `approve-message`.
 
-## Required `message-validation.md` Sections
+## Required Message Recommendation Sections
 
 - `Status`
 - `Mode`
@@ -51,8 +57,8 @@ instead of pulling the long prompt into the main thread.
 - `Findings`
 - `Recommendation`
 
-Keep this artifact concise. It should prove the reasoning path, not reproduce
-the full framework.
+Keep this recommendation concise. It should prove the reasoning path, not
+reproduce the full framework.
 
 ## Message Quality Gates
 
@@ -83,21 +89,96 @@ but the [topic] thread felt close enough to send`. Otherwise omit the
 - If the message is plausible but not ready to send, set
   `Recommendation: revise-messaging`.
 
-## Customer-Facing `message-review.md`
-
-Render this in chat before asking:
-
-- `Status: message-review`
-- `Subject:`
-- `Message:` with the tokenized template or approved AI-native message
-- `Rendered examples:`
-- `Good token fill:`
-- `Good omit:`
-- `Token notes:`
-- `My take:`
-- `Suggested adjustment:`
-- `Question: approve-message or revise-messaging?`
-- `Recommendation: approve-message` or `Recommendation: revise-messaging`
+## Customer-Facing Message Review
+
+Render this in chat before asking. Use Markdown structure so the approval target
+is visually scannable:
+
+````markdown
+Status: message-review
+
+## Message Template
+
+**Subject**
+
+```text
+{{tokenized_subject}}
+```
+
+**Body**
+
+```text
+{{tokenized_message_body}}
+```
+
+## Rendered Examples
+
+### Good token fill
+
+Use when the row has a clean, supported fill.
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+
+### Good omit / fallback
+
+Use when a row signal or company context is missing, weak, or awkward.
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+
+### Bad fill to avoid
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+
+**Why this is wrong:** one sentence naming the exact token-fill failure.
+
+## Token Notes
+
+| Token            | Use when                 | Fallback |
+| ---------------- | ------------------------ | -------- |
+| `{{first_name}}` | Clean first name exists. | `there`  |
+
+## Recommendation
+
+**My take:** ...
+
+**Suggested adjustment:** ...
+
+**Question:** approve-message or revise-messaging?
+
+**Recommendation:** approve-message
+````
+
+Formatting requirements:
+
+- Put the tokenized template and every rendered example in fenced `text` blocks
+  so chat gives them a distinct background.
+- `Good token fill` and `Good omit / fallback` must each contain a complete
+  rendered subject + body, not a bullet list of token names or a single
+  bridge-line fragment.
+- Include `Bad fill to avoid` when the row sample has a tempting but unsafe
+  source-mechanics or raw-headline fill; otherwise include `Bad fill to avoid:
+none found`.
+- Use a token notes table, not paragraph-only token notes.
+- Keep reasoning outside the code blocks so the blocks are easy to inspect and
+  approve.
 
 `My take` and `Suggested adjustment` must be specific. The adjustment can be
 "approve as-is, or revise once to X if you want Y"; it must not be empty.

package/skills/create-campaign-v2/references/sample-validation-loop.md

@@ -20,7 +20,9 @@ auto-revise leads.
 
 ## Inputs
 
-- `CampaignOffer.currentStep === "validate-sample"` (set at end of Step 13)
+- `CampaignOffer.currentStep === "apply-icp-rubric"` (the watched app is
+  already on Filter Leads after `save_rubrics`; `validate-sample` is the
+  logical loop name, not a visible route)
 - Imported review batch from Step 13 (size: `importLimit`, default 15)
 - Config from `auto-execute.yaml`: `sample.sampleSize`,
   `sample.minProjectedPass`, `sample.maxRevisionRounds`
@@ -48,7 +50,8 @@ auto-revise leads.
    the enrichment batch ids; NOT by calling wait_for_rubric_results
    before rubric was scheduled)
 
-5. check_rubric(sample)
+5. do not call `check_rubric`; the product cascade runs enrichment and rubric
+   scoring from the queued Enrich Prospect cells
 
 6. wait_for_rubric_results(sample, targetCount = <cohortSize>, minPassedCount = 1)
    - cohortSize = stats.totalRows of the enrichment batch, or the

package/skills/create-campaign-v2/references/step-15-re-cascade.md

@@ -2,8 +2,7 @@
 
 This reference governs Step 15 (`auto-execute-messaging`) re-cascade
 behavior when Step 14's validate-sample loop graduates additional rows
-from pending → passed after the first `generate_messages` call has
-already run.
+from pending → passed after the first Generate Message cells have already run.
 
 Load whenever Step 15 is about to transition to
 `awaiting-user-greenlight`, and on every resume into Step 15.
@@ -25,7 +24,7 @@ Re-cascade runs whenever ALL of the following are true:
 
 1. Step 15 has already observed the initial review-batch message cascade.
 2. A subsequent check of rubric state shows rows that were pending at
-   first generate_messages time are now passed.
+   first message-generation pass are now passed.
 3. Those newly-passed rows do NOT yet have generated messages
    (`messagesCount` flat relative to pre-cascade).
 4. Step 15 has NOT yet transitioned to `awaiting-user-greenlight`.

package/skills/create-campaign-v2/references/watch-guide-narration.md

@@ -14,14 +14,14 @@ Building campaign with {Claude Code or Codex}               [Exit watch mode]
 {visibleState} {agentIntent}
 
 Next: {nextAction}
-{safety?}
 ```
 
 UI owns the header, driver label, button, progress bar, step count, and static
 stage labels. The driver label comes from the watch URL mode (`mode=claude` or
 `mode=codex`), so do not add separate guide args for it. You own `stage`,
 `headline`, `visibleState`, `agentIntent`, and any exceptional `nextAction`,
-`safety`, `workerStatuses`, or `blockedReason`.
+`workerStatuses`, `blockedReason`, or concise `safety` note for blocked/recovery
+states.
 
 ## Copy Rules
 
@@ -40,6 +40,11 @@ stage labels. The driver label comes from the watch URL mode (`mode=claude` or
   sample you are checking, and why that helps this campaign.
 - At filter choice, do not say filtering the batch before rubrics and message approval are saved.
 - Avoid internal terms: MCP, tool, currentStep, workflow table, scout, debug.
+- Treat `safety` as optional internal context, not a visible disclaimer.
+- Do not repeat long negative lists like "no leads import, no enrichment, no
+  messages, no sequence, no sending" in routine watch copy. Prefer one concise
+  gate phrase only when it matters: "Approval covers scouting/search only" or
+  "Next gate: selected-post scrape."
 - Do not invent time estimates.
 
 ## Stages
@@ -86,8 +91,7 @@ Default source funnel:
   "headline": "Choosing the lead source",
   "visibleState": "The browser is on Pick Provider while Codex explains the source path before opening a provider lane.",
   "agentIntent": "Codex will start with people engaging with relevant LinkedIn posts when that looks plausible, then switch to Sales Nav to find ICP people actively posting on LinkedIn, then search by titles, and use Prospeo for a broader account/contact path. Sales Nav with recent activity remains the first LinkedIn fallback.",
-  "nextAction": "Review source",
-  "safety": "No leads import until you approve the source."
+  "nextAction": "Review source"
 }
 ```
 
@@ -99,8 +103,7 @@ Signal Discovery viability handoff:
   "headline": "Checking Signal Discovery viability",
   "visibleState": "The browser is moving from Pick Provider into Signal Discovery so the exact posts and sample math are visible.",
   "agentIntent": "Codex is testing whether relevant posts have enough ICP-looking engagers before recommending this as the source.",
-  "nextAction": "Review source math",
-  "safety": "No leads import until you approve the source."
+  "nextAction": "Review source math"
 }
 ```
 
@@ -112,8 +115,7 @@ Source direction override:
   "headline": "Testing the requested source",
   "visibleState": "The campaign asked for hiring and account signals, so Codex is starting with Prospeo instead of the default LinkedIn engagement path.",
   "agentIntent": "It is checking whether this source has enough reachable ICP-looking people before importing a review batch.",
-  "nextAction": "Review source",
-  "safety": "No leads import until you approve the source."
+  "nextAction": "Review source"
 }
 ```
 
@@ -125,8 +127,7 @@ Source fallback:
   "headline": "Switching source lanes",
   "visibleState": "The Signal Discovery sample did not show enough ICP-looking engagers for a confident first batch.",
   "agentIntent": "Codex is trying Sales Nav with recent activity so the source can still preserve some buyer activity context.",
-  "nextAction": "Review source",
-  "safety": "No leads import until you approve the source."
+  "nextAction": "Review source"
 }
 ```
 
@@ -149,9 +150,8 @@ Source recommendation ready:
   "stage": "find-leads",
   "headline": "Review the source in Codex",
   "visibleState": "The browser is showing the evaluated Signal Discovery source with counts and sample quality.",
-  "agentIntent": "Approve LinkedIn Engagement or ask for a source change in chat before any leads import.",
-  "nextAction": "Approve in Codex",
-  "safety": "No leads import until you approve the source."
+  "agentIntent": "Approve LinkedIn Engagement or ask for a source change in chat.",
+  "nextAction": "Approve in Codex"
 }
 ```
 
@@ -180,8 +180,7 @@ Source approved and import starting:
   "headline": "Importing the review batch",
   "visibleState": "The browser is still showing the approved LinkedIn Engagement source leads.",
   "agentIntent": "Codex is importing only the bounded 15-row review batch into the campaign now.",
-  "nextAction": "Review batch ready",
-  "safety": "This is still a review step; nothing launches or sends."
+  "nextAction": "Review batch ready"
 }
 ```
 
@@ -199,10 +198,9 @@ After review batch import:
   "visibleState": "The first review batch is in the campaign. The visible sample looks mixed enough that filters should be added before message review.",
   "agentIntent": "Codex is asking whether you want to further filter these leads before message review. Skip filters only if the visible rows already look clean.",
   "nextAction": "Choose filters or skip",
-  "safety": "Nothing enriches, validates, or sends until the message is ready and approved.",
   "workerStatuses": {
     "leadFitBuilder": "idle",
-    "messageDraftBuilder": "idle"
+    "messageDraftBuilder": "running"
   }
 }
 ```
@@ -211,7 +209,8 @@ Use this after the selected review rows are present and before filters are
 saved. This is add-filters intent, not active filtering. Recommend adding
 filters when the sample is mixed/noisy, tell the user to Choose filters or skip,
 and do not say filtering the batch before rubrics and message approval are
-saved. Only show worker statuses as running if those branches actually started.
+saved. The Message Draft Builder should start immediately after the bounded
+review batch exists; mark it running only when that branch actually started.
 When the user chooses filters, immediately persist `enableICPFilters: true` and
 move to `create-icp-rubric` so the watched app shows Filter Rules while Codex
 defines the rules in chat. After `save_rubrics`, move to `apply-icp-rubric`
@@ -242,11 +241,28 @@ Review ready:
   "headline": "Review the message template",
   "visibleState": "The browser remains on Filter Leads while the message template is reviewed in chat.",
   "agentIntent": "Codex is waiting for approval before saving the template to the campaign brief and queueing enrichment/filtering.",
-  "nextAction": "Approve or revise the template",
-  "safety": "Codex will only continue after you approve."
+  "nextAction": "Approve or revise the template"
 }
 ```
 
+Template approved, bounded filter test running:
+
+```json
+{
+  "stage": "fit-message",
+  "headline": "Template saved",
+  "visibleState": "The browser stays on Filter Leads while the bounded enrichment and filter test runs.",
+  "agentIntent": "Codex saved the approved message template, queued the review-batch Enrich Prospect cells, and is waiting for at least one row to pass before moving to Messages.",
+  "nextAction": "Move to Messages after a passing row"
+}
+```
+
+Do not move to Messages immediately after `approve-message`. The visible route
+is already Filter Leads after `save_rubrics`; approving the message only unlocks
+the bounded cascade from that screen. Move to Messages only once at least one
+review-batch row passes and Generate Message cells are ready/running for the
+passing rows.
+
 Messages waiting for template:
 
 ```json
@@ -255,8 +271,7 @@ Messages waiting for template:
   "headline": "Waiting for the template",
   "visibleState": "The fit rules are saved and the message template is still being prepared.",
   "agentIntent": "Codex is waiting until the template can be reviewed.",
-  "nextAction": "Review template",
-  "safety": "No enrichment, filtering, or Generate Message cells run until the template is approved."
+  "nextAction": "Review template"
 }
 ```
 

package/skills/create-campaign-v2/references/watch-link-handoff.md

@@ -36,7 +36,7 @@ Example skeleton:
 I created the campaign shell with the brief already in it.
 You can watch the lead source, filters, and messages fill in from here.
 
-No leads import and nothing sends yet.
+I’ll pause at the next approval gate before sourcing.
 
 Watch link: [Open campaign]({watchUrl})
 

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

@@ -36,10 +36,13 @@ Step 13 — import/confirm review batch only
   update_campaign(currentStep=filter-choice)
 
 Post-import main thread
-  launch Lead Fit Builder + Message Draft Builder after workflowTableId exists
+  launch Message Draft Builder immediately after workflowTableId + review rows exist
+  launch Lead Fit Builder only after user chooses filters
   save_rubrics({ campaignOfferId, leadScoringRubrics }) after the campaign table exists
-  show readable filters + one concrete sample message
-  after approval, update_campaign_brief writes `## Approved Message Template` with `{{...}}` tokens
+  keep the watched app on Filter Leads after rubrics are saved
+  while on Filter Leads, show the message template recommendation from the background Message Draft Builder
+  after approve-message, update_campaign_brief writes `## Approved Message Template` with `{{...}}` tokens
+  only then start the bounded review-batch cascade
 
 Step 14 — kick bounded cascade + observe sample
   queue_cells(cellIds=<review-batch Enrich Prospect cells only>)  <-- starts bounded chain
@@ -58,7 +61,9 @@ Step 15 — observe messaging
   get_rows_minimal                 # confirm passing rows have completed Generate Message cells
   (rare) queue_cells on any pending Generate Message cells
   token-contract spot check via get_rows
-  update_campaign(currentStep=awaiting-user-greenlight)
+  update_campaign(currentStep=auto-execute-messaging) with review-ready narration
+  ask the user to approve generated review-batch messages before Settings
+  only after approval: update_campaign(currentStep=awaiting-user-greenlight)
   (generate_messages is NOT an MCP tool; messages come from the cascade)
 
 Step 16 — awaiting-user-greenlight
@@ -144,7 +149,9 @@ what changed and orient the user to what the watch link will show next —
 reuse the v1 `create-campaign` watch-mode pattern verbatim.
 
 Resume currentStep names covered by this tail: `"auto-execute-leads"`,
-`"validate-sample"`, `"auto-execute-messaging"`,
+`"apply-icp-rubric"` (the visible Filter Leads home for the logical
+`validate-sample` loop), `"validate-sample"` (legacy resumes only),
+`"auto-execute-messaging"`,
 `"awaiting-user-greenlight"`, `"settings"`, `"sequence"`, `"send"`, and
 `"running"`. New mint-early runs normally
 enter Step 13 from `"confirm-lead-list"`; the `"auto-execute-leads"` string is
@@ -273,10 +280,12 @@ caller or start the workflow-table cascade too early. The cascade starts in
 Step 14 only after `save_rubrics` and `update_campaign_brief` have both
 succeeded.
 
-## Step 14: validate-sample (loop)
+## Step 14: validate-sample (logical loop on Filter Leads)
 
-Entered on `CampaignOffer.currentStep === "validate-sample"`. Full
-decision tree lives in `references/sample-validation-loop.md`.
+Entered after the message template is approved while the watched campaign is
+already on `CampaignOffer.currentStep === "apply-icp-rubric"` / Filter Leads.
+Do not route to a visible `validate-sample` step. Full decision tree lives in
+`references/sample-validation-loop.md`.
 
 **Step 14 starts the bounded cascade, then observes it.** Step 13 imported the
 review batch only. After `save_rubrics` and the approved message template are
@@ -381,8 +390,9 @@ Template`. If it does not, fail before the cascade runs. Do not repair
 5. If the sample fails the token contract, diagnose brief-vs-list
    (same revision loop as Step 14) and escalate if over
    `maxRevisionRounds`.
-6. On success, `update_campaign({ campaignId, currentStep:
-"awaiting-user-greenlight" })`.
+6. On success, keep `currentStep: "auto-execute-messaging"` and ask the user
+   to approve the generated review-batch messages. Only that approval may move
+   the campaign to Settings / `awaiting-user-greenlight`.
 
 **Do NOT hand-write message bodies via `update_cell`.** `update_cell`
 is reachable for legitimate operator overrides AFTER the tail hands
@@ -428,8 +438,11 @@ strings, which is why Step 16 requires Step 15 to be complete.
 6. If the sample fails the token contract or critique, diagnose +
    loop the same way Step 14 does (brief-vs-list), subject to the same
    `maxRevisionRounds` cap.
-7. On success, `update_campaign({ campaignId, currentStep:
-"awaiting-user-greenlight" })` and orient the user.
+7. On success, keep `currentStep: "auto-execute-messaging"`, show that the
+   review-batch messages are ready in Messages, and ask for approval before
+   Settings. Only after the user approves those generated messages should
+   `update_campaign({ campaignId, currentStep: "awaiting-user-greenlight" })`
+   run.
 
 Critique failure modes NEVER escalate. A critic timeout, a total
 timeout, a budget trip, a fake-proof rejection, or an unsupported-
@@ -451,7 +464,7 @@ Shape:
    `get_campaign_navigation_state` when available to confirm the watch link is
    visibly on Settings.
 4. Explain why the sender matters: Sellable needs a connected LinkedIn sender
-   before anything can send. Explain Slack reply review before launch: replies
+   for launch. Explain Slack reply review before launch: replies
    and approvals need a place the team will actually monitor, so Slack should be
    connected or intentionally skipped before launch.
 5. If no connected sender exists, surface a direct Settings link:

package/skills/research/config.json

@@ -0,0 +1,9 @@
+{
+  "parallelMode": "wide",
+  "agentCount": 6,
+  "maxToolCallsPerAgent": 2,
+  "senderMaxAgents": 2,
+  "senderMaxToolCallsPerAgent": 3,
+  "progressMode": true,
+  "debugMode": true
+}