@sellable/mcp 0.1.188 → 0.1.190

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

@@ -27,8 +27,8 @@ Re-cascade runs whenever ALL of the following are true:
    to continue processing more campaign rows.
 2. A subsequent check of rubric state shows rows that were pending at
    first message-generation pass are now passed.
-3. Those newly-passed rows do NOT yet have generated messages
-   (`messagesCount` flat relative to pre-cascade).
+3. Those newly-passed rows do NOT yet have current-revision generated messages
+   (`currentRevisionGeneratedMessagesCount` flat relative to pre-cascade).
 4. Step 15 has NOT yet transitioned to `awaiting-user-greenlight`.
 
 Before that first generated-message approval, do not run this loop just to wait
@@ -41,25 +41,31 @@ rows graduated.
 ## Re-Cascade Loop Shape
 
 ```text
-1. paginate campaign table (get_rows_minimal, strip carryData) to
-   collect rowIds where:
-     - rubricStatus = "passed"
-     - messageStatus = "pending" OR messagesCount = 0
+1. use selector dry-run only if debugging:
+   `select_campaign_cells({ columnRole: "generateMessage", rowSelector: { type: "needsGeneratedMessage" } })`
+   The normal path can skip this and queue directly.
 
-2. if newlyPassedRowIds.length == 0:
+2. if selectedCellCount == 0:
      proceed to awaiting-user-greenlight
      EXIT re-cascade loop
 
 3. else:
-     queue_cells({
+     queue_campaign_cells({
        tableId,
-       cellIds: newlyPassedGenerateMessageCellIds
+       columnRole: "generateMessage",
+       rowSelector: { type: "needsGeneratedMessage" }
      })
 
-4. re-check token contract on the cascaded subset (strict mode default)
+4. wait_for_campaign_processing({
+       tableId,
+       minGeneratedMessages: 1,
+       templateRevision: "current"
+     })
+
+5. re-check token contract on the cascaded subset (strict mode default)
    — see references/thomas-revision-filters.md + gold-standard-message-patterns.md
 
-5. go back to step 1 until newlyPassedRowIds == 0
+6. go back to step 1 until selectedCellCount == 0
 ```
 
 ## Cap
@@ -86,9 +92,10 @@ silently skipped.
 ## Hard Rules
 
 - Generate Message cells do not always auto-cascade on late-passed rows —
-  Step 15 must explicitly queue newly-pending Generate Message cells.
+  Step 15 must explicitly queue `needsGeneratedMessage` cells.
 - Re-cascade iteration cap = 3. Trip escalates.
-- `messagesCount` flat + rubric graduating rows ⇒ re-cascade required.
+- `currentRevisionGeneratedMessagesCount` flat + rubric graduating rows ⇒
+  re-cascade required.
 - Token contract enforcement applies per-cascade, not once-for-all.
 - Re-cascade NEVER re-runs `import_leads`, `check_rubric`, or
   `enrich_with_prospeo`. Those are Step 13 / Step 14 actions.

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

@@ -30,9 +30,8 @@ Step 13 — materialize source list + confirm initial campaign slice
   materialize/reuse approved source with campaignOfferId
   import_leads(source-list target; SalesNav/Prospeo default ~1000, Signal Discovery default ~1500 engagers)
   wait_for_lead_list_ready
-  confirm_lead_list(reviewBatchLimit=15)
+  confirm_lead_list(reviewBatchLimit=15)  # compact reviewBatch metadata is stored on the campaign table
   wait_for_campaign_table_ready    # campaign table exists
-  get_rows_minimal                 # read initial campaign-table execution slice
   update_campaign(currentStep=filter-choice)
 
 Post-import main thread
@@ -45,22 +44,17 @@ Post-import main thread
   only then start the initial-slice cascade
 
 Step 14 — kick initial-slice cascade + observe campaign rows
