@sellable/mcp 0.1.206 → 0.1.208

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

@@ -21,34 +21,26 @@ validate-sample tool:
 get_subskill_prompt({ subskillName: "create-campaign-v2-tail" })
 ```
 
-CampaignOffer state and the watch link are canonical. Resume, gating, and handoff
-read campaign state first: `campaignId`, `watchUrl`, `campaignBrief`,
-`currentStep`, source/search association, `selectedLeadListId`,
-`workflowTableId`, `leadScoringRubrics`, `approvedMessageTemplate`,
-`senderIds`, `sequenceTemplate`, and running state. Local draft files are
-debug-only; do not create, link, or surface them in normal runs.
+CampaignOffer state and the watch link are canonical. Resume, gating, and
+handoff read campaign state first: `campaignId`, `watchUrl`, `campaignBrief`,
+`currentStep`, source/search IDs, `selectedLeadListId`, `workflowTableId`,
+`leadScoringRubrics`, `approvedMessageTemplate`, `senderIds`,
+`sequenceTemplate`, and running state. Local draft files are debug-only.
 
 ## Normal Flow
 
-There is no normal approval-packet.
-Legacy commit-gate/atomic-mint is only in create-campaign-v2-validation.
-
 1. Bootstrap and tell the user the active Sellable workspace.
 2. Resolve the client/company before strategy questions.
 3. Research the client/company and current offer enough to draft a concrete brief.
 4. Create the watchable campaign shell with `create_campaign` and the v1 brief.
 5. Surface the direct watch link once before brief approval.
 6. Approve the Find Buyers Plan, then approve Start Import.
-7. Materialize the approved source list and confirm 15 campaign-table rows for
-   filter/message setup; do not present that as source sampling.
+7. Materialize the source list and confirm 15 campaign-table rows for setup.
 8. Ask whether to use filters or skip them.
-9. Persist lead rubrics when filters are enabled, then ask approval while the
-   app remains on Filter Rules.
-10. Move to Filter Leads only after saved filters are approved.
-11. Review and approve/revise the message template.
-12. Sync the approved template into the brief, then queue bounded filtering.
-13. After one row passes with a generated message, review it, then hand off to
-    Settings, sender, sequence, and launch.
+9. Persist rubrics, approve saved criteria, then move to Filter Leads.
+10. Review and approve/revise the message template.
+11. Sync the approved template into the brief, then queue bounded filtering.
+12. After one generated pass, review it, then hand off to Settings and launch.
 
 ## Identity-First Campaign Setup
 
@@ -68,12 +60,10 @@ messages, and wait for final launch approval.
 What's your LinkedIn profile URL or handle?
 ```
 
-Require a LinkedIn profile URL or handle before setup continues. Normalize
-`csreyes92`, `@csreyes92`, or `/in/csreyes92` to
-`https://www.linkedin.com/in/{handle}/`; otherwise ask again. Retain it as
-`senderLinkedinUrl` or resolve `clientProspectId` for `create_campaign`. Run one
-lightweight profile lookup before strategy questions, then invite
-corrections.
+Require a LinkedIn profile URL/handle before setup continues. Normalize
+handles like `@csreyes92` to `https://www.linkedin.com/in/{handle}/`; otherwise
+ask again. Retain it as `senderLinkedinUrl` or resolve `clientProspectId` for
+`create_campaign`. Run one lightweight profile lookup before strategy questions.
 
 Restore the full setup intake before the brief. Ask bounded choices for:
 
@@ -84,22 +74,21 @@ Restore the full setup intake before the brief. Ask bounded choices for:
 - prospect source: "How should we find prospects?" with "Find prospects for me",
   "Use a CSV of LinkedIn profiles", and "Use a CSV of company domains"
 
-If setup choices were supplied and questions skipped, show before the brief:
-"Accepted LinkedIn input: normalized to the required LinkedIn profile URL. Offer
-path: supplied current offer or Sellable's researched
-recommendation; you can replace it with your current offer."
+If setup choices were supplied and questions skipped, state before the brief
+that the LinkedIn input was normalized and the offer path came from supplied or
+researched direction.
 
