@sellable/mcp 0.1.205 → 0.1.207

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. Choose and approve the lead source.
-7. Materialize the approved source list and confirm 15 campaign-table rows for
-   filter/message setup; do not present that as source sampling.
+6. Approve the Find Buyers Plan, then approve Start Import.
+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
 
@@ -143,7 +132,7 @@ Use the host-native structured question gate (`request_user_input` or
 AskUserQuestion) only for bounded choices:
 
 - target, offer, credibility, and prospect-source setup choices after research
-- source approval or source revision
+- Find Buyers Plan, Start Import, or source revision
 - use filters vs skip filters
 - approve message vs revise message
 - sender/sequence/launch choices at Settings
@@ -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,30 +195,29 @@ 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.
-
-After scouting, show a second approval gate for the concrete source action.
+Call `get_source_scout_registry` before source scouting. After Find Buyers Plan
+approval, source scouting is agent-first. Launch the approved returned source
+scout; YOLO/autonomous mode counts as permission. For LinkedIn posts, launch
+`source-scout-linkedin-engagement` even as a single lane; use Sales Nav/Prospeo
+scouts for those lanes. Use multiple scouts only for comparison/fallback. If a
+named scout is unavailable, use a generic `gpt-5.5` high background agent.
+Parent source MCP calls require impossible agent launch or approved inline
+fallback. Each scout loads its own provider prompt.
+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:
 selected posts, people we can check, likely prospects, what the first
 review will inspect, cleanup risk, and fallback. Label the approval like
@@ -241,16 +228,14 @@ 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 source-action 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.
-
-After the user approves this concrete source-action gate, do not show the
-Source Recommendation again or ask another source approval question.
+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.
 Acknowledge once, then call `import_leads` immediately with the approved source
 math. For Sales Nav/Prospeo, pass `targetLeadCount` as the approved source-list
 export count, not the campaign execution-slice size. For Signal Discovery, pass
@@ -261,39 +246,37 @@ After `import_leads`, poll `wait_for_lead_list_ready` until ready, failed, or
 cancelled. Rows appearing is not enough for `confirm_lead_list`; use
 `allowPartialSourceList: true` only when the user explicitly asks to continue early.
 
-For LinkedIn engagement, the source-action approval uses `## Source
+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
 customer-facing source-choice labels.
 
-## Post-Lead Workstreams
+## 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 post-lead workers before that question. The only customer-facing work
-before the question should be a short campaign setup summary and the choice:
+spawn Prospect Filters / 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 post-lead registry/reference needed for
-filtering and start the Lead Fit Builder. Also start the Message Draft Builder
-from the same campaign/table basis once filter-choice is known. If filters are
-skipped, move the watched app to Messages and run Message Draft Builder there.
+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.
 
 When the user chooses filters, immediately call
@@ -301,25 +284,39 @@ When the user chooses filters, immediately call
 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 the Message Draft Builder 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.
 
-Lead Fit Builder persists production rubrics with `save_rubrics` when filters
+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`.
 
-Run `post-find-leads-message-scout` as the background Message Draft Builder
-whenever the host exposes it. It must load:
+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.
+
+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.
+
+Load:
 
 ```text
 get_subskill_prompt({ subskillName: "generate-messages" })
 ```
 
-Do not use any alternate or examples-only message prompt. If the host cannot
-launch the agent, the parent fallback must run the same full prompt from live
-campaign state. Do not render message
-review until `messageDraftRecommendation` proves current campaign/table basis.
+Do not use any alternate or examples-only message prompt. Do not render message
+review until `messageDraftRecommendation` proves current campaign/table basis
+and shows whether it came from a background branch or an explicitly approved
+inline fallback.
 
 ## Hard Gates
 

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

@@ -256,8 +256,7 @@ Customer-facing source-plan copy must avoid "lane", "provider",
 "pilot volume", "workflow pain", and "ICP". Use "buyers" for the target market,
 "people to check" for raw reactions/comments, "prospects" after fit looks
 usable, and "leads" for campaign rows. Second, after the source evidence exists, show
-counts, samples, fit math, cleanup risk, and ask for source approval before
-import.
+counts, samples, fit math, cleanup risk, and ask for Start Import approval.
 
 For LinkedIn engagement, the second gate is not "approve source" in the abstract.
 It is a concrete scrape approval: show a compact `## Source Recommendation`
@@ -276,15 +275,13 @@ 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 is agent-first. Launch
+the approved named source scout when exposed; YOLO/autonomous mode counts as
+permission. A single LinkedIn-post lane still uses
+`source-scout-linkedin-engagement`, not parent `search_signals`. 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
@@ -297,18 +294,21 @@ 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.
+scout loads only its matching provider prompt. If the named scout is unavailable,
+use a generic `gpt-5.5` high background agent when possible. Parent source MCP
+calls are allowed only when agent launch is impossible or the user approves
+inline fallback. If inline, keep output numeric, do not claim a scout ran, and
+do not surface install status.
 
-For post-lead work, call `get_post_find_leads_scout_registry` after
+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 `post-find-leads-message-scout` /
-message generation from the same campaign/table basis. If the user chooses
-filters, also start `post-find-leads-filter-scout`, move the browser to Filter
-Rules, save rubrics, then ask for filter approval. After approval, keep the
+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
 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,8 +316,11 @@ 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 post-lead work when parallel work actually started. If the
-host cannot or should not launch background branches, say the real sequence:
+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:
 
 ```text
 I’ll tighten the filter first, then run message generation from the same sample.
@@ -356,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.