-  queue_cells(cellIds=<first 15 campaign-table execution-slice Enrich Prospect cells only>)  <-- starts bounded chain
-  wait_for_campaign_table_ready    # wait until sample cascade starts returning filter results
-  get_rows_minimal                 # read passesRubric + message cell status per row
-  wait_for_rubric_results(minPassedCount=1, includeRows=false)
+  queue_campaign_cells(columnRole=enrich, rowSelector=reviewBatch)  <-- starts bounded chain
+  wait_for_campaign_processing(minPassedCount=1)
   if at least one row passes: update_campaign(currentStep=auto-execute-messaging)
   compute projectedPass for later reporting / revision decisions
-  if zero rows pass: diagnose brief-vs-list; if brief: update_campaign_brief + re-queue + wait
+  if zero rows pass: diagnose brief-vs-list; if brief: update_campaign_brief + re-queue + wait with changed args
   (check_rubric / bulk_enrich_with_prospeo are NOT called here —
-   cascade already did them. wait_for_rubric_results is OK as a
-   read-only observation helper if you need to block until the first
-   passing filtered row exists.)
+   cascade already did them.)
 
 Step 15 — observe messaging
-  wait_for_rubric_results({ minPassedCount: 1, minMessagesCount: 1, includeRows: false })
-  get_rows_minimal                 # confirm the first passing generated message exists
-  (rare) queue_cells on any pending Generate Message cells
+  queue_campaign_cells(columnRole=generateMessage, rowSelector=needsGeneratedMessage)
+  wait_for_campaign_processing({ minGeneratedMessages: 1, templateRevision: "current" })
   token-contract spot check via get_rows
   update_campaign(currentStep=auto-execute-messaging) with review-ready narration
   ask the user to approve the generated message before Settings
@@ -99,19 +93,14 @@ Message` column's http_request writes those cells via the cascade.
 - Do NOT call `check_rubric`, `enrich_with_prospeo`, or
   `bulk_enrich_with_prospeo` in the tail. Those are direct-API
   mutation tools that fetch data to the caller without writing to
-  the workflow table cells. Step 13's `queue_cells` already
+  the workflow table cells. Step 14's `queue_campaign_cells` call
   triggers the column-level enrichment that populates those cells.
   Running these tools in the tail produces duplicate cost with no
   cell side effect.
-- `wait_for_rubric_results` is read-only and OK to use as an
-  observation helper when you need to block on rubric completion —
-  it does not mutate cells. Prefer `get_rows_minimal` +
-  `wait_for_campaign_table_ready` for the primary cascade-observation
-  path, but use `wait_for_rubric_results({ targetCount: cohortSize })`
-  when the table-level wait returns before rubric cells finish. In
-  create-campaign-v2 Step 14, pass `minPassedCount: 1`; one passing
-  filtered row is enough to start observing Generate Message, even if
-  other sample rows are still processing.
+- `wait_for_campaign_processing` is the stats-only observation helper for the
+  tail. In Step 14 pass `minPassedCount: 1`; in Step 15 pass
+  `minGeneratedMessages: 1` and `templateRevision: "current"`. Do not repoll
+  identical args after a timeout.
 - `start_campaign` is FORBIDDEN in the autonomous tail. It belongs only
   in the Claude-greenlight path, AFTER the user signals "start". See
   `references/final-handoff-contract.md`.
@@ -121,15 +110,16 @@ Message` column's http_request writes those cells via the cascade.
 - You MAY NOT call `start_campaign` while ANY passing row has an
   empty `Generate Message` cell. If you discover empty message cells in
   the greenlight turn, ABORT greenlight and return to Step 15 first.