-Do not call `list_senders`, infer the campaign from connected senders, or show
-a sender picker during setup. Sender availability belongs only
-to Settings after message approval and campaign setup validation.
+Do not call `list_senders`, infer from connected senders, or show a sender
+picker during setup. Sender availability belongs only to Settings after message
+approval and campaign setup validation.
 
 Use `research-sender`, call `complete_sender_research` before shell creation,
 and carry proof gaps into the brief.
 
 ## Brief Provenance
 
-When rendering the first brief, do not add bracketed inline source tags to
-individual claims. Instead, start the brief with one short provenance line:
+When rendering the first brief, do not add bracketed inline source tags. Start
+with one short provenance line:
 
 ```text
 This brief is based on Sellable's research and your answers.
@@ -120,9 +109,9 @@ keep it as non-final bullets and say: "This is not the message yet; I will write
 real examples after we find and filter leads."
 
 Keep brief approval positive: no "does not approve..." list. The first brief
-must be visible exactly once before the approval question. If it was rendered
-immediately before `create_campaign`, do not render it again after the shell is
-created; append the one watch-link handoff, then ask approve/revise.
+must be visible exactly once before approval. If rendered before
+`create_campaign`, do not render it again after shell creation; append the one
+watch-link handoff, then ask approve/revise.
 
 ## YOLO Mode
 
@@ -155,8 +144,8 @@ when a bounded choice needs an escape hatch.
 ## Watch Link And Narration
 
 Create the shell before lead import so the user can watch. When
-`create_campaign` returns `watchUrl`, print that exact value once, directly
-before brief approval. It must be a direct
+`create_campaign` returns `watchUrl`, print that exact value once before brief
+approval. It must be a direct
 `/campaign-builder/{campaignId}?mode={claude|codex}` URL with `workspaceId` and
 `token`; never derive, shorten, reconstruct, or print a bare campaign URL. If
 missing/broken, recover with `create_campaign({ campaignId })` or `get_campaign`
@@ -189,9 +178,8 @@ when not hiring-led. For hiring-by-role signals, start with Prospeo because
 
 Before any provider prompt/search/scout call, move the watched campaign to
 source selection, show `## Find Buyers Plan`, then open `request_user_input`
-without repeating the URL. The plan must appear before the question; never ask
-first or reuse that approval. This only authorizes where to look; it does not
-add anyone yet. Write:
+without repeating the URL. The plan must appear before the question and only
+authorizes where to look; it does not add anyone yet. Write:
 
 - the buyer groups or places we could check
 - the best place to start
@@ -207,28 +195,24 @@ scouting", or "not importing leads" in customer-facing copy.
 Terms: buyers=market; people to check=raw reactions/comments; prospects=likely
 after fit; leads=rows.
 
-Do not surface blanket heuristics. Make the recommendation campaign-specific.
-If LinkedIn engagement is recommended, name exact post themes in plain language.
-Avoid chat terms "Signal Discovery", "lead-source scouting", "source scouting",
-"lane", "provider", "precision/scale tradeoff", "evidence quality", "pilot
-volume", "workflow pain", or "ICP". If public conversations look thin, recommend
-Sales Nav or Prospeo in plain words once. Only the approval question shown after
-that visible plan, or an explicit source choice after seeing it, satisfies this
-gate. Do not ask a second source-plan question or call `search_signals`,
-`search_sales_nav`, `search_prospeo`, `fetch_post_engagers`, or provider
-subagents until approved.
+Make the recommendation campaign-specific. If LinkedIn engagement is
+recommended, name exact post themes in plain language. Avoid chat terms "Signal
+Discovery", "lead-source scouting", "source scouting", "lane", "provider",
+"precision/scale tradeoff", "evidence quality", "pilot volume", "workflow
+pain", or "ICP". Only the approval question after that visible plan, or an
+explicit post-plan source choice, satisfies this gate. Do not ask a second
+source-plan question or call `search_signals`, `search_sales_nav`,
+`search_prospeo`, `fetch_post_engagers`, or provider subagents until approved.
 Only then persist `leadSourceType`, `leadSourceProvider`, and provider `currentStep`.
 
