@sellable/mcp 0.1.71 → 0.1.73

package/agents/registry.json

@@ -24,7 +24,8 @@
       },
       "codex": {
         "description": "Sellable lead-source scout for LinkedIn post engagement and active conversation signals.",
-        "modelReasoningEffort": "medium",
+        "model": "gpt-5.5",
+        "modelReasoningEffort": "high",
         "sandboxMode": "read-only",
         "nicknameCandidates": [
           "LinkedIn Engagement Scout",
@@ -71,7 +72,8 @@
       },
       "codex": {
         "description": "Sellable lead-source scout for Sales Navigator role, company, and activity filters.",
-        "modelReasoningEffort": "medium",
+        "model": "gpt-5.5",
+        "modelReasoningEffort": "high",
         "sandboxMode": "read-only",
         "nicknameCandidates": [
           "Sales Nav Scout",
@@ -118,7 +120,8 @@
       },
       "codex": {
         "description": "Sellable lead-source scout for Prospeo account/domain and broad contact expansion.",
-        "modelReasoningEffort": "medium",
+        "model": "gpt-5.5",
+        "modelReasoningEffort": "high",
         "sandboxMode": "read-only",
         "nicknameCandidates": [
           "Prospeo Contact Scout",

package/dist/tools/prompts.d.ts

@@ -71,6 +71,8 @@ export interface SourceScoutRegistryResponse {
         codex: {
             filename: string;
             description: string;
+            model: string;
+            modelReasoningEffort: string;
         };
         claude: {
             filename: string;

package/dist/tools/prompts.js

@@ -211,6 +211,8 @@ export function getSourceScoutRegistry() {
             codex: {
                 filename: String(agent.codex?.filename || `${agent.name}.toml`),
                 description: String(agent.codex?.description || ""),
+                model: String(agent.codex?.model || "gpt-5.5"),
+                modelReasoningEffort: String(agent.codex?.modelReasoningEffort || "high"),
             },
             claude: {
                 filename: String(agent.claude?.filename || `${agent.name}.md`),

package/package.json

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

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

@@ -437,6 +437,14 @@ should test for this campaign. Those can run in parallel and usually take
   `lead-sample.json`). Approval waits for both `lead-filter.md` and
   `message-validation.md`, then reconciles that the selected message basis rows
   still pass the final filter.
+- `lead-sample.json` from `find leads` is always the message sample source.
+  `filter leads` must not create a different message sample or cause message
+  generation to fetch new prospects. The filter only marks which find-leads
+  sample rows are valid, names false-positive patterns, and provides the
+  production keep/exclude rules. Message generation may start prep or
+  provisional candidate work from probable good-fit rows in `lead-sample.json`,
+  but the final `message-validation.md` winner must cite basis rows from
+  `lead-sample.json` that still pass `lead-filter.md`.
 - Parallel means real parallel execution, not optimistic progress copy. For the
   lead-source scout, first call `get_source_scout_registry` and use the
   returned canonical `name` values. In Codex, explicitly spawn one named custom scout per

package/skills/create-campaign-v2/core/flow.v2.json

@@ -479,7 +479,7 @@
             "parallel only if real parallel branches were launched"
           ],
           "timeEstimate": "~2-3 min",
-          "chatRenderRule": "If real parallel MCP/tool branches or host subagents were actually launched, say: 'I’m kicking off two workstreams now' and list 'Tighten the fit filter' and 'Message generation'. If not, do not mention parallel/background work; say: 'I’ll tighten the filter first, then run message generation from the same approved brief and sample leads.' Never claim parallelism unless parallel execution actually started. User-facing stage name is message generation; message-validation.md is only the internal artifact."
+          "chatRenderRule": "If real parallel MCP/tool branches or host subagents were actually launched, say: 'I’m kicking off two workstreams now' and list 'Tighten the fit filter' and 'Message generation from the find-leads sample'. If not, do not mention parallel/background work; say: 'I’ll tighten the filter first, then run message generation from the same find-leads sample.' Never claim parallelism unless parallel execution actually started. User-facing stage name is message generation; message-validation.md is only the internal artifact. Message generation must use lead-sample.json from find-leads; filter leads only gates which of those sampled rows remain valid."
         },
         {
           "action": "ask_continue_revise_or_confirm_only_if_needed",
@@ -605,11 +605,12 @@
           "action": "run_or_reconcile_subskill",
           "target": "generate-messages",
           "mode": "DRY MODE",
+          "sampleSource": "lead-sample.json from find-leads",
           "toolCallRequiredBeforeArtifacts": [
             "get_subskill_prompt({ subskillName: \"generate-messages\", offset, limit }) until hasMore=false"
           ],
           "skipIfFreshArtifactExists": "message-validation.md",
-          "reconcileWith": "lead-filter.md"
+          "reconcileWith": "lead-filter.md; lead-sample.json remains the sample source"
         },
         {
           "action": "write_artifact",
@@ -626,6 +627,7 @@
       ],
       "toolRules": [
         "Before writing message-validation.md, message-review.md, approval-packet.md, or a commit-gate AskUserQuestion, the current run must read 100% of the real generate-messages prompt via chunked get_subskill_prompt({ subskillName: \"generate-messages\", offset, limit }) calls.",
+        "Lead Sample Basis must cite rows from lead-sample.json produced by find-leads. lead-filter.md only gates those rows; it is not a source for a new sample.",
         "Do not hand-write message-validation.md from message-prep.md, message-candidate-drafts.md, or general campaign knowledge.",
         "message-validation.md must prove the full generate-messages workflow ran: Gold Standard Strategy Map, Proof Inventory, Token Fill Rules, Token Adherence Table, Angle Drafts, Kill / Combine Review, Finalists, Finalizer Pass, Gold-Standard Quality Gate, Skeptical Prospect Review, Winner Gate, and a raw sendable Selected Winner are required before message-review can recommend approve-message.",
         "If the Codex-hosted output is plausible but weaker than the loaded gold-standard examples, stop at message-review with revise-messaging. Do not continue to approval or mint just because the mechanical flow worked.",

package/skills/create-campaign-v2/references/validation-criteria.md

@@ -234,8 +234,10 @@ The sample set must:
 
 - contain 2-3 sample messages
 - use the find-leads message handoff rows or probable good-fit rows from
-  `lead-sample.json`; if `lead-filter.md` already exists, use only leads that
-  still pass it
+  `lead-sample.json`; if `lead-filter.md` exists, use only those same
+  find-leads sample rows when they still pass it
+- never replace the find-leads sample with a filter-generated sample, fresh
+  LinkedIn rows, new Sales Nav previews, or new Prospeo rows
 - use only supported tokens documented in the brief
 - contain no unresolved `{{token}}` placeholders
 - resolve every token used in the sample output

package/skills/generate-messages/SKILL.md

@@ -79,6 +79,11 @@ Required dry-mode contract:
 - do not mutate DB-backed campaign state
 - do not fetch fresh web or LinkedIn research
 - use only `brief.md`, `lead-filter.md`, and `lead-sample.json`
+- treat `lead-sample.json` from find-leads as the message sample source; do not
+  ask filter-leads for a new sample, create a new sample, or fetch additional
+  prospects for dry-mode message generation
+- use `lead-filter.md` only to decide which find-leads sample rows remain valid
+  for the final winner and which false-positive patterns must be avoided
 - generate 2-3 sample messages inline
 - write findings to `message-validation.md`
 - start `message-validation.md` with `Mode: DRY MODE (no DB mutation)`
@@ -94,7 +99,8 @@ Read:
 
 - `brief.md`
 - `lead-filter.md`
-- `lead-sample.json`
+- `lead-sample.json` from the find-leads step; this is the only allowed sample
+  source for dry-mode message generation
 - `mcp/sellable/skills/create-campaign-brief/references/phase75-active-runtime-message-pack.md`
 - `mcp/sellable/skills/create-campaign-v2/references/validation-criteria.md`
 - `mcp/sellable/skills/create-campaign-v2/references/thomas-revision-filters.md`

package/skills/research/config.json

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