-- You MAY NOT call `attach_sequence` while ANY passing row has an
-  empty `Generate Message` cell. Before `attach_sequence`, call
-  `get_rows_minimal` and confirm every row where `passesRubric=true`
-  has a `completed` Generate Message cell with non-empty `result`. If
-  any are pending, call `queue_cells` on those generateMessageCellIds
-  and wait. If rows truly won't message, ESCALATE.
-- You MAY NOT advance past Step 13 without calling `queue_cells` on
-  the initial-slice Enrich Prospect cells. Without it, every downstream
-  cell stays `pending` and the campaign ships empty.
+- You MAY NOT call `attach_sequence` while ANY reviewed passing row has an
+  empty or stale `Generate Message` cell. Before `attach_sequence`, call
+  `select_campaign_cells({ tableId, columnRole: "generateMessage",
+  rowSelector: { type: "needsGeneratedMessage" } })`. If any cells are
+  selected, call `queue_campaign_cells` with the same selector and wait with
+  `wait_for_campaign_processing({ minGeneratedMessages: 1,
+  templateRevision: "current" })`. If rows truly won't message, ESCALATE.
+- You MAY NOT advance past Step 14 without calling `queue_campaign_cells` for
+  `{ columnRole: "enrich", rowSelector: { type: "reviewBatch" } }`. Without it,
+  every downstream cell stays `pending` and the campaign ships empty.
 - You MAY NOT queue enrichment for rows outside the configured internal
   execution slice before the user approves expansion. Full-list enrichment/message
   generation is a credit-spend decision and must happen after the user
@@ -141,9 +131,8 @@ All subsequent steps read the already-parsed config. Do not re-load mid-run,
 and do not read repo-local config files; packaged Claude Code and Codex runs
 must use the MCP asset loader.
 Load each subskill prompt (`create-campaign-v2`, `research-sender`,
-`generate-messages`) at most once per run. A multi-call chunk sequence counts
-as one load. If a tool result already told you to load a prompt, load all
-chunks once and remember; do not restart the same prompt from offset 0 later.
+`generate-messages-compact`) at most once per run. If a tool result already told
+you to load a prompt, remember it; do not restart the same prompt later.
 
 After every `update_campaign({ currentStep: ... })` in the tail, narrate
 what changed and orient the user to what the already-open app will show next —
@@ -265,16 +254,17 @@ searchId, targetLeadCount: 1000 })`.
    the source list and `workflowTableId` is the campaign table.
 4. `wait_for_campaign_table_ready` until the initial campaign-table execution slice rows are
    available in the campaign table.
-5. Call `get_rows_minimal({ tableId: workflowTableId })` and confirm the
-   15-row internal execution slice is present. Do not queue cells in Step 13.
+5. Confirm the compact `reviewBatch` returned by `confirm_lead_list` has the
+   expected 15-row internal execution slice metadata. Do not fetch row payloads
+   or queue cells in Step 13.
 6. If the import returns zero usable leads, ESCALATE per
    `references/escalation-ladder.md` (hard fail).
 7. `update_campaign({ campaignId, currentStep: "filter-choice" })`.
 8. Describe the filter-choice screen now visible in the already-open app. Do not
    repeat the watch URL.
 
-**Do NOT call `check_rubric`, `wait_for_rubric_results`,
-`queue_cells`, `enrich_with_prospeo`, or `bulk_enrich_with_prospeo` in Step 13.**
+**Do NOT call `check_rubric`, `wait_for_campaign_processing`,
+`queue_campaign_cells`, `enrich_with_prospeo`, or `bulk_enrich_with_prospeo` in Step 13.**
 Those are direct-API tools that fetch enrichment/scoring data to the
 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
@@ -299,18 +289,16 @@ message is ready. It does NOT call `check_rubric`,
 Shape:
 
 ```text
-queue_cells({ tableId: workflowTableId, cellIds: reviewBatchEnrichCellIds })
-wait_for_campaign_table_ready({ tableId: workflowTableId })
-get_rows_minimal({ tableId: workflowTableId })
-wait_for_rubric_results({ tableId: workflowTableId, targetCount: cohortSize, minPassedCount: 1, includeRows: false })
+queue_campaign_cells({ tableId: workflowTableId, columnRole: "enrich", rowSelector: { type: "reviewBatch" } })
+wait_for_campaign_processing({ tableId: workflowTableId, minPassedCount: 1 })
 passInSample = count of first sampleSize review/process sample rows with passesRubric === true
 projectedPass = round(passInSample / sampleSize * importLimit)
 