-Call `get_source_scout_registry` before source scouting. Source scouting is
-sequential by default. Run `source-scout-linkedin-engagement`,
-`source-scout-sales-nav`, and `source-scout-prospeo-contact` in parallel only
-when the user explicitly requested source comparison, a prior lane failed, or
-the first viable lane is borderline and a cheap fallback check is needed.
-Use a 10% planning floor after conservative cleanup. If LinkedIn engagement
-falls below that floor, move to Sales Nav. If Sales Nav also falls below it,
-move to Prospeo. Prospeo is the terminal fallback;
-if it also falls below 10%, tighten the ICP/source direction instead of
-inventing another provider.
+Source work stays inline in the parent thread in normal create-campaign runs.
+Do not launch source-scout background agents. Run the approved provider probes
+with MCP tools, loading only the provider prompt for the active sequential
+source. Use source scouts only if the user explicitly asks for a source
+comparison/debug run.
+Use a 10% planning floor after cleanup. If LinkedIn engagement falls below it,
+move to Sales Nav, then Prospeo. If Prospeo also falls below 10%, tighten the
+ICP/source direction instead of inventing another provider.
 
 After scouting, show a second approval gate for Start Import.
 For LinkedIn engagement (`signal-discovery` internally), use plain language:
@@ -241,13 +225,11 @@ Prospeo, name the specific search/import path and source lead count. Do not call
 `import_leads` or `confirm_lead_list` until this gate is approved.
 
 For Sales Nav and Prospeo, do not ask to import only the internal 15-row
-campaign-table execution slice at the Start Import gate. First-page samples are
-source math: sampled fit, projected good-fit prospects, and whether the path
-clears the target. Once it clears, ask approval for a source list with
-`targetLeadCount` around 1,000 contacts by default. After that,
-`confirm_lead_list({ reviewBatchLimit: 15 })` copies
-confirmed source rows into the campaign table and returns the initial
-campaign-table execution slice row ids for filter and message setup.
+campaign-table execution slice at Start Import. First-page samples are source
+math. Once the path clears, ask approval for a source list with
+`targetLeadCount` around 1,000 contacts by default. Then
+`confirm_lead_list({ reviewBatchLimit: 15 })` copies rows into the campaign
+table and returns execution-slice row ids for filter/message setup.
 
 After the user approves this Start Import gate, do not show the
 Source Recommendation again or ask another Start Import question.
@@ -265,15 +247,13 @@ For LinkedIn engagement, the Start Import approval uses `## Source
 Recommendation`, plain language, selected posts, people to check, likely
 prospects, cleanup risk, fallback, and the first 15-lead review.
 
-A source recommendation must show concrete evidence: source path, filters or
-recipe, raw volume, sample size, sampled fits as n/N plus percentage/range,
-estimated usable prospects, cleanup risk, runner-up, and what will happen after
-approval. For Sales Nav/Prospeo it must also show source export math:
-`rawResultCount`, `sampledFitRate`, conservative projected fit rate,
-`targetLeadCount` for the source list, and projected good-fit count from that
-export. If projected good-fit count is below target, the recommendation is to
-refine or broaden filters, not to run the internal campaign-table execution slice
-as if it were source sampling.
+A source recommendation must show source path, filters/recipe, raw volume,
+sample size, sampled fits as n/N plus percentage/range, estimated usable
+prospects, cleanup risk, runner-up, and post-approval action. Sales
+Nav/Prospeo also show `rawResultCount`, `sampledFitRate`, conservative
+projected fit rate, `targetLeadCount` for the source list, and projected
+good-fit count from that export. If below target, refine/broaden filters, not
+run the internal campaign-table execution slice as if it were source sampling.
 
 Supplied profile CSVs, company/domain CSVs, pasted domains, and existing
 Sellable lead lists are supported, but keep provider mechanics out of the first
@@ -281,40 +261,57 @@ customer-facing source-choice labels.
 
 ## Prospect Setup Workstreams
 
-After `confirm_lead_list` copies a non-empty confirmed source into the campaign
-and records the compact review batch, ask the filter-choice question
-immediately. Do not call
+After `confirm_lead_list` copies a non-empty source into the campaign and
+records the compact review batch, ask the filter-choice question immediately.
+Do not call
 `get_post_find_leads_scout_registry`, load filter/message subskill prompts, or
-spawn Prospect Filters / Message Drafting before that question. The only customer-facing work
-before the question should be a short campaign setup summary and the choice:
+spawn Message Drafting before that question. The only
+customer-facing work before the question should be a short setup summary and the choice:
 add filters, skip filters, or revise source. Do not include another watch link
 in this summary; the existing app view updates through campaign state.
 
