@sellable/mcp 0.1.234 → 0.1.235

package/package.json

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

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

@@ -233,7 +233,7 @@ Discovery", "lead-source scouting", "source scouting", "lane", "provider",
 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`, `search_prospeo_companies`, `fetch_post_engagers`, or provider subagents until approved.
+`search_prospeo`, `fetch_post_engagers`, `search_prospeo_companies`, or provider subagents until approved.
 Only then persist `leadSourceType`, `leadSourceProvider`, and provider `currentStep`.
 
 Source work stays inline in the parent thread in normal create-campaign runs.
@@ -292,79 +292,15 @@ customer-facing source-choice labels.
 
 ## Prospect Setup Workstreams
 
-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 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.
-
-After filter choice, the only normal background worker is Message Drafting
-(`post-find-leads-message-scout`). The registry lookup is not a launch. Call
-the registry, then start Message Drafting via `Task`, `spawn_agent`, or host
-equivalent before loading `references/filter-leads.md` or `save_rubrics`. YOLO
-already grants permission; do not ask for another permission click. If no
-background tool is callable, start the same full branch inline before filter
-drafting or return `blocked` / `retry-needed`. Do not wait until filters are
-saved and then call the registry. Debug artifacts are optional only.
-
-The parent thread is the orchestrator and the filter writer. On the filters
-path, immediately start Message Drafting in the background, then load
-`references/filter-leads.md`, draft production rubrics in the parent, call
-`save_rubrics`, and ask for filter approval. Do not render message review, queue
-cells, or move past Filter Rules until saved filters are approved and
-`messageDraftRecommendation` is ready.
-
-Keep the Message Drafting handoff lean: `campaignId`, `workflowTableId`, a
-concise brief summary, concise source summary/source-use rule, and 3-5 sample
-workflow-table rows with `rowId`, name, title, company, and signal. Optional:
-campaign name, `selectedLeadListId`, and filter choice. Do not paste copied row
-counts, brief hashes, review-batch hashes, full row ID lists, broad row data, or
-local debug artifacts. The branch loads the current brief/context and sample
-rows through Sellable tools before drafting.
-
-When the user chooses filters, immediately call
-`update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
-so the app is on Filter Rules while Message Drafting runs. 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.
-
-Codex: outside YOLO/autonomous mode only, ask once if worker permission is
-missing. Use generic `gpt-5.5` / `xhigh` Message Drafting if needed.
-
-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 the full
-`generate-messages` prompt, all referenced assets, and
-`create-campaign-v2-validation`, then return a revised
-`messageDraftRecommendation`; parent renders it and asks approval. Message QA
-and validation before approval also belong to Message Drafting, but validation
-is an internal gate. Do not render `renderedFallbackSample`, `concerns`, or a
-full `qaReceipt` in the normal happy path.
-
-Run `post-find-leads-message-scout` as Message Draft Builder when exposed. It
-must load:
+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 prompts, or spawn Message Drafting before that question. Customer-facing work before the question: short setup summary plus add filters, skip filters, or revise source; no extra watch link.
 
-```text
-get_subskill_prompt({ subskillName: "generate-messages" })
-get_subskill_asset(...) for every required message asset named by generate-messages Mode 0
-get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })
-```
+After filter choice, the only normal background worker is Message Drafting (`post-find-leads-message-scout`). The registry lookup is not a launch. Call the registry, then start Message Drafting via `Task`, `spawn_agent`, or host equivalent before loading `references/filter-leads.md` or `save_rubrics`. YOLO already grants permission; do not ask for another permission click. If no background tool is callable, start the same full branch inline before filter drafting or return `blocked` / `retry-needed`. Do not wait until filters are saved and then call the registry.
+
+The parent thread is the orchestrator and the filter writer. On the filters path, start Message Drafting, then load `references/filter-leads.md`, save rubrics, and ask users to approve saved criteria. Keep `currentStep` on Filter Rules and show `Filters saved + waiting for message approval`; do not queue cells until message approval. Tell the user Message Drafting is preparing the template in the background.
+
+Keep the handoff lean: `campaignId`, `workflowTableId`, concise brief/source summary, source-use rule, and 3-5 sample rows (`rowId`, name, title, company, signal). Do not paste copied row counts, hashes, full row IDs, broad row data, or local debug artifacts.
 
-After candidate generation/revision and before returning `ready`, Message Draft
-Builder must load `create-campaign-v2-validation` through MCP as the final gate.
-No alternate, examples-only, or local-artifact prompt. If the agent cannot
-launch, the parent fallback runs the same gate from live state. Render review
-only after `messageDraftRecommendation` proves current campaign/table basis.
-Handoff: labeled Markdown, not raw JSON.
+Route user copy feedback before `approve-message` back to Message Drafting; parent does not rewrite. The branch loads the full `generate-messages` prompt, every required asset, then `get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`; do not render `renderedFallbackSample`, concerns, or `qaReceipt` in the happy path. Generic fallback is `gpt-5.5` / `xhigh` Message Drafting. Handoff is labeled Markdown, not raw JSON.
 
 ## Hard Gates
 

package/skills/research/config.json

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