-if wait_for_rubric_results.ready === true and passRate.passed >= 1:
+if wait_for_campaign_processing.ready === true and passRate.passed >= 1:
     advance to Step 15 to observe or queue Generate Message for currently passing rows
     do not wait for every sample row to finish before message generation starts
     stop for review as soon as one passing generated message is ready
-else if wait_for_rubric_results.ready === false and reason === "timeout":
+else if wait_for_campaign_processing.ready === false and reason === "timeout":
     use the partial passRate/stats as the sample diagnostic
     if passRate.passed >= 1:
         advance to Step 15 to observe/queue Generate Message for passing rows
@@ -322,9 +310,10 @@ else if wait_for_rubric_results.ready === false and reason === "timeout":
         ask whether to revise source, revise filter/rubric, or wait once only if still processing
 else:
     diagnose brief-vs-list per sample-validation-loop.md
-    - brief: autonomous update_campaign_brief, then re-kick cascade
-             (queue_cells on enrichCellIds) and wait for the new
-             results
+    - brief: autonomous update_campaign_brief, then re-kick cascade with
+             queue_campaign_cells({ columnRole: "enrich", rowSelector:
+             { type: "reviewBatch" }, forceRerun: true }) and wait for the
+             new results
     - list:  ESCALATE (no auto-revision of leads)
     - unknown: ESCALATE
     revisionRound += 1
@@ -361,8 +350,8 @@ Entered on `CampaignOffer.currentStep === "auto-execute-messaging"`.
 
 **Messages are produced by the `Generate Message` column cascade, not
 by a separate tool.** Do NOT call a `generate_messages` MCP tool —
-that tool does not exist; `generate-messages` is a subskill prompt
-loaded during live messaging drafts. In the autonomous tail, messages
+that tool does not exist; `generate-messages-compact` is the Message Draft
+Builder subskill prompt for the approved template. In the autonomous tail, messages
 flow through the column pipeline: `Enrich Prospect` →
 `DNC Check` → `ICP Score` → `Passes Rubric` → `Generate Message`.
 Each column's http_request auto-fires when its upstream dependency
@@ -373,21 +362,19 @@ the output — not to generate messages manually.
 
 **What Step 15 does:**
 
-1. `get_rows_minimal` to read `passesRubric` + `generateMessageCellId`
-   - the Generate Message cell's `status` and `result` per row.
-     Before queueing or waiting on Generate Message cells, confirm the
-     minted campaign brief still contains `{{...}}` in `## Approved Message
-Template`. If it does not, fail before the cascade runs. Do not repair
-     after mint; the template must be present during mint so Step 15 never
-     starts in freeform generation mode.
-2. For every row where `passesRubric === true`:
-   - The Generate Message cell should be `running` or `completed`
-     already (cascade auto-fired it). If it is still `pending`, queue
-     it explicitly: `queue_cells({ tableId, cellIds:
-<generateMessageCellIds> })`.
-3. `wait_for_rubric_results({ tableId, targetCount: reviewBatchSize,
-minPassedCount: 1, minMessagesCount: 1, includeRows: false })` until the
-   first passing generated message is ready. Do not wait for every passing row's
+1. Before queueing or waiting on Generate Message cells, confirm the minted
+   campaign brief still contains `{{...}}` in `## Approved Message Template`.
+   If it does not, fail before the cascade runs. Do not repair after mint; the
+   template must be present during mint so Step 15 never starts in freeform
+   generation mode.
+2. Use `select_campaign_cells({ tableId, columnRole: "generateMessage",
+   rowSelector: { type: "needsGeneratedMessage" } })` only if you need a dry-run
+   count. If any passing row has a pending, empty, or stale Generate Message
+   cell, queue it explicitly with `queue_campaign_cells({ tableId, columnRole:
+   "generateMessage", rowSelector: { type: "needsGeneratedMessage" } })`.
+3. `wait_for_campaign_processing({ tableId, minGeneratedMessages: 1,
+templateRevision: "current" })` until the first current-revision generated
+   message is ready. Do not wait for every passing row's
    Generate Message cell, and do not add "one more wait" for a stronger sample.
    Remaining review/process sample rows can continue processing in the background.
 4. Read the first ready generated message back via `get_rows` (full) and