-If the user chooses filters, load the prospect-setup registry/reference needed
-for filtering and start Prospect Filters. Also start Message Drafting from the
-same campaign/table basis once filter-choice is known. If filters are skipped,
-move the watched app to Messages and run Message Drafting there.
-Debug markdown/json artifacts are optional only.
+Once filter choice is known, start only Message Drafting in the background from
+the same campaign/table basis. If the user chooses filters, the parent thread
+continues inline: move to Filter Rules, load the filter reference, draft/save
+rubrics, and ask for filter approval while Message Drafting runs. If filters are
+skipped, move the watched app to Messages and run Message Drafting there. Debug
+markdown/json artifacts are optional only.
+
+Keep the Message Drafting handoff compact: campaign identity/name,
+`selectedLeadListId`, `workflowTableId`, copied-row count, review-batch
+count/hash, filter choice, source summary, and a concise brief summary. Do not
+paste the full row ID list or row data. The branch loads the current brief,
+table state, and review rows through Sellable tools before drafting.
 
 When the user chooses filters, immediately call
 `update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
 before rubric thinking or branch work. After `save_rubrics`, keep Filter Rules
 visible so the user can approve saved criteria. Only after approval should
 `update_campaign` move to `apply-icp-rubric` / Filter Leads and show
-`Filters saved + waiting for message approval` until the template is approved. Do not
-queue enrichment/filtering/Generate Message cells until message approval. Tell
-the user Message Drafting is preparing the template in the background.
+`Filters saved + waiting for message approval` until the template is approved.
+Do not queue enrichment/filtering/Generate Message cells until message
+approval. Tell the user Message Drafting is preparing the template in the
+background.
 
-Prospect Filters persists production rubrics with `save_rubrics` when filters
-are enabled. It must not require `brief.md`, `lead-review.md`, or
-`lead-sample.json`.
+The parent thread persists production rubrics with `save_rubrics` when filters
+are enabled. Do not spawn Prospect Filters in normal create-campaign runs.
 
 Run compatibility agent `post-find-leads-message-scout` as Message Drafting
 when allowed. Keep the long prompt and refs there.
 
-Codex: YOLO counts as campaign bg-agent permission. If no permission, ask once
-after filter choice. Use generic `gpt-5.5` / `xhigh` if needed. Never draft in
-parent silently.
+Codex: YOLO counts as permission for the single Message Drafting bg-agent. If no
+permission, ask once after filter choice. Use generic `gpt-5.5` / `xhigh`
+Message Drafting if needed. Never draft in parent silently.
+
+If the user critiques or edits the template before `approve-message`, route the
+feedback back to Message Drafting with current `messageDraftRecommendation`,
+basis token, campaign/table basis, and latest user text. Do not rewrite copy in
+the parent or call `update_campaign_brief`. Message Drafting must load/use
+`generate-messages` and return a revised `messageDraftRecommendation`; parent
+renders it and asks approval. Message QA and validation before approval also
+belong to Message Drafting; the parent renders its QA receipt, not a fresh
+parent-thread critique. The branch must load the normal validation/QA rules and
+run a QA pass before returning its concise review-ready recommendation.
 
 Load:
 

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

@@ -275,40 +275,31 @@ gate; tell the customer what happens next instead.
 
 ## Parallelism + Naming
 
-Source selection is sequential by default. Start with the first recommended
-place to look from `flow.v2.json`; for the current campaign shape that is
-usually LinkedIn engagement. Only try the next fallback after the current place
-is not viable, the user asks for a comparison, or the first place is borderline
-and needs a second source to avoid a bad recommendation. The fallback order must
-stay plain in customer copy: first check people talking on LinkedIn, then people
-with the right titles who recently posted on LinkedIn, then people with the
-right titles from a broader LinkedIn search, then a broader company and contact
-search.
+After the Find Buyers Plan is approved, source selection stays in the parent
+thread for normal create-campaign runs. Do not launch source scouts unless the
+user explicitly asks for a source comparison/debug run. Only try a fallback after
+the current place fails, the user asks for comparison, or the first place is
+borderline. Keep fallback copy plain: people talking on LinkedIn, recent
+LinkedIn titles, broader LinkedIn titles, then company/contact search.
 Use a 10% planning floor after conservative cleanup. If LinkedIn engagement falls
 below that floor, move to Sales Nav. If Sales Nav falls below that floor after
 reasonable refinement, move to Prospeo. Prospeo is the terminal fallback; if it
 also falls below 10%, tighten the ICP/source direction instead of inventing
 another provider.
 
-Source-angle comparison should be real, not implied. Call
-`get_source_scout_registry` before dispatching source scouts and use the
-returned canonical `name` values. In Codex or Claude Code, launch multiple named
-source scouts in the same turn only when the user explicitly requested source
-comparison, a prior lane failed, or the active flow marks the first lane as
-borderline. The parent thread should not fetch every provider prompt first; each
-scout loads only its matching provider prompt. If source work is sequential,
-keep the output numeric but do not claim the source scout was parallel or
-surface install status to the customer.
+Source-angle comparison should be real, not implied. Normal source work uses MCP
+provider tools inline from the parent and loads only the active provider prompt.
+Do not claim a source scout ran and do not surface install status.
 
 For prospect setup work, call `get_post_find_leads_scout_registry` after
 the user chooses filters, not before the filter-choice question. After
 `confirm_lead_list` copies source rows and records the first review/process
 sample, ask add-filters vs skip-filters
 immediately. Once the user answers, start Message Drafting via
-`post-find-leads-message-scout` from the same campaign/table basis. If the user
-chooses filters, also start Prospect Filters via
-`post-find-leads-filter-scout`, move the browser to Filter Rules, save rubrics,
-then ask for filter approval. After approval, keep the
+`post-find-leads-message-scout` from the same campaign/table basis. This is the
+only normal background agent. If the user chooses filters, the parent thread
+keeps working inline: move the browser to Filter Rules, load the filter
+reference, save rubrics, then ask for filter approval. After approval, keep the
 browser on Filter Leads and show `Filters saved + waiting for message approval`
 while the message recommendation is reviewed. If the user skips filters, move
 the browser to Messages/message review. The join gate is saved-filter approval or
@@ -316,21 +307,30 @@ a resolved skip-filter choice, plus a message recommendation grounded in the sam
 campaign/table basis. Enrichment, filtering, and Generate Message cells wait for
 template approval on the Use Template path.
 
-Only promise parallel prospect setup work when parallel work actually started. If the
-host cannot or should not launch background branches, do not silently move the
-long message prompt into the parent thread. In Codex, ask once for permission to
-use background Message Drafting. If the user declines or asks to continue
-without background agents, say the real sequence:
+Keep the Message Drafting handoff compact: campaign identity, campaign name,
+selected lead list ID, workflow table ID, copied source row count, review-batch
+row count, review-batch basis/hash, filter choice, source summary, and a concise
+campaign brief summary. Do not paste the full review-batch row ID list or row
+data into the spawn prompt. Message Drafting loads the current campaign brief,
+campaign/table state, review rows, full generate-messages prompt, and
+validation/QA rules inside its own branch before returning review-ready output.
+
+Only promise background work for Message Drafting when it actually started. If
+the host cannot or should not launch that branch, do not silently move the long
+message prompt into the parent thread. In Codex, ask once for permission to use
+background Message Drafting. If the user declines or asks to continue without
+background agents, say the real sequence:
 
 ```text
 I’ll tighten the filter first, then run message generation from the same sample.
 ```
 
-Do not say `kicking off two workstreams`, `in parallel`, or `background` as
-aspirational copy.
+Do not say `kicking off two workstreams`, `in parallel`, or `background` for
+source or filter work. Only Message Drafting may be described as background.
 
 Call the post-filter message stage `message generation` in chat.
-Message validation is an internal approval proof, not the workstream name.
+Message validation/QA is owned by Message Drafting; the parent renders its
+approval proof, not a fresh critique from memory.
 
 Be explicit about what has and has not happened:
 
@@ -359,8 +359,10 @@ language. The YOLO option approves the brief, continues with best guesses, and
 still stops before final launch.
 
 At message review, if the user asks for edits, write the revised template and
-examples before asking approval again. Do not ask whether an unseen revision is
-better. Save to the campaign only after `approve-message`.
+examples before asking approval again. Route the feedback back to Message
+Drafting with the current recommendation and basis; do not rewrite in the
+parent and do not call `update_campaign_brief`. Do not ask whether an unseen
+revision is better. Save to the campaign only after `approve-message`.
 During message generation or revision, do not call `request_user_input` or
 `AskUserQuestion`; render the revised copy first, then enter message review.