package/skills/find-leads/SKILL.md

@@ -135,7 +135,8 @@ The kickoff doc is the resume surface. Re-open it before repeating discovery wor
   place to start, why the right buyers are likely to be there, what signs the
   next search will check, where you'll look next if the first place is too thin,
   and that approval only lets you look for the best places to find buyers. No
-  one is added to the campaign yet.
+  one is added to the campaign yet. The approval must come after the visible
+  plan; do not reuse a prior brief approval or generic approval panel.
 - When enough context exists, try 1-2 alternate hypotheses if the first lane is too weak or noisy.
 - Directional preview does not require a sender, campaign, or selected lead list. Start with count/sample exploration first; only attach searches to a campaign when the user is ready to import.
 - If the user already has a LinkedIn-profile CSV, treat that as a direct lead-list path and skip discovery.

package/skills/generate-messages/SKILL.md

@@ -1112,6 +1112,17 @@ unit, either compress it into that first send unit or omit it. Do not move it to
 a later message. Preserve the idea as an internal `Findings` note only if it is
 useful after campaign mint.
 
+### Message Review Revision Loop
+
+When the user gives edits to an already rendered template, treat that feedback
+as the next drafting input. Produce a revised selected template, rendered
+example, and short change summary before asking for approval again. Do not only
+acknowledge the feedback or ask whether a new version is better without showing
+the new version. In live campaign mode, save with `update_campaign_brief` only
+after the user approves the revised template.
+Do not call `request_user_input` or `AskUserQuestion` from the drafting or
+revision step; approval questions belong after the revised copy is visible.
+
 Before returning `Status: confirmed`, run this explicit check:
 
 `Single send unit: PASS | BLOCKED — reason`

package/skills/generate-messages-compact/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: generate-messages-compact
+description: Compact required Message Draft Builder prompt for create-campaign-v2; load lazy references only for examples, critique, or revision.
+visibility: internal
+---
+
+# Generate Messages Compact
+
+Use this prompt for create-campaign-v2 Message Draft Builder. It replaces the
+old normal-path requirement to load the full long-form `generate-messages`
+prompt before writing a reusable template. The full prompt remains available for
+legacy dry-mode validation and deep debugging.
+
+## Mode
+
+Draft one reusable first-message template for a live campaign after:
+
+- `confirm_lead_list` copied a non-empty source into the campaign table
+- the first review batch exists in campaign state
+- the parent recorded the filter choice
+
+This is not the product Generate Message cell path. Do not write row messages,
+queue cells, update the campaign brief, attach sequence, or launch.
+
+## Source Of Truth
+
+Use only live campaign inputs supplied by the parent or scoped MCP tools:
+
+- `campaignId`
+- campaign revision or `updatedAt`
+- campaign brief content and brief hash
+- selected source decision and `selectedLeadListId`
+- `workflowTableId`
+- review-batch row ids/hash and compact sample rows
+- filter choice and saved rubric summary when available
+- explicit user/operator message direction
+
+Reject as `blocked` or `stale` if campaign id, selected list, table id, brief
+hash, or review-batch basis do not match. Do not reconstruct state from local
+markdown/json files, database reads, or stale tool output.
+
+## Required Output
+
+Return compact structured output to the parent:
+
+- `templateRecommendation`: tokenized first-send template
+- `tokenFillRules`: safe fill rules, fallbacks, and unsupported fills
+- `renderedSample`: one good passing-row example
+- `omitSample`: one example where weak personalization is omitted
+- `concerns`: quality risks or blockers
+- `status`: `ready`, `blocked`, `retry-needed`, or `stale`
+- `basisStatus`, `basisToken`, `outputAt`, `outputHash`
+
+The parent owns approval and `update_campaign_brief`.
+
+## Drafting Rules
+
+- Keep it clear, concrete, and product-specific.
+- Use simple language and short lines.
+- Default to one blank line per sentence in the body.
+- Explain what the product is before what it does.
+- Use proof only when the campaign brief provides it.
+- Use the sender's voice, not third-person notes about the sender.
+- Use supported tokens such as `{{first_name}}` only.
+- Prefer omitting weak personalization over forcing a creepy line.
+- Do not claim the prospect needs outbound, automation, AI, or the product.
+- Do not claim private intent from a reaction/comment.
+- Do not write "saw you engaging", "clearly focused", or similar certainty.
+- Do not include bracketed instructions in the outbound message body.
+- Do not include sequence, follow-up, post-accept DM, launch, or sender setup.
+
+Engagement-source personalization is allowed only when it is cautious and
+self-aware, for example: `you might not remember the thread, but I found you
+through a [topic] discussion and your [role/company context] looked close to
+[problem]`. Otherwise omit the source signal and start from role, company,
+problem, or product relevance.
+
+## Quality Gate
+
+Before returning `ready`, verify:
+
+- first name and company/person match
+- tokens have deterministic fallbacks
+- proof claims are in the brief or omitted
+- the prospect angle follows from role/source context
+- unsupported claims are removed
+- the template is usable for the whole review batch, not only one row
+- at least one rendered example reads like a message a real sender would send
+
+## Lazy References
+
+Load `references/examples-critique-revision.md` only when:
+
+- the parent explicitly asks for a critique pass
+- the first draft fails the quality gate
+- the user asks to revise the message template
+- you need more examples to resolve a close call
+
+Do not load the old full `generate-messages` prompt in the normal create-campaign
+path unless the parent asks for legacy dry-mode validation or deep debugging.

package/skills/generate-messages-compact/references/examples-critique-revision.md

@@ -0,0 +1,37 @@
+# Examples, Critique, And Revision
+
+Load this only when the compact prompt is insufficient.
+
+## Good Pattern
+
+```text
+Hey {{first_name}},
+
+You might not remember the thread, but I found you through a Claude GTM
+discussion and your founder/operator background looked close enough to send this.
+
+I am building Sellable so Claude Code can run LinkedIn outbound without
+stitching together Clay, Apollo, HeyReach, and spreadsheets.
+
+It finds people from live LinkedIn signals.
+
+It filters for fit.
+
+It writes the sequence and keeps the campaign moving from chat.
+
+Open to seeing what this would look like for your own outbound workflow?
+```
+
+## Bad Patterns To Block
+
+- "Saw you engaging with Debbie's post, so AI-GTM is clearly on your mind."
+- "You need help with outbound."
+- "I noticed you are struggling with..."
+- "[PERSONALIZATION_LINE]"
+- "Christian's approach is..."
+
+## Revision Rule
+
+When the user asks to change the message after generation, update the approved
+template in the campaign brief and rerun Generate Message cells. Do not directly
+overwrite generated row messages.

package/skills/providers/signal-discovery.md

@@ -40,8 +40,14 @@ When the user asks to find posts or start searching, **IMMEDIATELY begin Round 1
 
 Production Signal Discovery uses Harvest for post comments and reactions.
 Harvest returns about 100 comments or reactions per page. The source scrape
-pages through Harvest up to the configured per-post caps, currently 1,500
-reactions and 300 comments per selected post.
+pages through Harvest up to the configured per-post caps, currently 1,000
+reactions and 1,000 top-level comments per selected post.
+
+LinkedIn search/post-detail counts are visible public counts. LinkedIn can
+include replies in the visible comment number, while Signal Discovery imports
+top-level commenters only. Treat pre-import people-to-check math as an upper
+bound. The exact unique people count is known only after the comments/reactions
+scrape completes and duplicate people are merged.
 
 Important interpretation rule: a source list row count is the number of
 headline-passing candidates inserted after scraping and filtering, not the raw
@@ -243,7 +249,7 @@ Examples of BAD keywords:
 
 Look for posts that:
 
-- Have meaningful engagement (minimum 30 likes OR 15 comments)
+- Have meaningful visible engagement (minimum 30 likes OR 15 visible comments)
 - Are from authors in your ICP's community
 - Discuss specific, tactical topics (not generic thought leadership)
 - Generate discussion, not just likes